1 2 Previous Next 17 Replies Latest reply: May 31, 2012 7:20 AM by Balaji Ramalingam RSS

Infinispan 5.1.4.Final  + JGroups 3.0.9.Final

Balaji Ramalingam Newbie

Hi,

 

We are trying to setup Infinispan Cluster on 3 Nodes with Distributed Clustering mode. We simulated a load of 100,000 request and after around 20,000 request, all the nodes got hanged and it was unable to take up any more request. We simulated this load using jmeter scripts. Data that is being pushed to each of the nodes is of 12kb. Our expectation was to have the replication happen as immediately as an entry gets added/updated in the cache.

 

However, it was NOT happening. Other scenario that we tested was to have only 2 nodes currently serving the load mentioned above, and when we brought the 3rd node, NO nodes were NOT able to take up any request. All the nodes got blocked.

 

While I was searching for the way the Distributed Cache works, I found the following two links to understand more on the distributed mode.

https://community.jboss.org/wiki/DIST-DistributedCacheMode

https://community.jboss.org/thread/196059?start=0&tstart=0

 


Please help me in validating my configuration files attached.

 

1. We do NOT want the cache to be persistent.

2. All data that goes into the cache will be String. Instead of relying on Java Serialization, we have convered all the objects to a json String and pushed the same to cache.


 

 

I have attached 2 files : infinispan & jgroups configuration file.

 

In JGroups - We made it to do a streaming state transfer. So enabled the same by adding this protocol.

 

<pbcast.STATE max_pool="100" pool_thread_keep_alive="1800000" buffer_size="81920"/>

 

In infinispan - We configured for asynchronous state transfer

 

<namedCache name="application-cache">

                    <eviction strategy="LIRS" maxEntries="1800000" />

                    <expiration maxIdle="36000" wakeUpInterval="1000" />

                    <clustering mode="distribution">

                              <stateTransfer fetchInMemoryState="false" timeout="20000" />

                              <async asyncMarshalling="false" useReplQueue="true"

                                        replQueueInterval="10" replQueueMaxElements="1000" />

                              <l1 enabled="true" lifespan="36000" onRehash="true" />

                              <hash numVirtualNodes="9" numOwners="3" />

                    </clustering>

                    <loaders passivation="false" shared="false" preload="true">

                              <loader class="org.infinispan.loaders.file.FileCacheStore"

                                        fetchPersistentState="true" ignoreModifications="false"

                                        purgeOnStartup="true">

                                        <properties>

                                                  <property name="location" value="/home/balaji/" />

                                        </properties>

                              </loader>

                    </loaders>

                    <transaction useEagerLocking="true" eagerLockSingleNode="true">

                              <recovery enabled="true" recoveryInfoCacheName="noRecovery" />

                    </transaction>

          </namedCache>

 

 

