[JBoss JIRA] (ISPN-1996) Failed to prepare view exceptions
by dex chen (JIRA)
dex chen created ISPN-1996:
------------------------------
Summary: Failed to prepare view exceptions
Key: ISPN-1996
URL: https://issues.jboss.org/browse/ISPN-1996
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.1.3.FINAL
Environment: ISPN 5.1.3.Final; Java 7; Cent OS
3-node cluster in replication mode using jgroups-tcp config.
Reporter: dex chen
Assignee: Manik Surtani
I saw lot (re-curring) cache view exceptions (below) when I start up a 3 node cluster.
I am running ISPN 5.1.3 final with replication mode, and jgroup-tcp config.
In this case, I start first 2 nodes first, and later try to join the 3rd node.
=======================================
2012-04-10/12:13:45.714/MDT
[CacheViewInstaller-3,portal1.net-1609] ERROR
org.infinispan.cacheviews.CacheViewsManagerImpl[263] - ISPN000172: Failed
to prepare view CacheView{viewId=832,
members=[portal1.net-1609, portal2.net-11982]}
for cache ispn-cipherkey, rolling back to view CacheView{viewId=831,
members=[portal1.net-1609]}
java.util.concurrent.ExecutionException: org.infinispan.CacheException:
java.lang.IllegalStateException: Cannot prepare new view
CacheView{viewId=832, members=[portal1.net-1609,
portal2.net-11982]} on cache ispn-cipherkey, we have already
committed view CacheView{viewId=844, members=[]}
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:262)
at java.util.concurrent.FutureTask.get(FutureTask.java:119)
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:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
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: org.infinispan.CacheException: java.lang.IllegalStateException:
Cannot prepare new view CacheView{viewId=832,
members=[portal1.net-1609, portal2.net-11982]}
on cache ispn-cipherkey, we have already committed view
CacheView{viewId=844, members=[]}
at org.infinispan.util.Util.rewrapAsCacheException(Util.java:524)
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:172)
at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:488)
at
org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302)
at
org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299)
... 5 more
Caused by: java.lang.IllegalStateException: Cannot prepare new view
CacheView{viewId=832, members=[portal1.net-1609,
portal2.net-11982]} on cache ispn-cipherkey, we have already
committed view CacheView{viewId=844, members=[]}
at
org.infinispan.cacheviews.CacheViewInfo.prepareView(CacheViewInfo.java:107)
at
org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:481)
at
org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:125)
at
org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:221)
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:201)
at
org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456)
at
org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363)
at
org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238)
at
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:543)
at org.jgroups.JChannel.up(JChannel.java:716)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:882)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:595)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
at org.jgroups.protocols.FD.up(FD.java:273)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:282)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
at org.jgroups.protocols.Discovery.up(Discovery.java:359)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1174)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1722)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1704)
... 3 more
2012-04-10/12:13:46.715/MDT
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ISPN-2327) NPE in error log during shutdown of nodes with l1 cache
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2327:
----------------------------------
Summary: NPE in error log during shutdown of nodes with l1 cache
Key: ISPN-2327
URL: https://issues.jboss.org/browse/ISPN-2327
Project: Infinispan
Issue Type: Enhancement
Components: Cache Server
Affects Versions: 5.2.0.Alpha4
Reporter: Thomas Fromm
Assignee: Mircea Markus
Shutdown works, but is not nice to have NPE in error log...
ERROR 15:24:43,515 [OOB-9,ISNode-33962] InvocationContextInterceptor ISPN000136: Execution error
java.lang.NullPointerException
at org.infinispan.commands.write.InvalidateL1Command.perform(InvalidateL1Command.java:109)
at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:83)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:142)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:147)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
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.visitInvalidateCommand(AbstractVisitor.java:142)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:147)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:211)
at org.infinispan.interceptors.EntryWrappingInterceptor.visitInvalidateL1Command(EntryWrappingInterceptor.java:143)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateL1Command(AbstractLockingInterceptor.java:99)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
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.visitInvalidateCommand(AbstractVisitor.java:142)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:147)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.statetransfer.StateTransferInterceptor.visitInvalidateL1Command(StateTransferInterceptor.java:184)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
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.visitInvalidateCommand(AbstractVisitor.java:142)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:147)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:129)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:93)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:142)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:147)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:347)
at org.infinispan.statetransfer.StateConsumerImpl.discardSegments(StateConsumerImpl.java:510)
at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:202)
at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:183)
at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:55)
at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:114)
at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:194)
at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165)
at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:250)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:217)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:480)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:387)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:609)
at org.jgroups.JChannel.up(JChannel.java:715)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
at org.jgroups.protocols.RSVP.up(RSVP.java:172)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
at org.jgroups.protocols.FC.up(FC.java:479)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:704)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:536)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:177)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
at org.jgroups.protocols.Discovery.up(Discovery.java:359)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1210)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1774)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1747)
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)
--
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
11 years, 5 months
[JBoss JIRA] (ISPN-2418) CLONE - Cache restart doesn't work properly
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-2418:
-------------------------------------
Summary: CLONE - Cache restart doesn't work properly
Key: ISPN-2418
URL: https://issues.jboss.org/browse/ISPN-2418
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.1.7.Final, 5.2.0.Alpha3
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.2.0.Final, 5.1.9.Final
Cache restart has at least two issues:
1. If a cache is stopped via {{Cache.stop()}} it will still be returned by {{DefaultCacheManager.getCache()}}. Cache {{start()}} and {{stop()}} are not synchronized in any way, so a {{start()}} call may return before the cache was properly started - just because another thread is in the process of starting it.
2. {{ComponentRegistry}} keeps a few components as fields to speed up access. These components are destroyed on {{stop()}} and re-created on {{start()}}, because they are volatile, but the field references are not updated.
Also, the documentation of {{EmbeddedCacheManager.getCache()}} should say that it will start the cache only if it doesn't exist yet - if the cache is stopped it will return the cache as it was. Alternatively we could change the behaviour of {{getCache()}} to always start the cache.
--
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
11 years, 5 months
[JBoss JIRA] (ISPN-2172) Cache removals not removing L1 cached values in non-owners
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-2172:
--------------------------------------
Summary: Cache removals not removing L1 cached values in non-owners
Key: ISPN-2172
URL: https://issues.jboss.org/browse/ISPN-2172
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 5.2.0.ALPHA2, 5.1.5.FINAL
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Priority: Critical
Fix For: 5.2.0.ALPHA3, 5.2.0.FINAL
There appears to be an issue L1 and removals.
Seems like on removal, non-owners are not invalidated and data is left in memory.
If using a Hot Rod server, it would appear as if the remote get operations don't return anything after removal is cos it goes to an owner node, where data is indeed removed.
However, if you try to build a test case with embedded cache, it clearly shows that after removal, data is left in memory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ISPN-1731) Threads waiting for key locks should not block state transfer
by Dan Berindei (JIRA)
Dan Berindei created ISPN-1731:
----------------------------------
Summary: Threads waiting for key locks should not block state transfer
Key: ISPN-1731
URL: https://issues.jboss.org/browse/ISPN-1731
Project: Infinispan
Issue Type: Task
Components: State transfer
Affects Versions: 5.1.0.CR3, 5.0.1.FINAL
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.2.0.FINAL
A write/lock command holds the state transfer lock for its entire duration, including while waiting to acquire key locks. Because of this, we can get a deadlock scenario:
1. Tx1 waits for key k1 while holding the state transfer lock
2. State transfer waits for Tx1 while blocking new write commands
3. Tx2 waits for state transfer to end while holding the k1 lock
The only way out of this scenario at the moment is for Tx1 to time out and fail to acquire the lock. We should make it possible to release the state transfer lock temporarily and return to waiting for the key lock after state transfer has ended.
ISPN-1424 might make this issue obsolete.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ISPN-2466) Unlock called twice doesn't behave correctly
by Mircea Markus (JIRA)
Mircea Markus created ISPN-2466:
-----------------------------------
Summary: Unlock called twice doesn't behave correctly
Key: ISPN-2466
URL: https://issues.jboss.org/browse/ISPN-2466
Project: Infinispan
Issue Type: Feature Request
Components: Locking and Concurrency
Affects Versions: 5.2.0.Beta3
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 5.2.0.CR1
Taken from ISPN-2458:
<snip>
When the lock is acquired after the first unlock, the second unlock fails with IllegalMonitorStateException in OwnableReentrantLock.tryAcquire(...), but the reference count is still decremented in AbstractPerEntryLockContainer.releaseLock(...). This results in further IllegalStateException: Negative reference count for lock.
</snip>
Even if the ISE occurs, the lock counter should not be affected.
--
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
11 years, 5 months
[JBoss JIRA] (ISPN-2458) Double unlock during rollback breaks reference counting
by Radim Vansa (JIRA)
Radim Vansa created ISPN-2458:
---------------------------------
Summary: Double unlock during rollback breaks reference counting
Key: ISPN-2458
URL: https://issues.jboss.org/browse/ISPN-2458
Project: Infinispan
Issue Type: Bug
Components: Locking and Concurrency
Affects Versions: 5.2.0.Beta3
Reporter: Radim Vansa
Assignee: Mircea Markus
Priority: Critical
Using pessimistic locking, when a transaction is rolled-back, {{RollbackCommand}} and then {{TxCompletionNotification}} commands are sent to the primary owner. When the order of these two changes, the locks are unlocked twice: first by {{TxCompletionNotification}} calling {{LockManagerImpl.unlock(Collection<Object> lockedKeys, Object lockOwner)}} and then by {{AbstractTxLockingInterceptor.visitRollbackCommand}} calling {{LockManagerImpl.unlockAll(...)}}
When the lock is acquired after the first unlock, the second unlock fails with IllegalMonitorStateException in {{OwnableReentrantLock.tryAcquire(...)}}, but the reference count is still decremented in {{AbstractPerEntryLockContainer.releaseLock(...)}}. This results in further IllegalStateException: Negative reference count for lock
--
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
11 years, 5 months
[JBoss JIRA] (ISPN-2463) Clean up Configuration API in test suites
by Navin Surtani (JIRA)
Navin Surtani created ISPN-2463:
-----------------------------------
Summary: Clean up Configuration API in test suites
Key: ISPN-2463
URL: https://issues.jboss.org/browse/ISPN-2463
Project: Infinispan
Issue Type: Task
Components: Test Suite
Affects Versions: 5.2.0.CR1
Reporter: Navin Surtani
Assignee: Navin Surtani
Fix For: 5.2.0.CR1
The test-suite currently uses older, previous implementations of configuring Infinispan. These approaches are currently deprecated and for ease of maintenance it would be useful to clean up the approach used to configure Infinispan within the test-suite.
--
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
11 years, 5 months