Infinispan non-transactional cache

[gspadmapriya]

Hello..

We have a requirement, where we will always have a new key added rather modifications, so in that case, do we need transactional cache?

Also,we are not using cache store, as this key-value, will be used only one time. I am under impression, we do not need transaction at all, so in that case, for Infinispan 7.0.3, I need to mark transaction as non-transactional, right? Please advice. As we are already facing lot of XA Exception in prod with version 5.2. @

[nadirx]

You don't need a tx cache unless your modifications involve multiple keys that need to be atomically modified.

[gspadmapriya]

Thank you Tristan., your reply helped to make a big decision on our config.

I need another help,

We have 36 instances in production under the same cluster. But we end up restarting every day(very bad on our side), even then its observed, to have XAException after 4 hours of start time. Looks like have some concurrency issues.

Can you please help me, resolve this?

We are using Infinispan 5.2 and jgroups 3. I see, that jgroups, has config with thread_pool.max_threads="30" , given below snippet from jgroups xml, we are using.

Should I increase this thread_pool.max_threads="30"  to 40? As we have 36 tomcat instances...

<TCP

    bind_addr="SITE_LOCAL"

    bind_port="${jgroups.tcp.port:7800}"

    loopback="true"

    port_range="2"

    recv_buf_size="20m"

    send_buf_size="640k"

    discard_incompatible_packets="true"

    max_bundle_size="64000"

    max_bundle_timeout="30"

    enable_bundling="true"

    use_send_queues="true"

    enable_diagnostics="false"

    bundler_type="old"

    thread_naming_pattern="pl"

    thread_pool.enabled="true"

    thread_pool.min_threads="2"

    thread_pool.max_threads="30"

    thread_pool.keep_alive_time="60000"

    thread_pool.queue_enabled="true"

    thread_pool.queue_max_size="100"

    thread_pool.rejection_policy="Discard"

    oob_thread_pool.enabled="true"

    oob_thread_pool.min_threads="2"

    oob_thread_pool.max_threads="30"

    oob_thread_pool.keep_alive_time="60000"

    oob_thread_pool.queue_enabled="false"

    oob_thread_pool.queue_max_size="100"

    oob_thread_pool.rejection_policy="Discard"   

  />

Any help on resolving, will be greatly appreciated!

[wdfink]

Thread pool depends more on the load. You might check whether increasing of the thread_pool and oob_thread_pool helps, maybe increase min=2 as well.

Also I would set oob_thread_pool.queue_enabled="true"

[rvansa]

What exception exactly is that?

30 OOB threads is quite a low value, especially if you write into the cache very often. In stress tests, hundreds of threads are needed. However, you do not need thread per node - the number of threads is rather proportional to frequency of modifications.

I would not recommend enabling OOB queue as Wolf suggests, JGroups resends discarded messages, and therefore if they can't be processed for a while, there's no reason to queue them - the retransmission would be probably on its way.

[gspadmapriya]

Didnt help, got replication exception

[rvansa]

Can't help, don't have your logs.

[gspadmapriya]

Timed out waiting for the state transfer lock, state transfer in progress for view 11

added new discussion,

Timed out waiting for the state transfer lock, state transfer in progress for view 11