[infinispan-dev] Basic issue with replicated sync caches

Giovanni Meo gmeo at cisco.com
Wed Sep 25 06:09:01 EDT 2013


Hi infinispan-dev,

sorry for the trouble, so just to close in this topic i figure out the issue 
(not infinispan related) and documented inside:

https://issues.jboss.org/browse/ISPN-3455

In a nutshell this is due to hashCode not being consistent in the cluster for Enum.

Thanks,
Giovanni

On 11-Sep-13 15:26, Giovanni Meo wrote:
> 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 at cisco.com
>> <mailto:gmeo at 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 at 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 at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>

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


More information about the infinispan-dev mailing list