Hi infinispan-dev, i'm having a basic issue with infinispan and i wonder if i can get some lead on what to look next. I have a cache configured in replicated/sync mode on a cluster made of 3 nodes. - Node1 writes a key/value in the cache - Node2 gets it because i have registered a listener for it and i see the message being logged - Node3 never gets it no error is raised anywhere. I'm using Infinispan 5.3.0. > osgi> cacheinfo default frm.workOrder > Info for cache frm.workOrder on container default > LOCKING_PROP = LockingConfiguration{concurrencyLevel=32, isolationLevel=READ_COMMITTED, lockAcquisitionTimeout=10000, useLockStriping=false, writeSkewCheck=false} > TRANSACTION_PROP = TransactionConfiguration{autoCommit=true, cacheStopTimeout=30000, eagerLockingSingleNode=false, lockingMode=OPTIMISTIC, syncCommitPhase=true, syncRollbackPhase=false, transactionManagerLookup=org.infinispan.transaction.lookup.GenericTransactionManagerLookup@1789ff2c, transactionSynchronizationRegistryLookup=null, transactionMode=NON_TRANSACTIONAL, useEagerLocking=false, useSynchronization=true, recovery=RecoveryConfiguration{enabled=true, recoveryInfoCacheName='__recoveryInfoCacheName__'}, reaperWakeUpInterval=1000, completedTxTimeout=15000, use1PcForAutoCommitTransactions=false} > CLUSTERING_PROP = ClusteringConfiguration{async=AsyncConfiguration{asyncMarshalling=false, replicationQueue=null, replicationQueueInterval=5000, replicationQueueMaxElements=1000, useReplicationQueue=false}, cacheMode=REPL_SYNC, hash=HashConfiguration{consistentHashFactory=null, hash=MurmurHash3, numOwners=2, numSegments=60, groupsConfiguration=GroupsConfiguration{enabled=false, groupers=[]}, stateTransferConfiguration=StateTransferConfiguration{chunkSize=10000, fetchInMemoryState=true, originalFetchInMemoryState=null, timeout=240000, awaitInitialTransfer=true, originalAwaitInitialTransfer=null}}, l1=L1Configuration{enabled=false, invalidationThreshold=0, lifespan=600000, onRehash=false, cleanupTaskFrequency=600000}, stateTransfer=StateTransferConfiguration{chunkSize=10000, fetchInMemoryState=true, originalFetchInMemoryState=null, timeout=240000, awaitInitialTransfer=true, originalAwaitInitialTransfer=null}, sync=SyncConfiguration{replTimeout=15000}} The cache has this caractestics Thanks in advance for any leads on what to look for debugging further the issue, Giovanni -- Giovanni Meo Via del Serafico, 200 Telephone: +390651644000 00142, Roma Mobile: +393480700958 Italia Fax: +390651645917 VOIP: 8-3964000 “The pessimist complains about the wind; the optimist expects it to change; the realist adjusts the sails.” -- Wm. Arthur Ward IETF credo: "Rough consensus and running code" _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 11-Sep-13 12:30, Meena Rajani wrote: > Is it because you are doing update in non transcriptional mode? Yeap, as soon as i changed the cache to be transactional the issue is gone. Problem is that i need this cache to be non-transactional so even while a transaction is open the updates are synchronized before the transaction commits. > Is it always the same node which is missing the replicated value? No, sometime also Node1 is missing the entry or Node2, which is very puzzling. Thanks, Giovanni > Meena > > > On Wed, Sep 11, 2013 at 7:44 PM, Giovanni Meo <gmeo(a)cisco.com > <mailto:gmeo@cisco.com>> wrote: > > Hi infinispan-dev, > > i'm having a basic issue with infinispan and i wonder if i can get > some lead on what to look next. I have a cache configured in > replicated/sync mode on a cluster made of 3 nodes. > - Node1 writes a key/value in the cache > - Node2 gets it because i have registered a listener for it and i see > the message being logged > - Node3 never gets it > > no error is raised anywhere. I'm using Infinispan 5.3.0. > > > osgi> cacheinfo default frm.workOrder > > Info for cache frm.workOrder on container default > > LOCKING_PROP = LockingConfiguration{concurrencyLevel=32, > isolationLevel=READ_COMMITTED, lockAcquisitionTimeout=10000, > useLockStriping=false, writeSkewCheck=false} > > TRANSACTION_PROP = > TransactionConfiguration{autoCommit=true, cacheStopTimeout=30000, > eagerLockingSingleNode=false, lockingMode=OPTIMISTIC, syncCommitPhase=true, > syncRollbackPhase=false, > > transactionManagerLookup=org.infinispan.transaction.lookup.GenericTransactionManagerLookup@1789ff2c, > > transactionSynchronizationRegistryLookup=null, > transactionMode=NON_TRANSACTIONAL, useEagerLocking=false, > useSynchronization=true, recovery=RecoveryConfiguration{enabled=true, > recoveryInfoCacheName='__recoveryInfoCacheName__'}, > reaperWakeUpInterval=1000, completedTxTimeout=15000, > use1PcForAutoCommitTransactions=false} > > CLUSTERING_PROP = > ClusteringConfiguration{async=AsyncConfiguration{asyncMarshalling=false, > replicationQueue=null, replicationQueueInterval=5000, > replicationQueueMaxElements=1000, useReplicationQueue=false}, > cacheMode=REPL_SYNC, hash=HashConfiguration{consistentHashFactory=null, > hash=MurmurHash3, numOwners=2, numSegments=60, > groupsConfiguration=GroupsConfiguration{enabled=false, groupers=[]}, > stateTransferConfiguration=StateTransferConfiguration{chunkSize=10000, > fetchInMemoryState=true, originalFetchInMemoryState=null, timeout=240000, > awaitInitialTransfer=true, originalAwaitInitialTransfer=null}}, > l1=L1Configuration{enabled=false, invalidationThreshold=0, lifespan=600000, > onRehash=false, cleanupTaskFrequency=600000}, > stateTransfer=StateTransferConfiguration{chunkSize=10000, > fetchInMemoryState=true, originalFetchInMemoryState=null, timeout=240000, > awaitInitialTransfer=true, originalAwaitInitialTransfer=null}, > sync=SyncConfiguration{replTimeout=15000}} > > The cache has this caractestics > Thanks in advance for any leads on what to look for debugging further the > issue, > Giovanni > > -- > Giovanni Meo > Via del Serafico, 200 Telephone: +390651644000 > 00142, Roma Mobile: +393480700958 > Italia Fax: +390651645917 > VOIP: 8-3964000 > “The pessimist complains about the wind; > the optimist expects it to change; > the realist adjusts the sails.” -- Wm. Arthur Ward > IETF credo: "Rough consensus and running code" > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >