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).

[1]: https://issues.apache.org/jira/browse/IGNITE-12451

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

> 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."
>

Reply via email to