April 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-380) Be compliant with JBoss AS logging requirements

by Manik Surtani (JIRA)

Be compliant with JBoss AS logging requirements ----------------------------------------------- Key: ISPN-380 URL: https://jira.jboss.org/jira/browse/ISPN-380 Project: Infinispan Issue Type: Feature Request Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR1, 4.1.0.Final This (JBoss internal) document has details of standardised logging formats and codes, to enable easy i18n, etc. in future. https://docspace.corp.redhat.com/docs/DOC-30217 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
16
0 / 0

[JBoss JIRA] Created: (ISPN-1025) CommandAwareRpcDispatcher.FutureCollator.getResponseList() hangs instead of reporting timeout

by Dan Berindei (JIRA)

CommandAwareRpcDispatcher.FutureCollator.getResponseList() hangs instead of reporting timeout --------------------------------------------------------------------------------------------- Key: ISPN-1025 URL: https://issues.jboss.org/browse/ISPN-1025 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.ALPHA4, 4.2.1.FINAL Reporter: Dan Berindei Assignee: Dan Berindei I only reproduced this once while running the core test suite. FutureCollator.getResponseList() waits in a loop, but only checks for timeout before starting the loop. So if it doesn't get any response it will wait indefinitely. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-1016) Hash-aware view update causing lock ups in Hot Rod

by Galder Zamarreño (JIRA)

Hash-aware view update causing lock ups in Hot Rod -------------------------------------------------- Key: ISPN-1016 URL: https://issues.jboss.org/browse/ISPN-1016 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.2.1.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.2.2.BETA1, 5.0.0.BETA1 When encoding a Hot Rod response, if the encoder discovers that the client has an old view, it decides that a new topology needs to be sent to the client. Now, when building this view in distributed caches, the encoder checks whether in the new view, any of the nodes hash ids has changed, and if so, it sends a cluster wide replace with the view containing the new hash ids. This seems to cause some deadlocks as shown in JBPAPP-6113 where one node is timing to send the replace to other node, and another node is timing out doing the same. This needs further thinking but have some ideas in mind... On top of that, it appears that a failure here is causing problems the requests after that, so some thinking needs to be done to see if that replace() call can be moved out of there... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
8
0 / 0

[JBoss JIRA] Created: (ISPN-1013) Message ids should be logged as decimal

by Galder Zamarreño (JIRA)

Message ids should be logged as decimal --------------------------------------- Key: ISPN-1013 URL: https://issues.jboss.org/browse/ISPN-1013 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.2.1.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Minor Fix For: 4.2.2.BETA1, 5.0.0.BETA1 This is confusing: {code}org.infinispan.client.hotrod.exceptions.InvalidResponseException:: Invalid message id. Expected cfec and received 84b6{code} Message Ids are more readable as numbers rather than hex. The protocol uses hex numbers for things like error codes and those make sense being shown as hex so that they can be easily mapped to the protocol documentation. But for msg ids it should be left as is. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-1010) ClusteredCacheLoader not detecting multiple responses are equal

by Galder Zamarreño (JIRA)

ClusteredCacheLoader not detecting multiple responses are equal --------------------------------------------------------------- Key: ISPN-1010 URL: https://issues.jboss.org/browse/ISPN-1010 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.2.1.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.2.2.BETA1, 5.0.0.BETA1 Infinispan's clustered cache loader does not seem to be capable of dealing with two or more identical responses: {code}[JBoss] org.infinispan.loaders.CacheLoaderException: Response length is always 0 or 1, received: [SuccessfulResponse{responseValue=ImmortalCacheValue{value=TopologyView(2,List(TopologyAddress(172.17.65.254,11222,Map(),perf02-7642), TopologyAddress(172.17.67.254,11222,Map(),perf04-36806)))}} , SuccessfulResponse{responseValue=ImmortalCacheValue{value=TopologyView(2,List(TopologyAddress(172.17.65.254,11222,Map(),perf02-7642), TopologyAddress(172.17.67.254,11222,Map(),perf04-36806)))}} ] [JBoss] at org.infinispan.loaders.cluster.ClusterCacheLoader.load(ClusterCacheLoader.java:57){code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-1020) HotRod client test suite hangs in ClientConnectionPoolingTest.tearDown

by Dan Berindei (JIRA)

HotRod client test suite hangs in ClientConnectionPoolingTest.tearDown ---------------------------------------------------------------------- Key: ISPN-1020 URL: https://issues.jboss.org/browse/ISPN-1020 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 5.0.0.ALPHA4, 4.2.1.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Sometimes the HotRod client test suite stops towards the end. Almost all of the live threads are client worker threads or server threads, the only test method running after a while is ClientConnectionPoolingTest.tearDown: -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-1024) Make Lucene Directory compatible with Lucene 3.1

by Sanne Grinovero (JIRA)

Make Lucene Directory compatible with Lucene 3.1 ------------------------------------------------ Key: ISPN-1024 URL: https://issues.jboss.org/browse/ISPN-1024 Project: Infinispan Issue Type: Enhancement Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.2.2.BETA1, 5.0.0.BETA1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-1026) Lucene demo working fine but fails unit test

by Sanne Grinovero (JIRA)

Lucene demo working fine but fails unit test -------------------------------------------- Key: ISPN-1026 URL: https://issues.jboss.org/browse/ISPN-1026 Project: Infinispan Issue Type: Bug Components: Demos and Tutorials Affects Versions: 5.0.0.ALPHA4 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.0.0.BETA1 JMX stats are enabled, but all nodes are using the same domain name. during a real execution it works fine as they are in different JVMs, though the unit tests fail. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-1017) Livelock creating lots of cache managers in parallel

