[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-3767:
-------------------------------------
Romain, you do not say on which version you're running. The first branch you sent was based on an old 6 (mid October) and the second on 5.2.4. I would recommend migrating to 6.0.0.Final.
Also, let's keep the mass indexing on a one-node cluster being broken and indexing slowness as separate issues.
Looking at the first branch, it's quite old, so I applied the same changes on current version of DistributedMassIndexingTest. Running it with 1 or 2 nodes fails the asserts right after the index rebuild. Running with 3, 4, 5 ... nodes works. A quick analysis leads me to believe it's caused by indexing not being fully synchronous. MassIndexer.start() should only return after the index was rebuilt, but unfortunately it seems to return right after reindexing work was performed but without any guarantee it was actually flushed. I'll fix this during this week.
Right now, a quick workaround to confirm this : replace enqueueAsyncWork with doWorkInSync at https://github.com/infinispan/infinispan/blob/master/query/src/main/java/...
This is not the clean fix, just a workaround to confirm the root of the problem.
Should I also look at branch number 2 or is this clarified? The commit message being "modify DistributedMassIndexingTest to show slowlyness of indexing" makes me think it's about a different issue :)
> MassIndexer breaks search feature with one node cluster
> -------------------------------------------------------
>
> Key: ISPN-3767
> URL: https://issues.jboss.org/browse/ISPN-3767
> Project: Infinispan
> Issue Type: Bug
> Reporter: Romain Pelisse
> Assignee: Adrian Nistor
> Priority: Minor
>
> Hi,
> Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query.
> I've modified one of the test suite of InfiniSpan to reproduce the issue:
> https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi...
> Once this branch is checked out, just run :
> $ cd ./query
> $ mvn clean -Dtest=org.infinispan.query.distributed.DistributedMassIndexingTest test
> Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN).
> [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load...
> If run within a single node cluster, the MassIndexer
--
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, 6 months
[JBoss JIRA] (ISPN-3783) JBOSS AS Infinispan nodes cannot interoperate with Plain JVM / Glassfish nodes
by Andrew Scully (JIRA)
Andrew Scully created ISPN-3783:
-----------------------------------
Summary: JBOSS AS Infinispan nodes cannot interoperate with Plain JVM / Glassfish nodes
Key: ISPN-3783
URL: https://issues.jboss.org/browse/ISPN-3783
Project: Infinispan
Issue Type: Bug
Components: Configuration, Distributed Cache, Marshalling, State transfer
Affects Versions: 5.2.1.Final
Environment: JBOSS 7.2.0.FINAL / Glassfish 4 / Plain JVM
Reporter: Andrew Scully
Assignee: Galder Zamarreño
I am able to start up an Infinispan (running over JGroups 3.2.7.Final) cluster, with nodes composed of plain JVMs and Glassfish instances. Equally, I am able to create an Infinispan cluster composed purely of JBOSS instances.
My problem occurs when I include a JBOSS instance in a cluster of Plain JVMs / Glassfish instances. Infinispan running on JBOSS does not appear to be able to inter-operate with Infinispan running in a different environment.
The JGroups configuration is the same on all nodes and I am able to send messages between all of the nodes to prove that the JGroups cluster is operational.
As far as I can see, the Infinispan configuration is the same across all nodes.
The following exception is logged in the JBOSS log:
2013-12-03 15:27:02,841 ERROR [org.jgroups.blocks.RequestCorrelator](OOB-18,shared=udp) failed unmarshalling buffer into return value: java.io.StreamCorruptedException: Unexpected byte found when reading an object: 0
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:750)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.jboss.marshalling.ModularClassResolver.resolveClass(ModularClassResolver.java:99)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:893)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1205)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.infinispan.remoting.responses.ExceptionResponse$Externalizer.readObject(ExceptionResponse.java:66)
at org.infinispan.remoting.responses.ExceptionResponse$Externalizer.readObject(ExceptionResponse.java:58)
at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:402)
at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:224)
at org.infinispan.marshall.jboss.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:164)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:163)
at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:116)
at org.infinispan.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:104)
at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:50)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:404)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
at org.jgroups.JChannel.up(JChannel.java:707)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
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:896)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245)
at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:765)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:420)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:606)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
at org.jgroups.protocols.FD.up(FD.java:253)
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$ProtocolAdapter.up(TP.java:2616)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1263)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798)
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:724)
The following exception is logged on the plain JVM / Glassfish side:
org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl
.start() throws java.lang.Exception on object of type StateTransferManagerImpl
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:88
3)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:654)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:643)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:546)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:199)
at org.infinispan.CacheImpl.start(CacheImpl.java:559)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545)
at com.saaconsultants.external.tester.DomainAccessTester.main(DomainAccessTester.java:137)
Caused by: org.infinispan.CacheException: java.lang.IllegalArgumentException: Segment owner list cannot be null or empty
at org.infinispan.util.Util.rewrapAsCacheException(Util.java:541)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispat
cher.java:186)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:261)
at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:101)
at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
... 10 more
Caused by: java.lang.IllegalArgumentException: Segment owner list cannot be null or empty
at org.infinispan.distribution.ch.DefaultConsistentHash.<init>(DefaultConsistentHash.java:78)
at org.infinispan.distribution.ch.DefaultConsistentHash$Externalizer.readObject(DefaultConsistentHash.java:314)
at org.infinispan.distribution.ch.DefaultConsistentHash$Externalizer.readObject(DefaultConsistentHash.java:294)
at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:402)
at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:224)
at org.infinispan.marshall.jboss.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:164)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.infinispan.topology.CacheTopology$Externalizer.readObject(CacheTopology.java:132)
at org.infinispan.topology.CacheTopology$Externalizer.readObject(CacheTopology.java:121)
at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:402)
at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:224)
at org.infinispan.marshall.jboss.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:164)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.infinispan.remoting.responses.SuccessfulResponse$Externalizer.readObject(SuccessfulResponse.java:101)
at org.infinispan.remoting.responses.SuccessfulResponse$Externalizer.readObject(SuccessfulResponse.java:86)
at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:402)
at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:224)
at org.infinispan.marshall.jboss.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:164)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:163
)
at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:116)
at org.infinispan.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:1
04)
at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:50)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:404)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
at org.jgroups.JChannel.up(JChannel.java:707)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
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:896)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245)
at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:765)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:420)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:606)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
at org.jgroups.protocols.FD.up(FD.java:253)
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$ProtocolAdapter.up(TP.java:2616)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1263)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798)
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:724)
I can supply my configuration if this would be useful.
--
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, 6 months
[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on ISPN-3767:
--------------------------------------
Hi Adrian,
yes, I have - sorry forgot to push/update the JIRA. As suggested by Alan Field, I simply "hack" the DistributedMassIndex test case to reproduce my scenario. You'll find the modify test case on github:
https://github.com/rpelisse/infinispan/tree/ISPN-3767
> MassIndexer breaks search feature with one node cluster
> -------------------------------------------------------
>
> Key: ISPN-3767
> URL: https://issues.jboss.org/browse/ISPN-3767
> Project: Infinispan
> Issue Type: Bug
> Reporter: Romain Pelisse
> Assignee: Adrian Nistor
> Priority: Minor
>
> Hi,
> Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query.
> I've modified one of the test suite of InfiniSpan to reproduce the issue:
> https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi...
> Once this branch is checked out, just run :
> $ cd ./query
> $ mvn clean -Dtest=org.infinispan.query.distributed.DistributedMassIndexingTest test
> Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN).
> [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load...
> If run within a single node cluster, the MassIndexer
--
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, 6 months
[JBoss JIRA] (ISPN-3738) Entry version gets lost during topology change -> NPE
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3738?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3738 started by Pedro Ruivo.
> Entry version gets lost during topology change -> NPE
> -----------------------------------------------------
>
> Key: ISPN-3738
> URL: https://issues.jboss.org/browse/ISPN-3738
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
>
> Replicated TX cache with WSC, A, B are in cluster, C is joining
> 0. The current CH already contains A and B as owners, C is joining (is not primary owner of anything yet). B is primary owner of K=V.
> 1. A sends PrepareCommand to B and C with put(K, V) (V is null on all nodes)
> 2. C receives PrepareCommand and responds with no versions (it is not primary owner)
> 3. topology changes on B - primary ownership of K is transfered to C
> 4. B receives PrepareCommand, responds without K's version (it is not primary)
> 5. B forwards the Prepare to C as it sees that the command has lower topology ID
> 6. C responds to B's prepare with version of K
> 7. K version is *not* added to B's response, B responds to A
> 8. A finds out that topology has changed, forwards prepare to C
> 9. C responds to C's prepare with version of K
> 10. A receives C's response, but the versions are not added to transaction
> 11. A sends out CommitCommand missing version of K
> 12. all nodes record K=V without version as usual ImmortalCacheEntry
> 13. the next time we try to increase version of K=V, we fail with NPE in SimpleClusteredVersionGenerator (actually when it tries to throw IllegalArgumentException because the null version is unexpected version class)
--
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, 6 months
[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-3767:
-------------------------------------
Hi Romain! Did you make the update you mention?
> MassIndexer breaks search feature with one node cluster
> -------------------------------------------------------
>
> Key: ISPN-3767
> URL: https://issues.jboss.org/browse/ISPN-3767
> Project: Infinispan
> Issue Type: Bug
> Reporter: Romain Pelisse
> Assignee: Adrian Nistor
> Priority: Minor
>
> Hi,
> Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query.
> I've modified one of the test suite of InfiniSpan to reproduce the issue:
> https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi...
> Once this branch is checked out, just run :
> $ cd ./query
> $ mvn clean -Dtest=org.infinispan.query.distributed.DistributedMassIndexingTest test
> Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN).
> [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load...
> If run within a single node cluster, the MassIndexer
--
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, 6 months
[JBoss JIRA] (ISPN-3764) ISPN testsuite fails for RHEL6x64 && IBM JDK6
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3764?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3764:
--------------------------------
Labels: 620 testsuite_stability (was: testsuite_stability)
> 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: Mircea Markus
> 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, 6 months
[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3633:
-------------------------------------
I will try the interleavings again, I wasn't able to reproduce that one before. It must be more specific positioning, I will try to see what I can get.
> InvalidateL1Command during ST should not cancel writing the entry by ST
> -----------------------------------------------------------------------
>
> Key: ISPN-3633
> URL: https://issues.jboss.org/browse/ISPN-3633
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.3.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry.
> Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once.
--
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, 6 months
[JBoss JIRA] (ISPN-3498) Cannot construct org.infinispan.util.KeyValuePair as it does not have a no-args constructor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3498?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3498:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1007435|https://bugzilla.redhat.com/show_bug.cgi?id=1007435] from NEW to ON_QA
> Cannot construct org.infinispan.util.KeyValuePair as it does not have a no-args constructor
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-3498
> URL: https://issues.jboss.org/browse/ISPN-3498
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 6.0.0.Alpha4
> Environment: Azul JDK
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> When infinispan testsuite(Alpha3) is running with Azul JDK
> java.runtime.version = 1.6.0_33-b5
> java.runtime.name =Java(TM) SE Runtime Environment
> java.vm.version = 1.6.0_33-ZVM_5.5.3.0-b5-product-azlinuxM-X86_64
> java.vm.vendor = Azul Systems, Inc.
> os.name = Linux
> os.version = 2.6.32-358.11.1.el6.x86_64
> sun.arch.data.model = 64
> sun.cpu.endian = little
> Wollowing redundant Exception occurs
> Error Message
> Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor ---- Debugging information ---- message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException cause-message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor class : org.infinispan.container.entries.ImmortalCacheValue required-type : org.infinispan.container.entries.ImmortalCacheValue converter-type : com.thoughtworks.xstream.converters.reflection.ReflectionConverter path : /org.infinispan.container.entries.ImmortalCacheValue line number : 1 version : 1.4.1-redhat-2 -------------------------------
> Stacktrace
> com.thoughtworks.xstream.converters.ConversionException: Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> ---- Debugging information ----
> message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> cause-message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> class : org.infinispan.container.entries.ImmortalCacheValue
> required-type : org.infinispan.container.entries.ImmortalCacheValue
> converter-type : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
> path : /org.infinispan.container.entries.ImmortalCacheValue
> line number : 1
> version : 1.4.1-redhat-2
> -------------------------------
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:79)
> at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:134)
> at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32)
> at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1035)
> at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1019)
> at com.thoughtworks.xstream.XStream.fromXML(XStream.java:895)
> at com.thoughtworks.xstream.XStream.fromXML(XStream.java:886)
> at org.infinispan.marshall.TestObjectStreamMarshaller.objectFromObjectStream(TestObjectStreamMarshaller.java:65)
> at org.infinispan.marshall.TestObjectStreamMarshaller.objectFromByteBuffer(TestObjectStreamMarshaller.java:97)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromInputStream(AbstractMarshaller.java:105)
> at org.infinispan.loaders.jdbc.JdbcUtil.unmarshall(JdbcUtil.java:66)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.readStoredEntry(JdbcStringBasedCacheStore.java:391)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.loadLockSafe(JdbcStringBasedCacheStore.java:328)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.loadLockSafe(JdbcStringBasedCacheStore.java:67)
> at org.infinispan.loaders.spi.LockSupportCacheStore.load(LockSupportCacheStore.java:128)
> at org.infinispan.loaders.spi.AbstractCacheLoader.containsKey(AbstractCacheLoader.java:34)
> at org.infinispan.loaders.BaseCacheStoreTest.testCommitAndRollbackWithoutPrepare(BaseCacheStoreTest.java:427)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: com.thoughtworks.xstream.converters.reflection.ObjectAccessException: Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.newInstance(PureJavaReflectionProvider.java:71)
> at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.instantiateNewInstance(AbstractReflectionConverter.java:424)
> at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:229)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)
> ... 40 more
> You can see it in jenkins http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-62-ispn-testsuite...
> After implementing or extending Serializable interface in BucketInternalCacheEntry, InternalCacheValue exception disappeared
> Second build was done with Alpha4 version and the same exception appers because of new classes and functionality added
> You can see it in jenkins http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-62-ispn-testsuite...
--
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, 6 months
[JBoss JIRA] (ISPN-3537) Custom interceptor with Position.LAST set programmatically doesn't work
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3537?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3537:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1024414|https://bugzilla.redhat.com/show_bug.cgi?id=1024414] from NEW to ON_QA
> Custom interceptor with Position.LAST set programmatically doesn't work
> -----------------------------------------------------------------------
>
> Key: ISPN-3537
> URL: https://issues.jboss.org/browse/ISPN-3537
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 6.0.0.Beta1
> Reporter: Jiří Holuša
> Assignee: Mircea Markus
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> When configuring cache programmatically, adding a custom interceptor with position set to Position.LAST cause not calling this interceptor.
> Code sample:
> {code:borderStyle=solid}
> EmbeddedCacheManager manager = new DefaultCacheManager();
> Configuration c2 = new ConfigurationBuilder()
> .customInterceptors()
> .addInterceptor() .position(InterceptorConfiguration.Position.LAST).interceptor(new MyInterceptor())
> .build();
> manager.defineConfiguration("interceptors", c2);
> Cache<String, String> cache = manager.getCache("interceptors");
> cache.put("hello", "world");
> {code}
> MyInterceptor is very simple, reacting to all events. When changing to Position.FIRST, everything works fine. Also tried two/three interceptors, various combinations, but always with same result - when position set to Position.LAST, interceptors is not called.
> Note that no problem when setting by index().
--
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, 6 months