[JBoss JIRA] Created: (ISPN-1101) Race conditions in MarshalledValue equals & hashcode
by Sanne Grinovero (JIRA)
Race conditions in MarshalledValue equals & hashcode
----------------------------------------------------
Key: ISPN-1101
URL: https://issues.jboss.org/browse/ISPN-1101
Project: Infinispan
Issue Type: Bug
Components: Core API
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 5.0.0.CR2
I've spotted some race conditions in MarshalledValue; all quite unlikely still I have some suggested improvements:
- serialize() is synchronized but other methods relying on the value of "raw" are not, and serialize is modifying the value of raw[] with System.arraycopy which is not an atomic operation.
- equals() implementation is relying on the fact that instance values don't change while it's figuring out the best strategy to perform the comparison (race condition between checking for the need to serialize or deserialize and actually using the value)
- same race condition in hashCode() as well
- some volatile fields are read and written multiple times in the same method, I'll make local copies instead
- equalityPreferenceForInstance is applied inconsistently: in first part of equals implementation only the this.equalityPreferenceForInstance is considered, while in case we need to do some serialization/deserialization then the preference is decided by considering the equalityPreferenceForInstance variable of both values in &&.
- compact() is missing some lock/synch, it a very unlikely race condition is possible in which the data is completely lost (nulling out both raw and instance valueholders)
- System.arraycopy makes a copy of the buffer used by the marshaller, but that's not needed as defensive copy because the ExposedByteArrayOutputStream is discarded: don't copy it if there's no need to resize the buffer.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (ISPN-1093) If an exception occurs during one phase commit optimization the local cache changes are still applied
by William Burns (JIRA)
If an exception occurs during one phase commit optimization the local cache changes are still applied
-----------------------------------------------------------------------------------------------------
Key: ISPN-1093
URL: https://issues.jboss.org/browse/ISPN-1093
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 4.2.1.FINAL
Reporter: William Burns
Assignee: Manik Surtani
I had been implementing infinispan clustered cache with transactions. When a rollback for a transaction occurs it will not push the changes to the local cache.
However I found that if a one phase commit optimization is done where infispan is the one resource and a node in the clustered is found in a Suspect state while preparing that it will throw a RollbackException, which is great. However the local node still pushes the changes to the cache which then puts that local cache in an inconsistent state with the rest of the nodes in the cluster, since they were not pushed the updates.
Here is a snippet of the trace when this occurs
1 ider T 10:18:52,698 (Transactio) [0] Committing transaction GlobalTransaction:<wburns-53118>:6:local
1 ider T 10:18:52,698 (Transactio) [0] Doing an 1PC prepare call on the interceptor chain
1 ider T 10:18:52,698 (Invocation) [0] Invoked with command PrepareCommand {gtx=GlobalTransaction:<wburns-53118>:6:local, modifications=[RemoveCommand{key=key, value=null, flags=null}], onePhaseCommit=true, gtx=GlobalTransaction:<wburns-53118>:6:local, cacheName='test'} and InvocationContext [LocalTxInvocationContext{flags=null}]
1 ider T 10:18:52,698 (CallInterc) [0] Suppressing invocation of method handlePrepareCommand.
1 ider T 10:18:52,698 (Distributi) [0] Not performing invalidation! isL1CacheEnabled? true numCallRecipients=2
1 ider T 10:18:52,699 (RpcManager) [0] wburns-53118 broadcasting call PrepareCommand {gtx=GlobalTransaction:<wburns-53118>:6:local, modifications=[RemoveCommand{key=key, value=null, flags=null}], onePhaseCommit=true, gtx=GlobalTransaction:<wburns-53118>:6:local, cacheName='test'} to recipient list [wburns-38125, wburns-53118]
1 ider T 10:18:52,699 (JGroupsTra) [0] dests=[wburns-38125, wburns-53118], command=PrepareCommand {gtx=GlobalTransaction:<wburns-53118>:6:local, modifications=[RemoveCommand{key=key, value=null, flags=null}], onePhaseCommit=true, gtx=GlobalTransaction:<wburns-53118>:6:local, cacheName='test'}, mode=SYNCHRONOUS, timeout=15000
1 ider T 10:18:52,701 (CommandAwa) [0] Replication task sending PrepareCommand {gtx=GlobalTransaction:<wburns-53118>:6:local, modifications=[RemoveCommand{key=key, value=null, flags=null}], onePhaseCommit=true, gtx=GlobalTransaction:<wburns-53118>:6:local, cacheName='test'} to addresses [wburns-38125, wburns-53118]
1 ider T 10:18:52,703 (JBossMarsh) [0] Start marshaller after retrieving marshaller from thread local
1 ider T 10:18:52,703 (VersionAwa) [0] Wrote version 420
1 ider T 10:18:52,704 (JBossMarsh) [0] Stop marshaller
1 ider T 10:18:52,704 (CommandAwa) [0] real_dests=[wburns-38125]
37 ider T 10:18:52,720 (JGroupsDis) Closing joinInProgress gate
37 ider I 10:18:53,028 (JGroupsTra) Received new cluster view: [wburns-53118|2] [wburns-53118]
1 ider T 10:18:53,032 (CommandAwa) [0] Responses: [sender=wburns-38125, retval=null, received=false, suspected=true]
37 ider T 10:18:53,028 (Transactio) Saw 1 leavers - kicking off a lock breaking task
1 ider T 10:18:53,034 (RpcManager) [0] replication exception:
org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: wburns-38125
.... full stack trace removed for clarity ....
1 ider T 10:18:53,037 (DistLockin) [0] Number of entries in context: 1
41 ider T 10:18:53,036 (Transactio) No global transactions pertain to originator(s) [wburns-38125] who have left the cluster.
37 ider I 10:18:53,036 (Distributi) Detected a view change. Member list changed from [wburns-53118, wburns-38125] to [wburns-53118]
41 ider T 10:18:53,038 (Transactio) Completed cleaning stale locks.
37 ider I 10:18:53,038 (Distributi) This is a LEAVE event! Node wburns-38125 has just left
1 ider T 10:18:53,038 (ReadCommit) [0] Updating entry (key=key removed=true valid=false changed=true created=false value=com.redprairie.moca.cache.Maybe@5bd6c768]
1 ider T 10:18:53,039 (DistLockin) [0] Releasing lock on [key] for owner GlobalTransaction:<wburns-53118>:6:local
37 ider T 10:18:53,039 (Distributi) Added new leaver wburns-38125, leavers list is [wburns-38125]
1 ider T 10:18:53,039 (LockManage) [0] Attempting to unlock key
1 ider E 10:18:53,039 (Invocation) [0] Execution error:
org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: wburns-38125
.... full stack trace removed for clarity ....
1 ider T 10:18:53,041 (Invocation) [0] Transaction marked for rollback as exception was received.
1 ider T 10:18:53,041 (jta ) [0] TransactionImple.getStatus
1 ider E 10:18:53,041 (Transactio) [0] Error while processing 1PC PrepareCommand
org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: wburns-38125
.... full stack trace removed for clarity ....
1 ider T 10:18:53,043 (jta ) [0] TransactionImple.equals
37 ider T 10:18:53,040 (Distributi) wburns-53118 is looking for a new backup to replace leaver wburns-38125
37 ider T 10:18:53,044 (Distributi) Leaver wburns-38125 main backup wburns-53118 is looking for another backup as well.
37 ider T 10:18:53,044 (Distributi) Nodes that need new backups are: [wburns-53118, wburns-53118]
37 ider T 10:18:53,044 (Distributi) This node won't receive state
37 ider I 10:18:53,044 (Distributi) I wburns-53118 am participating in rehash, state providers [wburns-53118, wburns-53118], state receivers [wburns-53118, wburns-53118]
1 ider W 10:18:53,045 (jta ) [0] ARJUNA-16039 onePhaseCommit on < formatId=131076, gtrid_length=29, bqual_length=28, tx_uid=0:ffff0a0302c6:ba1e:4dc805d1:16, node_name=1, branch_uid=0:ffff0a0302c6:ba1e:4dc805d1:17, eis_name=unknown eis name > (TransactionXaAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=TransactionImple < ac, BasicAction: 0:ffff0a0302c6:ba1e:4dc805d1:16 status: ActionStatus.COMMITTING >, xid=< formatId=131076, gtrid_length=29, bqual_length=28, tx_uid=0:ffff0a0302c6:ba1e:4dc805d1:16, node_name=1, branch_uid=0:ffff0a0302c6:ba1e:4dc805d1:17, eis_name=unknown eis name >} org.infinispan.transaction.xa.LocalTransaction@9c35300f}) failed with exception XAException.XAER_RMERR
javax.transaction.xa.XAException
.... full stack trace removed for clarity ....
1 ider T 10:18:53,046 (arjuna ) [0] BasicAction::removeChildThread () action 0:ffff0a0302c6:ba1e:4dc805d1:16 removing TSThread:1
1 ider T 10:18:53,046 (arjuna ) [0] BasicAction::removeChildThread () action 0:ffff0a0302c6:ba1e:4dc805d1:16 removing TSThread:1 result = true
1 ider T 10:18:53,047 (arjuna ) [0] TransactionReaper::remove ( BasicAction: 0:ffff0a0302c6:ba1e:4dc805d1:16 status: ActionStatus.ABORTED )
RollbackException encountered - ARJUNA-16053 Could not commit transaction.
1 ider T 10:18:53,047 (jta ) [0] BaseTransaction.begin
The significant line is
1 ider T 10:18:53,038 (ReadCommit) [0] Updating entry (key=key removed=true valid=false changed=true created=false value=com.redprairie.moca.cache.Maybe@5bd6c768]
where in the ReadCommited isolation level still pushed the remove call that should have been rolled back.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (ISPN-1100) TransactionLogger Not Unlocked/Disabled
by Shane Johnson (JIRA)
TransactionLogger Not Unlocked/Disabled
---------------------------------------
Key: ISPN-1100
URL: https://issues.jboss.org/browse/ISPN-1100
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 4.2.1.FINAL
Reporter: Shane Johnson
Assignee: Manik Surtani
If rehashing is DISABLED, the transaction logger is NOT unlocked and disabled for sender / receivers.
Typically the process is as follows:
1) Enable the transaction logger. (DistributionManagerImpl.rehash)
2) Submit InvertedLeaveTask. (DistributionManagerImpl.rehash)
3) Block new transactions if this is a receiver. (InvertedLeaveTask.performRehash)
4) Process / Drain transaction log if this is a sender. (InvertedLeaveTask.performRehash)
5) Unblock new transactions if this is a receiver.
The problem is that step 4 is only performed if rehashing is enabled. This is the step that eventually unlocks and disables the transaction logger.
Our temporary fix was to add an 'else' block that called 'processAndDrainTxLog'.
if (configuration.isRehashEnabled()) {
...
}
else {
processAndDrainTxLog(oldCH, newCH, replCount);
}
So far, it seems to be working. Our cluster is stable.
Of note is that we did not keep the 'isSender' check. When we used it, the transaction log remained enabled on any node that was ONLY a receiver.
I suspect this is because during a standard rehash the RemoteTransactionLogger sends a RehashControlCommand that ultimately unlocks and disables the transaction logger? This would place the responsibility on the sender and ensure that ALL receivers do so.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (ISPN-1008) Conditional replace/remove not returning previous value in Java Hot Rod client
by Galder Zamarreño (JIRA)
Conditional replace/remove not returning previous value in Java Hot Rod client
------------------------------------------------------------------------------
Key: ISPN-1008
URL: https://issues.jboss.org/browse/ISPN-1008
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Affects Versions: 5.0.0.ALPHA3, 4.2.1.FINAL
Reporter: Galder Zamarreño
Assignee: Mircea Markus
Fix For: 5.0.0.CR1
The following RemoteCache APIs (and their variants) are not correctly defined:
boolean replaceWithVersion(K key, V newValue, long version);
boolean removeWithVersion(K key, long version);
The protocol allows for the previous value to be returned if Flag.FORCE_RETURN_VALUE is used, and these APIs do not accomodate that.
We should think whether it makes sense to keep the protocol as is. Does returning previous value help at all with conditional operations like these?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (ISPN-530) Hot Rod client should load balance between different owners for a key
by Galder Zamarreno (JIRA)
Hot Rod client should load balance between different owners for a key
---------------------------------------------------------------------
Key: ISPN-530
URL: https://jira.jboss.org/browse/ISPN-530
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Reporter: Galder Zamarreno
Assignee: Mircea Markus
Fix For: 5.0.0.BETA1
While doing the demo for JUDCon, I realised that smart routing on the client side always choses the same node for the same key.
IOW, assume you have k1 stored in nodes A, B and the cluster is formed of nodes A, B and C. Now, when the client figures out that the owner is A, any further requests on k1 will be sent to A. This has the possibility of overloading A.
I think the client should, from the given list of owners of a key, do round robin between them for requests on the same key.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (ISPN-997) getting java.io.IOException: Unsupported protocol version 48
by Kavita Patil (JIRA)
getting java.io.IOException: Unsupported protocol version 48
------------------------------------------------------------
Key: ISPN-997
URL: https://issues.jboss.org/browse/ISPN-997
Project: Infinispan
Issue Type: Bug
Components: Cache Server, Marshalling
Affects Versions: 4.2.0.Final
Environment: Red Hat 3.4.6-2
Reporter: Kavita Patil
Assignee: Manik Surtani
Hi,
I Have a 2 infinispan node cluster setup. I am facing problem when i try to access the cache entries inserted in Node1 from Node2. I am using JDBC shared cacheloader. Exception looks like below..
Reading the keys inserted in Node1
Mar 16, 2011 1:57:44 AM org.infinispan.loaders.jdbc.JdbcUtil unmarshall
SEVERE: I/O error while unmarshalling from stream
java.io.IOException: Unsupported protocol version 48
at org.jboss.marshalling.river.RiverUnmarshaller.doStart(RiverUnmarshaller.java:1167)
at org.jboss.marshalling.AbstractUnmarshaller.start(AbstractUnmarshaller.java:389)
at org.infinispan.marshall.jboss.GenericJBossMarshaller.startObjectInput(GenericJBossMarshaller.java:169)
at org.infinispan.marshall.VersionAwareMarshaller.startObjectInput(VersionAwareMarshaller.java:155)
at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:112)
at org.infinispan.marshall.AbstractStreamingMarshaller.objectFromInputStream(AbstractStreamingMarshaller.java:23)
at org.infinispan.loaders.jdbc.JdbcUtil.unmarshall(JdbcUtil.java:88)
at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.readStoredEntry(JdbcStringBasedCacheStore.java:371)
at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.loadLockSafe(JdbcStringBasedCacheStore.java:296)
at org.infinispan.loaders.LockSupportCacheStore.load(LockSupportCacheStore.java:100)
at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:149)
at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeededAndUpdateStats(CacheLoaderInterceptor.java:218)
at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:89)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:59)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:88)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:59)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:169)
at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:160)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:59)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:87)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:58)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:88)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:59)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:273)
at org.infinispan.CacheDelegate.get(CacheDelegate.java:207)
at com.hp.uup.cache.examples.EmbeddedCacheClusterNode2.main(EmbeddedCacheClusterNode2.java:58)
Mar 16, 2011 1:57:44 AM org.infinispan.interceptors.InvocationContextInterceptor handleAll
SEVERE: Execution error:
org.infinispan.loaders.CacheLoaderException: I/O error while unmarshalling from stream
at org.infinispan.loaders.jdbc.JdbcUtil.unmarshall(JdbcUtil.java:92)
at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.readStoredEntry(JdbcStringBasedCacheStore.java:371)
at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.loadLockSafe(JdbcStringBasedCacheStore.java:296)
at org.infinispan.loaders.LockSupportCacheStore.load(LockSupportCacheStore.java:100)
at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:149)
at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeededAndUpdateStats(CacheLoaderInterceptor.java:218)
at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:89)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:59)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:88)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:59)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:169)
at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:160)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:59)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:87)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:58)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:88)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:59)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:273)
at org.infinispan.CacheDelegate.get(CacheDelegate.java:207)
at com.hp.uup.cache.examples.EmbeddedCacheClusterNode2.main(EmbeddedCacheClusterNode2.java:58)
Caused by: java.io.IOException: Unsupported protocol version 48
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (ISPN-862) XAResource.isSameRM is not implemented correctly
by Mircea Markus (JIRA)
XAResource.isSameRM is not implemented correctly
------------------------------------------------
Key: ISPN-862
URL: https://issues.jboss.org/browse/ISPN-862
Project: Infinispan
Issue Type: Bug
Affects Versions: 4.2.0.Final
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.0.0.BETA1
XAResource.isSameRM is described withing "3.4.9 Identifying Resource Manager Instance" of JTA spec.
Discussing this with Jonathan Halliday a cluster itself should be seen as a ResourceManager, which means that the semantic of XAResource.isSameRM(XAResource) is as follows:
- if it is the same type as ours (TransactionXAResource)
AND
- other's cluster name is same as ours
then return true. False in all other situations.
Current implementation returns true if and only of the two TransactionXAResource implementations are associated with the same Transaction object.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months