by Dan Berindei (JIRA)

Livelock creating lots of cache managers in parallel ---------------------------------------------------- Key: ISPN-1017 URL: https://issues.jboss.org/browse/ISPN-1017 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Reporter: Dan Berindei Assignee: Dan Berindei While running the HotRod client test suite I sometimes get a livelock and the thread dump shows a lot of stack traces like this: "pool-2-thread-20" prio=10 tid=0x6a63ec00 nid=0x2d71 runnable [0x6943e000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.get(HashMap.java:320) at org.infinispan.factories.ComponentRegistry.isGlobal(ComponentRegistry.java:138) at org.infinispan.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:130) at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:185) at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:326) at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:254) at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:843) at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:228) at org.infinispan.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:133) at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:185) at org.infinispan.factories.InternalCacheFactory.bootstrap(InternalCacheFactory.java:102) at org.infinispan.factories.InternalCacheFactory.createAndWire(InternalCacheFactory.java:77) at org.infinispan.factories.InternalCacheFactory.createCache(InternalCacheFactory.java:61) at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:538) at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:443) at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:412) at org.infinispan.server.core.AbstractProtocolServer.startDefaultCache(AbstractProtocolServer.scala:108) at org.infinispan.server.core.AbstractProtocolServer.start(AbstractProtocolServer.scala:69) at org.infinispan.server.hotrod.HotRodServer.start(HotRodServer.scala:48) at org.infinispan.server.hotrod.test.HotRodTestingUtil$.startHotRodServer(HotRodTestingUtil.scala:77) at org.infinispan.server.hotrod.test.HotRodTestingUtil$.startHotRodServer(HotRodTestingUtil.scala:57) at org.infinispan.server.hotrod.test.HotRodTestingUtil$.startHotRodServer(HotRodTestingUtil.scala:46) at org.infinispan.server.hotrod.test.HotRodTestingUtil$.startHotRodServer(HotRodTestingUtil.scala:43) at org.infinispan.server.hotrod.test.HotRodTestingUtil$.startHotRodServer(HotRodTestingUtil.scala:37) at org.infinispan.server.hotrod.test.HotRodTestingUtil.startHotRodServer(HotRodTestingUtil.scala) at org.infinispan.client.hotrod.TestHelper.startHotRodServer(TestHelper.java:34) at org.infinispan.client.hotrod.CacheManagerStoppedTest.createCacheManager(CacheManagerStoppedTest.java:31) This seems to be caused by the fact that the componentScopesLookup map is not synchronized and multiple threads write to it at the same time, leaving it in an invalid state. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

5
9
0 / 0

[JBoss JIRA] Created: (ISPN-1038) NullPointerException in L1ManagerImpl during IllegalMonitorTest

by Dan Berindei (JIRA)

NullPointerException in L1ManagerImpl during IllegalMonitorTest --------------------------------------------------------------- Key: ISPN-1038 URL: https://issues.jboss.org/browse/ISPN-1038 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.0.0.BETA1 Reporter: Dan Berindei Assignee: Pete Muir I have seen NPEs with two different stack traces during tests: 1) java.lang.NullPointerException at java.util.AbstractCollection.addAll(AbstractCollection.java:320) at org.infinispan.distribution.L1ManagerImpl.buildInvalidationAddressList(L1ManagerImpl.java:100) at org.infinispan.distribution.L1ManagerImpl.flushCache(L1ManagerImpl.java:56) at org.infinispan.interceptors.DistributionInterceptor.handleWriteCommand(DistributionInterceptor.java:390) at org.infinispan.interceptors.DistributionInterceptor.visitRemoveCommand(DistributionInterceptor.java:218) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:70) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.LockingInterceptor.visitRemoveCommand(LockingInterceptor.java:325) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:70) 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.visitRemoveCommand(AbstractVisitor.java:63) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:70) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:186) at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:139) at org.infinispan.interceptors.DistTxInterceptor.visitRemoveCommand(DistTxInterceptor.java:86) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:70) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:95) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:62) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:63) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:70) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:273) at org.infinispan.CacheDelegate.remove(CacheDelegate.java:226) at org.infinispan.distribution.IllegalMonitorTest.testScenario(IllegalMonitorTest.java:64) 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:636)... Removed 11 stack frames 2) org.infinispan.CacheException: java.lang.NullPointerException at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:116) ... at org.infinispan.distribution.IllegalMonitorTest.testScenario(IllegalMonitorTest.java:63) 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:636) Caused by: java.lang.NullPointerException at org.infinispan.distribution.L1ManagerImpl.addRequestor(L1ManagerImpl.java:47) at org.infinispan.interceptors.DistributionInterceptor.visitPutKeyValueCommand(DistributionInterceptor.java:203) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.LockingInterceptor.visitPutKeyValueCommand(LockingInterceptor.java:297) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76) 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.visitPutKeyValueCommand(AbstractVisitor.java:59) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:186) at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:134) at org.infinispan.interceptors.DistTxInterceptor.visitPutKeyValueCommand(DistTxInterceptor.java:79) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:95) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:62) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:59) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76) ... Looks like cleanupRequestors() should also use synchronization. It might also be better to lock on the requestors map values instead of the keys, as the keys can be also locked by user code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

4
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2011