[JBoss JIRA] (ISPN-6325) Other node shutting down caused local exception
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6325?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-6325:
------------------------------------
I hope it's no longer an issue, because I wouldn't expect an {{EOFException}} when unmarshalling a command -- even while the node is shutting down.
> Other node shutting down caused local exception
> -----------------------------------------------
>
> Key: ISPN-6325
> URL: https://issues.jboss.org/browse/ISPN-6325
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.1.2.Final
> Reporter: William Burns
>
> I was running DistributedStreamRehashStressTest and I found that one of my processing threads was killed by the following exception, which shouldn't be propagated to the user:
> {code}
> java.lang.AssertionError: Found an exception in at least 1 thread
> at org.testng.Assert.fail(Assert.java:83)
> at org.infinispan.stream.stress.DistributedStreamRehashStressTest.testStressNodesLeavingWhilePerformingCallable(DistributedStreamRehashStressTest.java:226)
> at org.infinispan.stream.stress.DistributedStreamRehashStressTest.testStressNodesLeavingWhileMultipleIterators(DistributedStreamRehashStressTest.java:113)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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:348)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
> at org.testng.SuiteRunner.run(SuiteRunner.java:254)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:72)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistributedStreamRehashStressTest-NodeCU-43302, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:796)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$212(JGroupsTransport.java:633)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.futureDone(SingleResponseFuture.java:30)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:162)
> at org.jgroups.blocks.UnicastRequest.receiveResponse(UnicastRequest.java:81)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:373)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:237)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.RSVP.up(RSVP.java:201)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:392)
> at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1043)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1590)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1802)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistributedStreamRehashStressTest-NodeCV-40406, see cause for remote stack trace
> ... 31 more
> Caused by: org.infinispan.commons.CacheException: Problems invoking command.
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:180)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:402)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:352)
> ... 20 more
> Caused by: java.io.EOFException: Read past end of file
> at org.jboss.marshalling.SimpleDataInput.eofOnRead(SimpleDataInput.java:151)
> at org.jboss.marshalling.SimpleDataInput.readUnsignedByteDirect(SimpleDataInput.java:294)
> at org.jboss.marshalling.SimpleDataInput.readUnsignedByte(SimpleDataInput.java:249)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.commons.marshall.MarshallUtil.unmarshallCollectionUnbounded(MarshallUtil.java:217)
> at org.infinispan.stream.impl.StreamSegmentResponseCommand.readFrom(StreamSegmentResponseCommand.java:61)
> at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readCommandParameters(ReplicableCommandExternalizer.java:113)
> at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:173)
> at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:68)
> at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:478)
> at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:235)
> at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:134)
> at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:101)
> at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
> at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:160)
> ... 22 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-6766) hot rod client: RemoteCache.removeClient method does not remove the listener from the list after server restart
by Katia Aresti (JIRA)
[ https://issues.jboss.org/browse/ISPN-6766?page=com.atlassian.jira.plugin.... ]
Katia Aresti updated ISPN-6766:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5091
> hot rod client: RemoteCache.removeClient method does not remove the listener from the list after server restart
> ---------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6766
> URL: https://issues.jboss.org/browse/ISPN-6766
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Remote Protocols
> Affects Versions: 8.2.1.Final
> Reporter: Eli Z
> Assignee: Katia Aresti
> Priority: Minor
> Fix For: 9.1.0.Final
>
>
> After registering a client listener in the client and then restarting the infinispan server --> The original listener object can not be removed from the client listener list by using the method RemoteCache.removeClient(Object listener) --> after calling this method and then get all listeners, i still see the old listener in the list.
> By doing a little debug, it seems that in class RemoveClientListenerOperation.execute when trying to remove from the server and a failure status is returned (probably due to the fact the the server after the restart does not know this listener id) the listener is not removed from the list eventually. the line this.listenerNotifier.removeClientListener(listenerId); is not executed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-7728) Run the stress tests serially
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7728?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7728:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.1.0.Alpha1
Resolution: Done
> Run the stress tests serially
> -----------------------------
>
> Key: ISPN-7728
> URL: https://issues.jboss.org/browse/ISPN-7728
> Project: Infinispan
> Issue Type: Task
> Components: Build process
> Affects Versions: 9.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.1.0.Final, 9.1.0.Alpha1
>
>
> Currently the {{test-stress}} profile runs the stress tests with the default number of threads (15). Considering that stress tests are heavy CPU users, it's better to run them on a single thread.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-7704) AbstractFileLookup#lookupFileStrict should also support absolute paths
by Daniel Svanström (JIRA)
[ https://issues.jboss.org/browse/ISPN-7704?page=com.atlassian.jira.plugin.... ]
Daniel Svanström edited comment on ISPN-7704 at 4/18/17 10:01 AM:
------------------------------------------------------------------
I just had a look at the fix of this issue. I built 9.0.1-SNAPSHOT locally, which should include this fix. I confirm that the error that occurred before went away. However, something still seems to be incorrect here. While Infinispan init seems like it checks for the existence of the infinispan.xml configuration(it complains loudly if it can't find the file), the init does not seem to care at all about the contents of the file. To show what I mean, I have updated my test case at https://github.com/DBarbarian/CacheTest/tree/master with a unit test. To see the issue, look in the application.properties file and play around with the three different configurations.
* When pointing at the correct configuration file, there is no error at init (expected), but my configured caches do not get initialized (not expected) as it can't find the cache when it is about to be used.
* When pointing at a non-existing configuration file, I get an error during init (expected).
* When pointing at an existing configuration file with invalid xml, I get no errors during init (unexpected).
I have also [included the same unit test for the 8.2.6 version|https://github.com/DBarbarian/CacheTest/tree/infinispan-8.2.6-tes...], where the only difference is which version of Infinispan the code is using but the behavior is what I would expect.
was (Author: danielbarbarian):
I just had a look at the fix of this issue. I built 9.0.1-SNAPSHOT locally, which should include this fix. I confirm that the error that occurred before went away. However, something still seems to be incorrect here. While Infinispan init seems like it checks for the existence of the infinispan.xml configuration(it complains loudly if it can't find the file), the init does not seem to care at all about the contents of the file. To show what I mean, I have updated my test case at https://github.com/DBarbarian/CacheTest/tree/master with a unit test. To see the issue, look in the application.properties file and play around with the three different configurations.
* When pointing at the correct configuration file, there is no error at init (expected), but my configured caches do not get initialized (not expected) as it can't find the cache when it is about t be used.
* When pointing at a non-existing configuration file, I get an error during init (expected).
* When pointing at an existing configuration file with invalid xml, I get no errors during init (unexpected).
I have also [included the same unit test for the 8.2.6 version|https://github.com/DBarbarian/CacheTest/tree/infinispan-8.2.6-tes...], where the only difference is which version of Infinispan the code is using but the behavior is what I would expect.
> AbstractFileLookup#lookupFileStrict should also support absolute paths
> ----------------------------------------------------------------------
>
> Key: ISPN-7704
> URL: https://issues.jboss.org/browse/ISPN-7704
> Project: Infinispan
> Issue Type: Bug
> Components: JCache, Spring Integration
> Affects Versions: 9.0.0.Final
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Fix For: 9.0.1.Final
>
>
> When specifying {{spring.cache.jcache.config}} value in Spring's application.properties, Spring passes us a scheme with absolute path (e.g. {{file:/home/slaskawi/work/infinispan/CacheTest/target/classes/infinispan.xml}}). This causes problems with {{AbstractFileLookup#lookupFileStrict(java.net.URI, java.lang.ClassLoader)}} since it should construct a new {{File}} rather than load this resource from the classloader.
> Related Pull Request: https://github.com/infinispan/infinispan/pull/4474
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-7704) AbstractFileLookup#lookupFileStrict should also support absolute paths
by Daniel Svanström (JIRA)
[ https://issues.jboss.org/browse/ISPN-7704?page=com.atlassian.jira.plugin.... ]
Daniel Svanström commented on ISPN-7704:
----------------------------------------
I just had a look at the fix of this issue. I built 9.0.1-SNAPSHOT locally, which should include this fix. I confirm that the error that occurred before went away. However, something still seems to be incorrect here. While Infinispan init seems like it checks for the existence of the infinispan.xml configuration(it complains loudly if it can't find the file), the init does not seem to care at all about the contents of the file. To show what I mean, I have updated my test case at https://github.com/DBarbarian/CacheTest/tree/master with a unit test. To see the issue, look in the application.properties file and play around with the three different configurations.
* When pointing at the correct configuration file, there is no error at init (expected), but my configured caches do not get initialized (not expected) as it can't find the cache when it is about t be used.
* When pointing at a non-existing configuration file, I get an error during init (expected).
* When pointing at an existing configuration file with invalid xml, I get no errors during init (unexpected).
I have also [included the same unit test for the 8.2.6 version|https://github.com/DBarbarian/CacheTest/tree/infinispan-8.2.6-tes...], where the only difference is which version of Infinispan the code is using but the behavior is what I would expect.
> AbstractFileLookup#lookupFileStrict should also support absolute paths
> ----------------------------------------------------------------------
>
> Key: ISPN-7704
> URL: https://issues.jboss.org/browse/ISPN-7704
> Project: Infinispan
> Issue Type: Bug
> Components: JCache, Spring Integration
> Affects Versions: 9.0.0.Final
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Fix For: 9.0.1.Final
>
>
> When specifying {{spring.cache.jcache.config}} value in Spring's application.properties, Spring passes us a scheme with absolute path (e.g. {{file:/home/slaskawi/work/infinispan/CacheTest/target/classes/infinispan.xml}}). This causes problems with {{AbstractFileLookup#lookupFileStrict(java.net.URI, java.lang.ClassLoader)}} since it should construct a new {{File}} rather than load this resource from the classloader.
> Related Pull Request: https://github.com/infinispan/infinispan/pull/4474
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months