[JBoss JIRA] (ISPN-3685) HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3685?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3685:
--------------------------------
Labels: 620 (was: )
> HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3685
> URL: https://issues.jboss.org/browse/ISPN-3685
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.CR1
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
> Labels: 620
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> During process of HotRod Rolling Upgrades from cluster of 2 JDG 6.1.GA nodes to 2 JDG 6.2.ER3.2 nodes, we are blocked by this exception while calling recordKnownGlobalKeyset operation on "old" cluster:
> java.io.IOException: java.lang.ClassNotFoundException: org.infinispan.CacheException
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1775)
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$MessageReceiver$1.run(ClientConnection.java:455)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.ClassNotFoundException: org.infinispan.CacheException
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:947)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1259)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:72)
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1766)
> ... 4 more
> This is also the same for Infinispan Server build from upstream, so it shouldn't be product specific.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (ISPN-3589) StackOverflow in InternalMetadataImpl.Externalizer
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3589?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3589:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> StackOverflow in InternalMetadataImpl.Externalizer
> --------------------------------------------------
>
> Key: ISPN-3589
> URL: https://issues.jboss.org/browse/ISPN-3589
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: 620
> Fix For: 6.0.0.CR2
>
>
> the implementation delegates to another metadata some methods. The result is a chain of InternalMetadataImpl as you can see in:
> {code}
> metadata=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Inte
> rnalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl
> {actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Internal
> MetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{act
> ual=InternalMetadataImpl [....]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (ISPN-3678) In replicated mode writeSkew check is executed only on coordinator
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3678?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3678:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 6.0.0.CR2
Resolution: Done
> In replicated mode writeSkew check is executed only on coordinator
> ------------------------------------------------------------------
>
> Key: ISPN-3678
> URL: https://issues.jboss.org/browse/ISPN-3678
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 6.0.0.CR2
>
>
> Write skew check should be always performed on primary owner - however, in replicated and invalidation modes this is executed only on the coordinator (and primary owner). The bug is in ClusterDependentLogic.InvalidationLogic.
> As a result, two conditional commands (e.g putIfAbsent) may both succeed to set the value.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (ISPN-3657) L1WriteSynchronizer exception on L1 write race
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3657?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3657:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 6.0.0.CR2
Resolution: Done
> L1WriteSynchronizer exception on L1 write race
> ----------------------------------------------
>
> Key: ISPN-3657
> URL: https://issues.jboss.org/browse/ISPN-3657
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: William Burns
> Labels: 620
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> {noformat}java.lang.IllegalStateException: There is already a L1WriteSynchronizer associated with key: *|tempIndexName
> at org.infinispan.distribution.L1ManagerImpl.registerL1WriteSynchronizer(L1ManagerImpl.java:278)
> at org.infinispan.interceptors.distribution.L1NonTxInterceptor.performL1Lookup(L1NonTxInterceptor.java:109)
> at org.infinispan.interceptors.distribution.L1NonTxInterceptor.performCommandWithL1WriteIfAble(L1NonTxInterceptor.java:88)
> at org.infinispan.interceptors.distribution.L1NonTxInterceptor.visitGetKeyValueCommand(L1NonTxInterceptor.java:76)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:113)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitGetKeyValueCommand(NonTransactionalLockingInterceptor.java:34)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:237)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> at org.infinispan.CacheImpl.get(CacheImpl.java:368)
> at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)
> at org.infinispan.lucene.impl.FileListOperations.getFileList(FileListOperations.java:43)
> at org.infinispan.lucene.impl.DirectoryImplementor.fileExists(DirectoryImplementor.java:64)
> at org.infinispan.lucene.impl.DirectoryLuceneV3.fileExists(DirectoryLuceneV3.java:72)
> at org.apache.lucene.index.SegmentInfo.addIfExists(SegmentInfo.java:637)
> at org.apache.lucene.index.SegmentInfo.files(SegmentInfo.java:662)
> at org.apache.lucene.index.SegmentInfos.files(SegmentInfos.java:851)
> at org.apache.lucene.index.IndexFileDeleter.incRef(IndexFileDeleter.java:480)
> at org.apache.lucene.index.IndexFileDeleter.checkpoint(IndexFileDeleter.java:453)
> at org.apache.lucene.index.IndexWriter.checkpoint(IndexWriter.java:3039)
> at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3591)
> at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:3376)
> at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3485)
> at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3467)
> at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3451)
> at org.infinispan.lucene.profiling.LuceneWriterThread.testLoop(LuceneWriterThread.java:40){noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (ISPN-3556) When LockControlCommand fails on an owner, the rollback command is not sent
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3556?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3556 started by Pedro Ruivo.
> When LockControlCommand fails on an owner, the rollback command is not sent
> ---------------------------------------------------------------------------
>
> Key: ISPN-3556
> URL: https://issues.jboss.org/browse/ISPN-3556
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.7.Final, 5.3.0.Final, 6.0.0.Beta1
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> If a transaction starts with a {{lock()}} operation and the lock fails on one of the owners (e.g. because of a {{SuspectException}}), the rollback command should still be sent to all the live owners.
> However, because a locked key is only registered in the {{affectedKeys}} collection after a successful lock operation (in {{PessimisticLockingInterceptor.acquireRemoteIfNeeded()}}, the rollback command is not sent to any owners.
> This is in a pessimistic cache. However, looking at the {{OptimisticLockingInterceptor.acquireAllLocks()}} code I think I see a similar problem: it's possible that a key is locked, but the write skew check fails and the key is not added to the {{affectedKeys}} collection. We should always register the key first and attempt to lock it after.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months