Usage of TransactionConfiguration to overcome deadlocked threads

classic Classic list List threaded Threaded
4 messages Options
Kamlesh Joshi Kamlesh Joshi
Reply | Threaded
Open this post in threaded view
|

Usage of TransactionConfiguration to overcome deadlocked threads

Hi Igniters,

 

We are currently using ATOMIC caches for our operations. Recently, we observed cluster hang issue, the operations were stuck for quite a long time (had to bring down the cluster to resolve this). So, after some digging found that setting up below property should resolve this. Could you please confirm on below:

 

  1. Whether this needs to be set on both Ignite servers and Ignite thick clients?
  2. Or setting on cluster should suffice?
  3. What should be the optimum value for defaultTxTimeout

 

 

<property name="transactionConfiguration">

            <bean class="org.apache.ignite.configuration.TransactionConfiguration">

                <property name="defaultTxTimeout" value="20000"/>

            </bean>

</property>

 

 

 

 

Thanks and Regards,

Kamlesh Joshi

 


"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

Alex Plehanov Alex Plehanov
Reply | Threaded
Open this post in threaded view
|

Re: Usage of TransactionConfiguration to overcome deadlocked threads

Hello,

TransactionConfiguration property has nothing to do with atomic caches. Perhaps your threads were deadlocked due to atomic putAll/removeAll operations with an unordered set of keys. It's a known issue and I hope will be fixed soon. See [1] for detailed information. Until this ticked is fixed you should avoid concurrent putAll/removeAll operations with an unordered set of keys on atomic caches (putAll with HashMap as an argument, for example).


вт, 20 окт. 2020 г. в 12:16, Kamlesh Joshi <[hidden email]>:

Hi Igniters,

 

We are currently using ATOMIC caches for our operations. Recently, we observed cluster hang issue, the operations were stuck for quite a long time (had to bring down the cluster to resolve this). So, after some digging found that setting up below property should resolve this. Could you please confirm on below:

 

  1. Whether this needs to be set on both Ignite servers and Ignite thick clients?
  2. Or setting on cluster should suffice?
  3. What should be the optimum value for defaultTxTimeout

 

 

<property name="transactionConfiguration">

            <bean class="org.apache.ignite.configuration.TransactionConfiguration">

                <property name="defaultTxTimeout" value="20000"/>

            </bean>

</property>

 

 

 

 

Thanks and Regards,

Kamlesh Joshi

 


"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

Kamlesh Joshi Kamlesh Joshi
Reply | Threaded
Open this post in threaded view
|

RE: [External]Re: Usage of TransactionConfiguration to overcome deadlocked threads

Thanks for the update Alex.

 

Actually we are using BinaryObjects for such operations. Is there any implementation available (or a reference) to sort user defined types of objects ?

 

Thanks and Regards,

Kamlesh Joshi

 

From: Alex Plehanov <[hidden email]>
Sent: 20 October 2020 19:54
To: [hidden email]
Subject: [External]Re: Usage of TransactionConfiguration to overcome deadlocked threads

 

The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.

Hello,

 

TransactionConfiguration property has nothing to do with atomic caches. Perhaps your threads were deadlocked due to atomic putAll/removeAll operations with an unordered set of keys. It's a known issue and I hope will be fixed soon. See [1] for detailed information. Until this ticked is fixed you should avoid concurrent putAll/removeAll operations with an unordered set of keys on atomic caches (putAll with HashMap as an argument, for example).

 

 

вт, 20 окт. 2020 г. в 12:16, Kamlesh Joshi <[hidden email]>:

Hi Igniters,

 

We are currently using ATOMIC caches for our operations. Recently, we observed cluster hang issue, the operations were stuck for quite a long time (had to bring down the cluster to resolve this). So, after some digging found that setting up below property should resolve this. Could you please confirm on below:

 

  1. Whether this needs to be set on both Ignite servers and Ignite thick clients?
  2. Or setting on cluster should suffice?
  3. What should be the optimum value for defaultTxTimeout

 

 

<property name="transactionConfiguration">

            <bean class="org.apache.ignite.configuration.TransactionConfiguration">

                <property name="defaultTxTimeout" value="20000"/>

            </bean>

</property>

 

 

 

 

Thanks and Regards,

Kamlesh Joshi

 


"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."


"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

Alex Plehanov Alex Plehanov
Reply | Threaded
Open this post in threaded view
|

Re: [External]Re: Usage of TransactionConfiguration to overcome deadlocked threads

If you have user-defined types and can sort it by yourself, you can use LinkedHashMap as an argument to preserve the order and avoid deadlocks.

ср, 21 окт. 2020 г. в 09:44, Kamlesh Joshi <[hidden email]>:

Thanks for the update Alex.

 

Actually we are using BinaryObjects for such operations. Is there any implementation available (or a reference) to sort user defined types of objects ?

 

Thanks and Regards,

Kamlesh Joshi

 

From: Alex Plehanov <[hidden email]>
Sent: 20 October 2020 19:54
To: [hidden email]
Subject: [External]Re: Usage of TransactionConfiguration to overcome deadlocked threads

 

The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.

Hello,

 

TransactionConfiguration property has nothing to do with atomic caches. Perhaps your threads were deadlocked due to atomic putAll/removeAll operations with an unordered set of keys. It's a known issue and I hope will be fixed soon. See [1] for detailed information. Until this ticked is fixed you should avoid concurrent putAll/removeAll operations with an unordered set of keys on atomic caches (putAll with HashMap as an argument, for example).

 

 

вт, 20 окт. 2020 г. в 12:16, Kamlesh Joshi <[hidden email]>:

Hi Igniters,

 

We are currently using ATOMIC caches for our operations. Recently, we observed cluster hang issue, the operations were stuck for quite a long time (had to bring down the cluster to resolve this). So, after some digging found that setting up below property should resolve this. Could you please confirm on below:

 

  1. Whether this needs to be set on both Ignite servers and Ignite thick clients?
  2. Or setting on cluster should suffice?
  3. What should be the optimum value for defaultTxTimeout

 

 

<property name="transactionConfiguration">

            <bean class="org.apache.ignite.configuration.TransactionConfiguration">

                <property name="defaultTxTimeout" value="20000"/>

            </bean>

</property>

 

 

 

 

Thanks and Regards,

Kamlesh Joshi

 


"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."


"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."