January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3873) Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup)

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3873?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3873: ------------------------------------ Karl, can you post some logs with trace enabled as well? Mostly I'm interested to see what the topologyId of the put command was (logged by StateTransferInterceptor). Waiting for any topology should be enough to make sure all the components of the cache have been started, so I'm not sure how your scenario can happen. In any case, I think all the logic to discard/block commands received before the initial topology id should stay in InboundInvocationHandlerImpl, so I'd rather add a check there instead of AbstractInvocationContextFactory. > Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup) > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3873 > URL: https://issues.jboss.org/browse/ISPN-3873 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 6.0.1.Final > Environment: Ubuntu Linux 12.04_LTS, Oracle Java SE 1.7.0_45 > Reporter: Karl von Randow > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha1 > > > Sometimes when I start one server in a cluster I see the NullPointerException reproduced below. This only occurs if there is another server running. I run multiple caches with clustering using invalidation. JGroups using JDBC_PING and TCP. The caches are non-transactional. > The NPE is because the keyEq (Equivalence instance for keys) is null. I believe this is because the command is processed before the start() method has been called on the AbstractInvocationContextFactory, as the start() method sets the keyEq ivar. > At this point I'm not sure how to fix it! > java.lang.NullPointerException > at org.infinispan.commons.equivalence.EquivalentHashMap.put(EquivalentHashMap.java:176) > at org.infinispan.commons.equivalence.EquivalentHashSet.add(EquivalentHashSet.java:109) > at org.infinispan.context.impl.NonTxInvocationContext.addLockedKey(NonTxInvocationContext.java:84) > at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:190) > at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:181) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:149) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:85) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118) > 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.visitInvalidateCommand(AbstractVisitor.java:111) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118) > 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.visitInvalidateCommand(AbstractVisitor.java:111) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:111) > at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39) > at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48) > at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95) > at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:186) > at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:84) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:259) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:211) > at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460) > at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377) > at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665) > at org.jgroups.JChannel.up(JChannel.java:730) > at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1019) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:182) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) > at org.jgroups.stack.Protocol.up(Protocol.java:409) > at org.jgroups.stack.Protocol.up(Protocol.java:409) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) > at org.jgroups.protocols.RSVP.up(RSVP.java:221) > at org.jgroups.protocols.UNICAST2.removeAndPassUp(UNICAST2.java:919) > at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:800) > at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:415) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147) > at org.jgroups.protocols.FD.up(FD.java:255) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301) > at org.jgroups.protocols.MERGE2.up(MERGE2.java:209) > at org.jgroups.protocols.Discovery.up(Discovery.java:379) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1399) > at org.jgroups.protocols.TP$MyHandler.run(TP.java:1585) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3888) Enums are not serialized properly with IBM JDK 6

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3888?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3888: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha1 Resolution: Done > Enums are not serialized properly with IBM JDK 6 > ------------------------------------------------ > > Key: ISPN-3888 > URL: https://issues.jboss.org/browse/ISPN-3888 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This can cause various issues that cause the overall command to not be serialized properly. For example the topology id could be serialized using the value from the Flag enumset causing it to possibly never be invoked. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3889) L1 Synchronizer should have a timeout

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3889?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3889: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha1 Resolution: Done > L1 Synchronizer should have a timeout > ------------------------------------- > > Key: ISPN-3889 > URL: https://issues.jboss.org/browse/ISPN-3889 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The L1 Synchronizer currently does a get when waiting for a concurrent request to complete. If for some reason the other request doesn't complete this can block forever as well. This has only been seen on IBM JDK 6 though and I think it is related to some issues with that JVM. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3764) ISPN testsuite fails for RHEL6x64 && IBM JDK6

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3764?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3764: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha1 Resolution: Done > ISPN testsuite fails for RHEL6x64 && IBM JDK6 > ---------------------------------------------- > > Key: ISPN-3764 > URL: https://issues.jboss.org/browse/ISPN-3764 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 6.0.0.Final > Environment: RHEL6x64 IBM6 > Reporter: Vitalii Chepeliuk > Assignee: William Burns > Priority: Critical > Labels: 620, testsuite_stability > Fix For: 7.0.0.Alpha1 > > > Sometimes build is stucked and sometiemes it throws following exception when CORE module is running > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!! (testng-DistWriteSkewTest) Exiting because DistWriteSkewTest has NOT shut down all the cache managers it has started !!!!!!! > !!!!!! (testng-DistWriteSkewTest) See allocation stacktrace to find out where still-running cacheManager was created: !!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > java.lang.Throwable > at org.infinispan.test.fwk.TestCacheManagerFactory.addThreadCacheManager(TestCacheManagerFactory.java:373) > at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:356) > at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:68) > at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:160) > at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:151) > at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:125) > at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:177) > at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:162) > at org.infinispan.test.MultipleCacheManagersTest.createCluster(MultipleCacheManagersTest.java:196) > at org.infinispan.container.versioning.AbstractClusteredWriteSkewTest.createCacheManagers(AbstractClusteredWriteSkewTest.java:59) > at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:69) > at org.infinispan.test.MultipleCacheManagersTest.createBeforeMethod(MultipleCacheManagersTest.java:79) > at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > Add link to jenkins job > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3890) Store data in binary format for C/S mode

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3890: ----------------------------------- Summary: Store data in binary format for C/S mode Key: ISPN-3890 URL: https://issues.jboss.org/browse/ISPN-3890 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus Priority: Minor ATM the data is stored as POJO. Storing the data in binary mode would reduce the number of serialization and increase performance. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3888) Enums are not serialized properly with IBM JDK 6

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3888?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3888: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2324 > Enums are not serialized properly with IBM JDK 6 > ------------------------------------------------ > > Key: ISPN-3888 > URL: https://issues.jboss.org/browse/ISPN-3888 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > This can cause various issues that cause the overall command to not be serialized properly. For example the topology id could be serialized using the value from the Flag enumset causing it to possibly never be invoked. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3889) L1 Synchronizer should have a timeout

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3889?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3889: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2324 > L1 Synchronizer should have a timeout > ------------------------------------- > > Key: ISPN-3889 > URL: https://issues.jboss.org/browse/ISPN-3889 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > The L1 Synchronizer currently does a get when waiting for a concurrent request to complete. If for some reason the other request doesn't complete this can block forever as well. This has only been seen on IBM JDK 6 though and I think it is related to some issues with that JVM. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3889) L1 Synchronizer should have a timeout

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3889?page=com.atlassian.jira.plugin.... ] Work on ISPN-3889 started by William Burns. > L1 Synchronizer should have a timeout > ------------------------------------- > > Key: ISPN-3889 > URL: https://issues.jboss.org/browse/ISPN-3889 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > The L1 Synchronizer currently does a get when waiting for a concurrent request to complete. If for some reason the other request doesn't complete this can block forever as well. This has only been seen on IBM JDK 6 though and I think it is related to some issues with that JVM. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3886) StateTransferManager MBean is duplicated in the generated jmxComponents.html

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3886?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3886: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > StateTransferManager MBean is duplicated in the generated jmxComponents.html > ---------------------------------------------------------------------------- > > Key: ISPN-3886 > URL: https://issues.jboss.org/browse/ISPN-3886 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This is caused by management annotations being added on both interface and implementation which causes the tool that generates the jmxComponents.html to duplicate the MBean. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3875) JMX related chapter of user guide is not up to date

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3875?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3875: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > JMX related chapter of user guide is not up to date > ---------------------------------------------------- > > Key: ISPN-3875 > URL: https://issues.jboss.org/browse/ISPN-3875 > Project: Infinispan > Issue Type: Bug > Components: Documentation > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The text implies the user needs to follow certain steps in order to enable jmx (ie enable stats), but mbeans are currently created and registered even if statistics are not enabled. -- 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, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014