January 2014 - infinispan-issues - Jboss List Archives

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

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3875?page=com.atlassian.jira.plugin.... ] Work on ISPN-3875 started by Adrian Nistor. > 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

10 years, 3 months

1
0
0 / 0

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

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3875?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3875: -------------------------------- Fix Version/s: 7.0.0.Alpha1 7.0.0.Final > 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

10 years, 3 months

1
0
0 / 0

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

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-3875: ----------------------------------- Summary: 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 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3867) L1 cache of ISPN server cannot be enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3867?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3867: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1047860|https://bugzilla.redhat.com/show_bug.cgi?id=1047860] from POST to MODIFIED > L1 cache of ISPN server cannot be enabled > ----------------------------------------- > > Key: ISPN-3867 > URL: https://issues.jboss.org/browse/ISPN-3867 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final, 6.0.0.Final > Reporter: Martin Gencur > Assignee: William Burns > Priority: Critical > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > L1 cache in the server distribution cannot be enabled. The problem is in DistributedCacheAdd:100: > The file should include > builder.clustering().l1().enable().lifespan(lifespan); > instead of > builder.clustering().l1().lifespan(lifespan); -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3801) Test for jgroups auth/encrypt protocols fails on IBM7

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3801?page=com.atlassian.jira.plugin.... ] Martin Gencur resolved ISPN-3801. --------------------------------- Assignee: Jakub Markos (was: Mircea Markus) Resolution: Done > Test for jgroups auth/encrypt protocols fails on IBM7 > ----------------------------------------------------- > > Key: ISPN-3801 > URL: https://issues.jboss.org/browse/ISPN-3801 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Environment: ibm java 1.7 > Reporter: Jakub Markos > Assignee: Jakub Markos > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The test is in infinispan-server ( https://github.com/infinispan/infinispan-server/blob/master/testsuite/src... ), and it uses keystores generated with oracle java. IBMs java 1.7 has problems loading these keystores ( https://www.ibm.com/developerworks/community/forums/html/topic?id=7777777... ). > Fix is to use a keystore generated with ibm7 when the test is run under ibm7. > I'll send a PR once the infinispan-server project is migrated to infinispan. -- 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3801) Test for jgroups auth/encrypt protocols fails on IBM7

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3801?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3801: -------------------------------- Fix Version/s: 7.0.0.Alpha1 7.0.0.Final > Test for jgroups auth/encrypt protocols fails on IBM7 > ----------------------------------------------------- > > Key: ISPN-3801 > URL: https://issues.jboss.org/browse/ISPN-3801 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Environment: ibm java 1.7 > Reporter: Jakub Markos > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The test is in infinispan-server ( https://github.com/infinispan/infinispan-server/blob/master/testsuite/src... ), and it uses keystores generated with oracle java. IBMs java 1.7 has problems loading these keystores ( https://www.ibm.com/developerworks/community/forums/html/topic?id=7777777... ). > Fix is to use a keystore generated with ibm7 when the test is run under ibm7. > I'll send a PR once the infinispan-server project is migrated to infinispan. -- 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

10 years, 3 months

1
0
0 / 0

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

by Karl von Randow (JIRA)

[ https://issues.jboss.org/browse/ISPN-3873?page=com.atlassian.jira.plugin.... ] Karl von Randow commented on ISPN-3873: --------------------------------------- I've investigated another issue, and I think this does cause a serious issue - it has acquired a lock. I see the following exception again and again, and the Incoming-9 thread identified as holding the lock is the thread that gets the NullPointerException on startup. So we do need to workaround this issue for our production environment. At the moment I'm just restarting the system until it doesn't get the exception on start up. I will start looking for a more permanent fix! org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [film-poster-data-51858] for requestor [Thread[ajp-bio-20001-exec-281,5,main]]! Lock held by [Thread[Incoming-9,letterboxd3,app1-1107,5,]] at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198) 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.lockKey(AbstractLockingInterceptor.java:145) at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:69) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70) 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.visitPutKeyValueCommand(AbstractVisitor.java:32) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148) at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70) 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.visitPutKeyValueCommand(AbstractVisitor.java:32) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306) at org.infinispan.CacheImpl.putInternal(CacheImpl.java:878) at org.infinispan.CacheImpl.put(CacheImpl.java:870) at org.infinispan.DecoratedCache.put(DecoratedCache.java:471) > 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3867) L1 cache of ISPN server cannot be enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3867?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3867: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1047860|https://bugzilla.redhat.com/show_bug.cgi?id=1047860] from NEW to POST > L1 cache of ISPN server cannot be enabled > ----------------------------------------- > > Key: ISPN-3867 > URL: https://issues.jboss.org/browse/ISPN-3867 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final, 6.0.0.Final > Reporter: Martin Gencur > Assignee: William Burns > Priority: Critical > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > L1 cache in the server distribution cannot be enabled. The problem is in DistributedCacheAdd:100: > The file should include > builder.clustering().l1().enable().lifespan(lifespan); > instead of > builder.clustering().l1().lifespan(lifespan); -- 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

10 years, 3 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3764?page=com.atlassian.jira.plugin.... ] Work on ISPN-3764 started by William Burns. > 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 > > 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

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3867) L1 cache of ISPN server cannot be enabled

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3867?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3867: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha1 7.0.0.Final Resolution: Done > L1 cache of ISPN server cannot be enabled > ----------------------------------------- > > Key: ISPN-3867 > URL: https://issues.jboss.org/browse/ISPN-3867 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final, 6.0.0.Final > Reporter: Martin Gencur > Assignee: William Burns > Priority: Critical > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > L1 cache in the server distribution cannot be enabled. The problem is in DistributedCacheAdd:100: > The file should include > builder.clustering().l1().enable().lifespan(lifespan); > instead of > builder.clustering().l1().lifespan(lifespan); -- 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

10 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014