Can you please validate the configurations to know on any flaw in the same.

  • 1. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Martin Gencur Novice

    Hi Balaji,

    let me comment the Infinispan configuration...

     

    The attribute passivation="false" on laoders means that with each write operation to the cache you also wait for file system operation as you do not define asynchronous cache store and all operations with the cache store (file system) are synchronous. This will probably affect the performance a lot.

     

    Furthermore, you said you were expecting the replication happening as immediately as an entry gets added/updated in the cache. However, you define asynchronous replication via <async> tag. So it's in fact asynchronous and will not happen neccessarily instantly.

     

    Just my two cents.

  • 2. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Balaji Ramalingam Newbie

    Hi Martin,

     

    Thank you on the reply. I have made passivation="true" & made the mode of replication to <sync/>.

     

    1. Can you let me know if  <stateTransfer> configuration looks fine.

     

    <stateTransfer fetchInMemoryState="false" timeout="20000" />

     

    2. Also during the state transfer, I could see lot of message being dropped. NAKACK is showing warn that message is getting dropped. Is there any problem in my jgroups configuration file ?

     

    3. Other scenario I tested was - While 3 nodes was running, I brought down one node and started it again. When I started that node, I want that node to have the entire state of other 2 servers before it starts serving the request. Can you please help me on which configuration would help me accomplish this case ?

     

     

    Thanks !

  • 3. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Martin Gencur Novice

    fetchInMemoryState should be true IMO, and timeout can be easily higher, like 4+ minutes. Read ISPN docs to see impact of fetchInMemoryState, when you have it set to false, it won't fetch state from other nodes to newly joining node. Maybe that was your problem as well.

     

    Not really sure about the JGroups config but the NACKACK settings could look e.g. like this :

     

    <pbcast.NAKACK  exponential_backoff="0"

                       use_mcast_xmit="true"

                       retransmit_timeout="300,600,1200"

                       discard_delivered_msgs="true"/>

  • 4. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Balaji Ramalingam Newbie

    Hi Martin,

     

    Thank you on the state Transfer configuration. After changing this, we were trying to simulate it for a load of 10 lakh request. After sometime, have started getting error during transaction commit.

     

    This is the error on Node 1 - Other nodes errors are in next replies.

     

    ERROR [ajp-bio-22009-exec-25] [2012-05-24 11:27:26,742] (DummyTransaction.java:notifyAfterCompletion:281) - ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=164466}, status=3}, lockedKeys=null, backupKeyLocks=null, viewId=4} org.infinispan.transaction.synchronization.SyncLocalTransaction@28272} org.infinispan.transaction.synchronization.SynchronizationAdapter@28291

    org.infinispan.CacheException: Could not commit.

            at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:83)

            at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:279)

            at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:328)

            at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)

            at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)

            at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1016)

            at org.infinispan.CacheImpl.put(CacheImpl.java:702)

            at org.infinispan.CacheImpl.put(CacheImpl.java:694)

            at org.infinispan.CacheSupport.put(CacheSupport.java:53)

            at in.verse.cache.distributed.CacheServlet.doGet(CacheServlet.java:27)

            at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)

            at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)

            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)

            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)

            at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)

            at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)

            at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)

            at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)

            at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)

            at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)

            at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)

            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)

            at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)

            at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)

            at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)

            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

            at java.lang.Thread.run(Thread.java:662)

    Caused by: javax.transaction.xa.XAException

            at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:223)

            at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:176)

            at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)

     

     

    We have the following transaction definition in cache configuration :

    <transaction useEagerLocking="true" eagerLockSingleNode="true">

                                  <recovery enabled="true" recoveryInfoCacheName="noRecovery" />

                        </transaction>

     

    Can you help me to identify the problem in this configuration ?

  • 5. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Balaji Ramalingam Newbie

    <pbcast.NAKACK  exponential_backoff="0"

                       use_mcast_xmit="true"

                       retransmit_timeout="300,600,1200"

                       discard_delivered_msgs="true"/>

     

    Here we are setting multi-caste is true. My understanding was the Multicaste is enabled only in UDP Protocol. However, we are using TCP, which will do multiple times unicast. Please validate my understanding. In my trace logs, I could still see lot of messages being dropped.

  • 6. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Balaji Ramalingam Newbie

    After setting up 3 nodes with a load of 1 million requests - started getting this exception ...

     

    In Node 3 -

    ERROR [AsyncSerializationThread-9] [2012-05-24 19:44:59,891] (TP.java:down:1122) - failed sending message to localhost-54136 (91 bytes): java.lang.NullPointerException, cause: null

    ERROR [AsyncSerializationThread-9] [2012-05-24 19:45:04,893] (TP.java:down:1122) - failed sending message to localhost-54136 (91 bytes): java.lang.NullPointerException, cause: null

    ERROR [AsyncSerializationThread-9] [2012-05-24 19:45:09,896] (TP.java:down:1122) - failed sending message to localhost-54136 (91 bytes): java.lang.NullPointerException, cause: null

    ERROR [AsyncSerializationThread-9] [2012-05-24 19:45:14,898] (TP.java:down:1122) - failed sending message to localhost-54136 (91 bytes): java.lang.NullPointerException, cause: null

    ERROR [AsyncSerializationThread-53] [2012-05-24 19:45:20,056] (TP.java:down:1122) - failed sending message to localhost-54136 (91 bytes): java.lang.NullPointerException, cause: null

    ERROR [AsyncSerializationThread-267] [2012-05-24 19:45:25,058] (TP.java:down:1122) - failed sending message to localhost-54136 (91 bytes): java.lang.NullPointerException, cause: null

    ERROR [AsyncSerializationThread-94] [2012-05-24 19:45:30,059] (TP.java:down:1122) - failed sending message to localhost-54136 (91 bytes): java.lang.NullPointerException, cause: null

    ERROR [AsyncSerializationThread-181] [2012-05-24 19:45:35,059] (TP.java:down:1122) - failed sending message to localhost-54136 (91 bytes): java.lang.NullPointerException, cause: null

    ERROR [AsyncSerializationThread-294] [2012-05-24 19:45:40,061] (TP.java:down:1122) - failed sending message to localhost-54136 (91 bytes): java.lang.NullPointerException, cause: null

     

     

    In Node 2 -

     

     

    WARN [OOB-15,localhost-54736] [2012-05-24 19:44:23,391] (TP.java:sendToSingleMember:1297) - localhost-54736: no physical address for 09c838f3-fb79-fd3e-f5aa-ab3310717e34, dropping message

    WARN [OOB-15,localhost-54736] [2012-05-24 19:44:36,232] (TP.java:sendToSingleMember:1297) - localhost-54736: no physical address for 09c838f3-fb79-fd3e-f5aa-ab3310717e34, dropping message

    WARN [OOB-15,localhost-54736] [2012-05-24 19:44:49,706] (TP.java:sendToSingleMember:1297) - localhost-54736: no physical address for 09c838f3-fb79-fd3e-f5aa-ab3310717e34, dropping message

    WARN [OOB-15,localhost-54736] [2012-05-24 19:44:59,168] (TP.java:sendToSingleMember:1297) - localhost-54736: no physical address for 09c838f3-fb79-fd3e-f5aa-ab3310717e34, dropping message

    WARN [OOB-15,localhost-54736] [2012-05-24 19:45:10,404] (TP.java:sendToSingleMember:1297) - localhost-54736: no physical address for 09c838f3-fb79-fd3e-f5aa-ab3310717e34, dropping message

    WARN [OOB-15,localhost-54736] [2012-05-24 19:45:19,602] (TP.java:sendToSingleMember:1297) - localhost-54736: no physical address for 09c838f3-fb79-fd3e-f5aa-ab3310717e34, dropping message

    WARN [OOB-15,localhost-54736] [2012-05-24 19:45:29,818] (TP.java:sendToSingleMember:1297) - localhost-54736: no physical address for 09c838f3-fb79-fd3e-f5aa-ab3310717e34, dropping message

    WARN [OOB-15,localhost-54736] [2012-05-24 19:45:46,039] (TP.java:sendToSingleMember:1297) - localhost-54736: no physical address for 09c838f3-fb79-fd3e-f5aa-ab3310717e34, dropping message

    WARN [OOB-15,localhost-54736] [2012-05-24 19:45:56,036] (TP.java:sendToSingleMember:1297) - localhost-54736: no physical address for 09c838f3-fb79-fd3e-f5aa-ab3310717e34, dropping message

     

    Can I have my JGroups configuration validated ?

     

    Thank you so much !

  • 7. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Balaji Ramalingam Newbie

    Not sure where I messed up the configuration.  Getting lots of errors !

     

    ERROR [CacheViewInstaller-2,localhost-61406] [2012-05-25 00:19:59,716] (CacheViewsManagerImpl.java:clusterInstallView:263) - ISPN000172: Failed to prepare view CacheView{viewId=12, members=[localhost-11652, localhost-61406, localhost-33790]} for cache  ___defaultcache, rolling back to view CacheView{viewId=8, members=[localhost-61406, localhost-33790]}

    java.util.concurrent.TimeoutException

            at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228)

            at java.util.concurrent.FutureTask.get(FutureTask.java:91)

            at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318)

            at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249)

            at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875)

            at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

            at java.util.concurrent.FutureTask.run(FutureTask.java:138)

            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

            at java.lang.Thread.run(Thread.java:662)

     

    This is my latest cache configuration : -

     

    <namedCache name="application-cache">

                        <eviction strategy="LIRS" maxEntries="1800000" />

                        <expiration maxIdle="240000" wakeUpInterval="10000"

                                  lifespan="360000" reaperEnabled="true" />

                        <clustering mode="distribution">

                                  <stateTransfer fetchInMemoryState="true" timeout="300000"

                                            chunkSize="512" />

                                  <!--<async asyncMarshalling="false" useReplQueue="false" replQueueInterval="10"

                                            replQueueMaxElements="1000" /> -->

                                  <sync />

                                  <l1 enabled="true" lifespan="180000" onRehash="true" />

                                  <hash numVirtualNodes="1" numOwners="3" />

                        </clustering>

                        <loaders passivation="true" shared="false" preload="false">

                                  <loader class="org.infinispan.loaders.file.FileCacheStore"

                                            fetchPersistentState="false" ignoreModifications="true"

                                            purgeOnStartup="true" purgerThreads="25">

                                            <properties>

                                                      <property name="location" value="/home/verse-staging/" />

                                            </properties>

                                  </loader>

                        </loaders>

                        <locking writeSkewCheck="false" useLockStriping="false"

                                  lockAcquisitionTimeout="300000" isolationLevel="READ_COMMITTED"

                                  concurrencyLevel="5000" />

                        <transaction useSynchronization="false" useEagerLocking="true"

                                  use1PcForAutoCommitTransactions="false" transactionMode="TRANSACTIONAL"

                                  syncRollbackPhase="false" syncCommitPhase="false" lockingMode="OPTIMISTIC"

                                  eagerLockSingleNode="true" cacheStopTimeout="30000" autoCommit="true">

                                  <!-- <recovery recoveryInfoCacheName="__recoveryInfoCacheName__" -->

                                  <!-- enabled="false" /> -->

                        </transaction>

                        <customInterceptors />

                        <!-- <dataContainer class="org.infinispan.container.DefaultDataContainer"> -->

                        <!-- <properties /> -->

                        <!-- </dataContainer> -->

                        <jmxStatistics enabled="false" />

                        <storeAsBinary storeValuesAsBinary="true"

                                  storeKeysAsBinary="true" enabled="false" />

                        <lazyDeserialization enabled="false" />

                        <deadlockDetection spinDuration="100" enabled="false" />

                        <indexing indexLocalOnly="false" enabled="false">

                                  <properties />

                        </indexing>

                        <versioning versioningScheme="NONE" enabled="false" />

                        <invocationBatching enabled="true" />

                        <unsafe unreliableReturnValues="true" />

              </namedCache>

     

     

     

     

    Can someone help me on this ? 

  • 8. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Martin Gencur Novice

    Oh, you are using TCP...then use_mcast_xmit should be false, really.

     

    Have you tried sample jgroups config that is available in ISPN distribution? https://github.com/infinispan/infinispan/blob/master/core/src/main/resources/jgroups-tcp.xml

  • 9. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Balaji Ramalingam Newbie

    Yes. I have used the sample file. On top of that I have added a Streaming State Transfer protocol to ensure the state is getting replicated in a buffered mode !

     

    Can you help me validate my transaction configuration @ Infinispan that I have posted above ? I have started getting lots of issues on the commit phase !

  • 10. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Martin Gencur Novice

    OK, good.

     

    This is my opinion on the transaction configuration (I'm still reading this from javadocs):

     

    - useSynchronization should be true unless you want to use transaction recovery, it's more performant

    - useEagerLocking="true" was replaced by PESSIMISTIC locking in 5.1 version of ISPN, it does not go with OPTIMISTIC which you have set

    - if you enclose all operations with cache by a transaction, use1PcForAutoCommitTransactions can be false

    - I would leave default values for syncRollbackPhase and syncCommitPhase which would be false, true

     

    As I noticed from your stack tracec, you don't use any container/specific transaction manager and then transactionManagerLookup class falls back to DummyTransactionManagerLookup and transaction manager to DummyTransactionManager. I'd recommend reading https://docs.jboss.org/author/display/ISPN/Infinispan+transactions with regards to DymmyTM and would use some other TM, like JBoss TM.

     

    Otherwise it looks good to me.

  • 11. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Balaji Ramalingam Newbie

    Hi Martin,

     

    Thank you on the response. I am trying to configure JbossTransactionManagerLookup for managing transactions.  I followed your blog to add the required maven dependency to configure the TM.

     

    http://infinispan.blogspot.in/2012/05/how-to-configure-infinispan-with.html

     

    <transaction useSynchronization="true" useEagerLocking="true"

                                  transactionManagerLookupClass="org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup"

                                  use1PcForAutoCommitTransactions="false" transactionMode="TRANSACTIONAL"

                                  syncRollbackPhase="false" syncCommitPhase="true" lockingMode="OPTIMISTIC"

                                  eagerLockSingleNode="true" cacheStopTimeout="30000" autoCommit="true">

                        </transaction>

     

    Even after configuring the same, I still see that my code is using DummyTransaction.

     

    ERROR [ajp-bio-22009-exec-23] [2012-05-25 06:03:03,380] (DummyTransaction.java:notifyBeforeCompletion:233) - ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=12390}, status=1}, lockedKeys=null, backupKeyLocks=null, viewId=4} org.infinispan.transaction.synchronization.SyncLocalTransaction@3066} org.infinispan.transaction.synchronization.SynchronizationAdapter@3085

    org.infinispan.CacheException: Could not prepare.

            at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70)

            at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)

            at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:241)

            at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)

            at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)

            at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1016)

            at org.infinispan.CacheImpl.put(CacheImpl.java:702)

            at org.infinispan.CacheImpl.put(CacheImpl.java:694)

            at org.infinispan.CacheSupport.put(CacheSupport.java:53)

            at in.verse.cache.distributed.CacheServlet.doGet

     

    Let me know if I am missing something.

     

    Thanks !

  • 12. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Martin Gencur Novice

    Hi Baliji,

    glad to see someone is reading the blog:)

     

    Anyway, that's weird that you're still seing DummyTransaction. When you get TM by calling  TransactionManager tm = ((CacheImpl) cache).getAdvancedCache().getTransactionManager(), print the class of the TM, e.g. System.out.println("Transaction: " + tm.getClass().getName());

     

    You should get "com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple", if not then something is wrong.

     

    Btw. I'm still seeing useEagerLocking="true" in your config. This should be false because it will set locking mode to PESSIMISTIC even though you set it explicitly to OPTIMISTIC; useEagerLocking simply has higher priority!

     

    Please make sure you really use JBoss TM, by adding more logging or so, before you post next questions ;-)

  • 13. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Balaji Ramalingam Newbie

    Hi Martin,

     

    Apologize to bother you.  Here is my test program. This time I used programmatic configuration instead of declarative one !

     

    @Test

        public void infiniSpanCache() throws IOException

        {

            EmbeddedCacheManager manager = null;

            if (manager == null)

            {

                GlobalConfiguration glob = new GlobalConfigurationBuilder().nonClusteredDefault().globalJmxStatistics().enable().build();

                Configuration loc =

                        new ConfigurationBuilder().clustering().cacheMode(CacheMode.LOCAL).transaction()

                                .transactionMode(TransactionMode.TRANSACTIONAL)

                                .autoCommit(false).lockingMode(LockingMode.OPTIMISTIC).transactionManagerLookup(new JBossStandaloneJTAManagerLookup())

                                .locking().isolationLevel(IsolationLevel.READ_COMMITTED).loaders().passivation(false).preload(false).shared(false)

                                .build();

                manager = new DefaultCacheManager(glob, loc, true);

            }

            Cache<String, String> cache = manager.getCache();

            TransactionManager tm = ((CacheImpl) cache).getAdvancedCache().getTransactionManager();

            System.out.println("Transaction: " + tm);

            System.out.println("Cache Implementation = " + cache);

            // cache.put("key", "value");

            // assert cache.containsKey("key");

            // cache.remove("key");

            // assert cache.isEmpty();

        }

     

    Output :

     

    Transaction: Transaction: unknown

    Cache Implementation = Cache '___defaultcache'@576504fa

     

    I have all the dependencies mentioned in your blog ! While I was searching to know if I have missing something to configure the JBossTransactionManager. I found the same issue being raised in this forum 2 weeks back in 5.1.4.Final version.

     

    https://community.jboss.org/message/734350

     

     

    Here are my findings after I started going through the Infinispan Source code ! - This was with declarative approach.

     

    <transaction useSynchronization="true" transactionMode="TRANSACTIONAL"

              useEagerLocking="false"

              transactionManagerLookupClass="org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup"

              use1PcForAutoCommitTransactions="false" syncRollbackPhase="false"

              syncCommitPhase="true" lockingMode="OPTIMISTIC" eagerLockSingleNode="true"

              cacheStopTimeout="30000" autoCommit="true">

     

    I observed that when the code lands to TransactionManagerFactory class :

     

      TransactionManagerLookup lookup = configuration.getTransactionManagerLookup();

     

    This lookup is being returned as null;

     

    When I looked into TransactionConfigurationBuilder class,

     

       public TransactionConfigurationBuilder transactionManagerLookup(TransactionManagerLookup tml) {

          this.transactionManagerLookup = tml;

          return this;

       }

     

    It has only transactionManagerLookup, But it does not have transactionManagerLookupClass. Now I am confused to figure out the root cause of the problem. !

     

    In both the approaches, programatically and declaratively the transactionManager is not getting set.

     

    Let me know I am missing something silly. I would continue to go thru the source code of Infinispan and keep you posted on my findings.

     

    Thanks for your time !

  • 14. Re: Infinispan 5.1.4.Final  + JGroups 3.0.9.Final
    Martin Gencur Novice

    Hi Baliji, no problem. You don't bother me:)

     

    I tried to change one of infinispan quickstarts and add transactions to it. It is Java SE application, similar to yours. The commit that I did can be found at https://github.com/mgencur/examples/commit/d9b7c0bea30728f227a5c15b82b80a41a71321f2 .

     

    When I built the "embedded-cache" app by "mvn clean compile dependency:copy-dependencies -DstripVersion" and ran the app in its "target" directory by "java -cp classes:dependency/* org.infinispan.quickstart.embeddedcache.DefaultCacheQuickstart", I got the following output:

     

    May 26, 2012 8:03:08 PM org.infinispan.factories.GlobalComponentRegistry start
    INFO: ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.4.FINAL
    May 26, 2012 8:03:08 PM org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup getTransactionManager
    INFO: ISPN000107: Retrieving transaction manager Transaction: unknown
    Transaction: com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple
    May 26, 2012 8:03:08 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager addService
    INFO: ARJUNA012163: Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 33534
    May 26, 2012 8:03:08 PM com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem <init>
    INFO: ARJUNA012337: TransactionStatusManagerItem host: 127.0.0.1 port: 33534
    May 26, 2012 8:03:08 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager start
    INFO: ARJUNA012170: TransactionStatusManager started on port 33534 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService
    TransactionImple < ac, BasicAction: 0:ffff7f000001:aecb:4fc11adc:2 status: ActionStatus.RUNNING >

     

    You can see that JBossTM is really used. Try to compare your application/settings with mine and see what is wrong.

     

    Btw, transactionManagerLookupClass XML attribute is used to configure transaction manager lookup as well as is .transactionManagerLookup() in Java. The name of the attribute is just a little different from its counterpart in Java.

1 2 Previous Next