[JBoss JIRA] (ISPN-4988) Infinispan state transfer tests fail with Azul JDK
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4988?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4988:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1165036
> Infinispan state transfer tests fail with Azul JDK
> --------------------------------------------------
>
> Key: ISPN-4988
> URL: https://issues.jboss.org/browse/ISPN-4988
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.0.1.Final
> Reporter: Vitalii Chepeliuk
> Labels: testsuite_stability
>
> Lot of ST tests fail with
> {noformat}
> 2014-11-16 10:16:50,867 ERROR [UnitTestTestNGListener] (testng-DistSyncNonTxStateTransferTest) Test testRemoveIfMatchFail(org.infinispan.xsite.statetransfer.DistSyncNonTxStateTransferTest) failed.
> java.lang.AssertionError: expected:<ok> but was:<Unable to pushState to 'NYC'. org.infinispan.util.concurrent.TimeoutException: Timed out after 20 minutes waiting for a response from NYC (sync, timeout=1200000)>
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.startStateTransfer(BaseStateTransferTest.java:447)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testStateTransferWithNoReplicatedOperation(BaseStateTransferTest.java:372)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testRemoveIfMatchFail(BaseStateTransferTest.java:167)
> 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> 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: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.run(FutureTask.java:262)
> 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:745)
> Test suite progress: tests succeeded: 21, failed: 140, skipped: 0.
> {noformat}
> or
> {noformat}
> java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistSyncOnePhaseTxStateTransferTest-NodeAJ-18700, see cause for remote stack trace
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at org.infinispan.commons.util.concurrent.NotifyingFutureImpl.get(NotifyingFutureImpl.java:73)
> at org.infinispan.xsite.BackupReceiverImpl.invokeRemotelyInLocalSite(BackupReceiverImpl.java:215)
> at org.infinispan.xsite.BackupReceiverImpl.handleStateTransferControl(BackupReceiverImpl.java:89)
> at org.infinispan.xsite.BackupReceiverDelegator.handleStateTransferControl(BackupReceiverDelegator.java:37)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferControlCommand.performInLocalSite(XSiteStateTransferControlCommand.java:41)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$3.run(CommandAwareRpcDispatcher.java:250)
> 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:745)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistSyncOnePhaseTxStateTransferTest-NodeAJ-18700, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:364)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:525)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:290)
> at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:325)
> at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:321)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ... 3 more
> Caused by: org.infinispan.commons.CacheException: Already receiving state from LON
> at org.infinispan.xsite.statetransfer.XSiteStateConsumerImpl.startStateTransfer(XSiteStateConsumerImpl.java:64)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferControlCommand.perform(XSiteStateTransferControlCommand.java:59)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:92)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:208)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:81)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:265)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:209)
> 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:250)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:677)
> at org.jgroups.JChannel.up(JChannel.java:733)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1029)
> at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:419)
> 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:394)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:383)
> at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1042)
> 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:619)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
> at org.jgroups.protocols.Discovery.up(Discovery.java:277)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1572)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1791)
> ... 3 more
> {noformat}
> or
> {noformat}
> 2014-11-15 22:02:52,185 ERROR [UnitTestTestNGListener] (testng-DistSyncOnePhaseTxStateTransferTest) Test testRemoveNonExisting(org.infinispan.xsite.statetransfer.DistSyncOnePhaseTxStateTransferTest) failed.
> java.util.concurrent.TimeoutException: Timed out waiting for event before-start
> at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:43)
> at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:33)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest$XSiteStateProviderControl.await(BaseStateTransferTest.java:783)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testConcurrentOperation(BaseStateTransferTest.java:300)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testRemoveNonExisting(BaseStateTransferTest.java:179)
> 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> 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: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.run(FutureTask.java:262)
> 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:745)
> {noformat}
> More info from jenkins jobs here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-63-ispn-testsuit...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-63-ispn-testsuit...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4988) Infinispan state transfer tests fail with Azul JDK
by Vitalii Chepeliuk (JIRA)
Vitalii Chepeliuk created ISPN-4988:
---------------------------------------
Summary: Infinispan state transfer tests fail with Azul JDK
Key: ISPN-4988
URL: https://issues.jboss.org/browse/ISPN-4988
Project: Infinispan
Issue Type: Bug
Components: State Transfer
Affects Versions: 7.0.1.Final
Reporter: Vitalii Chepeliuk
Lot of ST tests fail with
{noformat}
2014-11-16 10:16:50,867 ERROR [UnitTestTestNGListener] (testng-DistSyncNonTxStateTransferTest) Test testRemoveIfMatchFail(org.infinispan.xsite.statetransfer.DistSyncNonTxStateTransferTest) failed.
java.lang.AssertionError: expected:<ok> but was:<Unable to pushState to 'NYC'. org.infinispan.util.concurrent.TimeoutException: Timed out after 20 minutes waiting for a response from NYC (sync, timeout=1200000)>
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108)
at org.infinispan.xsite.statetransfer.BaseStateTransferTest.startStateTransfer(BaseStateTransferTest.java:447)
at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testStateTransferWithNoReplicatedOperation(BaseStateTransferTest.java:372)
at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testRemoveIfMatchFail(BaseStateTransferTest.java:167)
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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
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: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.run(FutureTask.java:262)
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:745)
Test suite progress: tests succeeded: 21, failed: 140, skipped: 0.
{noformat}
or
{noformat}
java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistSyncOnePhaseTxStateTransferTest-NodeAJ-18700, see cause for remote stack trace
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at org.infinispan.commons.util.concurrent.NotifyingFutureImpl.get(NotifyingFutureImpl.java:73)
at org.infinispan.xsite.BackupReceiverImpl.invokeRemotelyInLocalSite(BackupReceiverImpl.java:215)
at org.infinispan.xsite.BackupReceiverImpl.handleStateTransferControl(BackupReceiverImpl.java:89)
at org.infinispan.xsite.BackupReceiverDelegator.handleStateTransferControl(BackupReceiverDelegator.java:37)
at org.infinispan.xsite.statetransfer.XSiteStateTransferControlCommand.performInLocalSite(XSiteStateTransferControlCommand.java:41)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$3.run(CommandAwareRpcDispatcher.java:250)
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:745)
Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistSyncOnePhaseTxStateTransferTest-NodeAJ-18700, see cause for remote stack trace
at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:364)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:525)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:290)
at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:325)
at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:321)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
... 3 more
Caused by: org.infinispan.commons.CacheException: Already receiving state from LON
at org.infinispan.xsite.statetransfer.XSiteStateConsumerImpl.startStateTransfer(XSiteStateConsumerImpl.java:64)
at org.infinispan.xsite.statetransfer.XSiteStateTransferControlCommand.perform(XSiteStateTransferControlCommand.java:59)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:92)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:208)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:81)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:265)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:209)
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:250)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:677)
at org.jgroups.JChannel.up(JChannel.java:733)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1029)
at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:419)
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:394)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:383)
at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1042)
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:619)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
at org.jgroups.protocols.Discovery.up(Discovery.java:277)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1572)
at org.jgroups.protocols.TP$MyHandler.run(TP.java:1791)
... 3 more
{noformat}
or
{noformat}
2014-11-15 22:02:52,185 ERROR [UnitTestTestNGListener] (testng-DistSyncOnePhaseTxStateTransferTest) Test testRemoveNonExisting(org.infinispan.xsite.statetransfer.DistSyncOnePhaseTxStateTransferTest) failed.
java.util.concurrent.TimeoutException: Timed out waiting for event before-start
at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:43)
at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:33)
at org.infinispan.xsite.statetransfer.BaseStateTransferTest$XSiteStateProviderControl.await(BaseStateTransferTest.java:783)
at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testConcurrentOperation(BaseStateTransferTest.java:300)
at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testRemoveNonExisting(BaseStateTransferTest.java:179)
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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
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: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.run(FutureTask.java:262)
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:745)
{noformat}
More info from jenkins jobs here
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-63-ispn-testsuit...
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-63-ispn-testsuit...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4939) The text is repeated three times in META-INF\services
by ratking (JIRA)
[ https://issues.jboss.org/browse/ISPN-4939?page=com.atlassian.jira.plugin.... ]
ratking updated ISPN-4939:
--------------------------
Description:
Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
{quote}
infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (Has been fixed in 7.0.1)
infinispan-embedded-7.0.0.Final.jar\META-INF\services\
infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
infinispan-remote-7.0.0.Final.jar\META-INF\services\
{quote}
Open these files with a text editor, you will find that the text is *repeated three times*.
disastrous
was:
Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
{quote}
infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (Has been fixed in 7.0.1)
infinispan-embedded-7.0.0.Final.jar\META-INF\services\
infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
infinispan-remote-7.0.0.Final.jar\META-INF\services\
{quote}
Open these files with a text editor, you will find that the text is *repeated three times*.
disastrous
Forum Reference: https://developer.jboss.org/message/909081
> The text is repeated three times in META-INF\services
> -----------------------------------------------------
>
> Key: ISPN-4939
> URL: https://issues.jboss.org/browse/ISPN-4939
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 7.0.0.Final
> Reporter: ratking
> Priority: Blocker
>
> Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
> {quote}
> infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (Has been fixed in 7.0.1)
> infinispan-embedded-7.0.0.Final.jar\META-INF\services\
> infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
> infinispan-remote-7.0.0.Final.jar\META-INF\services\
> {quote}
> Open these files with a text editor, you will find that the text is *repeated three times*.
> disastrous
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4939) The text is repeated three times in META-INF\services
by ratking (JIRA)
[ https://issues.jboss.org/browse/ISPN-4939?page=com.atlassian.jira.plugin.... ]
ratking updated ISPN-4939:
--------------------------
Description:
Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
{quote}
infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (Has been fixed in 7.0.1)
infinispan-embedded-7.0.0.Final.jar\META-INF\services\
infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
infinispan-remote-7.0.0.Final.jar\META-INF\services\
{quote}
Open these files with a text editor, you will find that the text is *repeated three times*.
disastrous
Forum Reference: https://developer.jboss.org/message/909081
was:
Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
{quote}
infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (Has been fixed in 7.0.1)
infinispan-embedded-7.0.0.Final.jar\META-INF\services\
infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
infinispan-remote-7.0.0.Final.jar\META-INF\services\
{quote}
Open these files with a text editor, you will find that the text is *repeated three times*.
disastrous
See the forum:
https://developer.jboss.org/message/909081
> The text is repeated three times in META-INF\services
> -----------------------------------------------------
>
> Key: ISPN-4939
> URL: https://issues.jboss.org/browse/ISPN-4939
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 7.0.0.Final
> Reporter: ratking
> Priority: Blocker
>
> Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
> {quote}
> infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (Has been fixed in 7.0.1)
> infinispan-embedded-7.0.0.Final.jar\META-INF\services\
> infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
> infinispan-remote-7.0.0.Final.jar\META-INF\services\
> {quote}
> Open these files with a text editor, you will find that the text is *repeated three times*.
> disastrous
> Forum Reference: https://developer.jboss.org/message/909081
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4939) The text is repeated three times in META-INF\services
by ratking (JIRA)
[ https://issues.jboss.org/browse/ISPN-4939?page=com.atlassian.jira.plugin.... ]
ratking updated ISPN-4939:
--------------------------
Description:
Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
{quote}
infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (Has been fixed in 7.0.1)
infinispan-embedded-7.0.0.Final.jar\META-INF\services\
infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
infinispan-remote-7.0.0.Final.jar\META-INF\services\
{quote}
Open these files with a text editor, you will find that the text is *repeated three times*.
disastrous
See the forum:
https://developer.jboss.org/message/909081
was:
Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
{quote}
infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (fixed in 7.0.1)
infinispan-embedded-7.0.0.Final.jar\META-INF\services\
infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
infinispan-remote-7.0.0.Final.jar\META-INF\services\
{quote}
Open these files with a text editor, you will find that the text is *repeated three times*.
disastrous
> The text is repeated three times in META-INF\services
> -----------------------------------------------------
>
> Key: ISPN-4939
> URL: https://issues.jboss.org/browse/ISPN-4939
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 7.0.0.Final
> Reporter: ratking
> Priority: Blocker
>
> Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
> {quote}
> infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (Has been fixed in 7.0.1)
> infinispan-embedded-7.0.0.Final.jar\META-INF\services\
> infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
> infinispan-remote-7.0.0.Final.jar\META-INF\services\
> {quote}
> Open these files with a text editor, you will find that the text is *repeated three times*.
> disastrous
> See the forum:
> https://developer.jboss.org/message/909081
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4939) The text is repeated three times in META-INF\services
by ratking (JIRA)
[ https://issues.jboss.org/browse/ISPN-4939?page=com.atlassian.jira.plugin.... ]
ratking updated ISPN-4939:
--------------------------
Description:
Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
{quote}
infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (fixed in 7.0.1)
infinispan-embedded-7.0.0.Final.jar\META-INF\services\
infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
infinispan-remote-7.0.0.Final.jar\META-INF\services\
{quote}
Open these files with a text editor, you will find that the text is *repeated three times*.
disastrous
was:
Download infinispan-7.0.0.Final-all.zip from http://infinispan.org/download/ and unzip the file.
{quote}
infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml
infinispan-embedded-7.0.0.Final.jar\META-INF\services\
infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
infinispan-remote-7.0.0.Final.jar\META-INF\services\
{quote}
Open these files with a text editor, you will find that the text is *repeated three times*.
disastrous
> The text is repeated three times in META-INF\services
> -----------------------------------------------------
>
> Key: ISPN-4939
> URL: https://issues.jboss.org/browse/ISPN-4939
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 7.0.0.Final
> Reporter: ratking
> Priority: Blocker
>
> Download infinispan-7.0.0.Final-all.zip or infinispan-7.0.1.Final-all.zip from http://infinispan.org/download/ and unzip the file.
> {quote}
> infinispan-embedded-7.0.0.Final.jar\META-INF\beans.xml (fixed in 7.0.1)
> infinispan-embedded-7.0.0.Final.jar\META-INF\services\
> infinispan-embedded-query-7.0.0.Final.jar\META-INF\services\
> infinispan-remote-7.0.0.Final.jar\META-INF\services\
> {quote}
> Open these files with a text editor, you will find that the text is *repeated three times*.
> disastrous
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero edited comment on ISPN-4979 at 11/17/14 8:13 PM:
-----------------------------------------------------------------
That's not exactly what I meant, sorry I've been too short as I simply meant to remind about "old discussions". We once discussed the need to not allocate new Address instance copies so often - I had diagnosed this as an allocation hot spot 2-3 years ago - and the discussion was about what kind of data structure we should use to represent a "View", and to use the View as a sort of root for most other collections we normally need for sets of addresses as these could be seen as a "mask" on top of the View they were linked to. I actually coded much of that but it was breaking too many SPIs as I was replaceing all instances of Collection<Address>, List<Address>, Set<Address>.. so the task was postponed and I think it would be a nightmare to try rebasing my old patch but I still think something in that league is eventually going to be necessary.
The basic principle is that - besides some exceptional cases - a mask of the View is good enough to represent any such Set<Address> as even when you need ordering like in List<Address>, the ordering is always going to be the same and all lists also need the property of no-repeated instanced provided by the Set. So you need a custom data structure, which we can make very efficient as our requirements are simple. Also there are plenty of points in the code in which defensive collections are created, the representation I was experimenting with would be an immutable collection, which you could mask recursively.. so with no mutations, you could guarantee that no copy would be done unless there was an actual need for it, and even then each copy would be cheap as it's again just a mask and a pointer to the inner set.
This wouldn't just be a custom collection, but you'd also have the "ViewManagementService" to be "the" only place where Address instances are maintained. If you had a de-serialization context, and the Unmarshaller had access to it, it could use it to incarnate references from the pool (as it is the pool). This would also make sure that you don't need to worry about cleanup of unused Address instances in the Unmarshaller cache, as nodes leaving would imply a View change and hence a cleanup from the root structure.
Occasionally you might still need to unmarshall an Address instance which isn't in the pool (like an unknown address such as what you might receive from a node having a different View installed); in such case you would still need to allocate one but that would be a fairly limited case.
was (Author: sannegrinovero):
That's not exactly what I meant, sorry I've been too short as I simply meant to refer to "old discussions". We once discussed the need to not allocate new Address instance copies so often - I had diagnosed this as an allocation hot spot 2-3 years ago - and the discussion was about what kind of data structure we should use to represent a "View", and to use the View as a sort of root for most other collections we normally need for sets of addresses as these could be seen as a "mask" on top of the View they were linked to. I actually coded much of that but it was breaking too many SPIs as I was replaceing all instances of Collection<Address>, List<Address>, Set<Address>.. so the task was postponed and I think it would be a nightmare to try rebasing my old patch but I still think something in that league is eventually going to be necessary.
The basic principle is that - besides some exceptional cases - a mask of the View is good enough to represent any such Set<Address> as even when you need ordering like in List<Address>, the ordering is always going to be the same and all lists also need the property of no-repeated instanced provided by the Set. So you need a custom data structure, which we can make very efficient as our requirements are simple. Also there are plenty of points in the code in which defensive collections are created, the representation I was experimenting with would be an immutable collection, which you could mask recursively.. so with no mutations, you could guarantee that no copy would be done unless there was an actual need for it, and even then each copy would be cheap as it's again just a mask and a pointer to the inner set.
This wouldn't just be a custom collection, but you'd also have the "ViewManagementService" to be "the" only place where Address instances are maintained. If you had a de-serialization context, and the Unmarshaller had access to it, it could use it to incarnate references from the pool (as it is the pool). This would also make sure that you don't need to worry about cleanup of unused Address instances in the Unmarshaller cache, as nodes leaving would imply a View change and hence a cleanup from the root structure.
Occasionally you might still need to unmarshall an Address instance which isn't in the pool (like an unknown address such as what you might receive from a node having a different View installed); in such case you would still need to allocate one but that would be a fairly limited case.
> CacheStatusResponse map uses too much memory
> --------------------------------------------
>
> Key: ISPN-4979
> URL: https://issues.jboss.org/browse/ISPN-4979
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Dan Berindei
> Assignee: William Burns
> Priority: Critical
> Fix For: 7.1.0.Final
>
>
> When the cluster is large and there are a log of caches, the {{CacheStatusResponse}} map on the new coordinator can get quite large. One of the problems that seems to be that the addresses in {{DefaultConsistentHash}} are duplicated on serialization, so the deserialized version occupies more memory.
> We need to investigate why the objects are not "shared" by the River marshaller, and maybe work around the problem by de-duplicating the addresses in the externalizer.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero edited comment on ISPN-4979 at 11/17/14 8:13 PM:
-----------------------------------------------------------------
That's not exactly what I meant, sorry I've been too short as I simply meant to refer to "old discussions". We once discussed the need to not allocate new Address instance copies so often - I had diagnosed this as an allocation hot spot 2-3 years ago - and the discussion was about what kind of data structure we should use to represent a "View", and to use the View as a sort of root for most other collections we normally need for sets of addresses as these could be seen as a "mask" on top of the View they were linked to. I actually coded much of that but it was breaking too many SPIs as I was replaceing all instances of Collection<Address>, List<Address>, Set<Address>.. so the task was postponed and I think it would be a nightmare to try rebasing my old patch but I still think something in that league is eventually going to be necessary.
The basic principle is that - besides some exceptional cases - a mask of the View is good enough to represent any such Set<Address> as even when you need ordering like in List<Address>, the ordering is always going to be the same and all lists also need the property of no-repeated instanced provided by the Set. So you need a custom data structure, which we can make very efficient as our requirements are simple. Also there are plenty of points in the code in which defensive collections are created, the representation I was experimenting with would be an immutable collection, which you could mask recursively.. so with no mutations, you could guarantee that no copy would be done unless there was an actual need for it, and even then each copy would be cheap as it's again just a mask and a pointer to the inner set.
This wouldn't just be a custom collection, but you'd also have the "ViewManagementService" to be "the" only place where Address instances are maintained. If you had a de-serialization context, and the Unmarshaller had access to it, it could use it to incarnate references from the pool (as it is the pool). This would also make sure that you don't need to worry about cleanup of unused Address instances in the Unmarshaller cache, as nodes leaving would imply a View change and hence a cleanup from the root structure.
Occasionally you might still need to unmarshall an Address instance which isn't in the pool (like an unknown address such as what you might receive from a node having a different View installed); in such case you would still need to allocate one but that would be a fairly limited case.
was (Author: sannegrinovero):
That's not exactly what I meant, sorry I've been too short as I simply meant to refer to "old discussions". We once discussed the need to not allocate new Address instance copies so often - I had diagnosed this as an allocation hot spot 2-3 years ago - and the discussion was about what kind of data structure we should use to represent a "View", and to use the View as a sort of root for most other collections we normally need for sets of addresses as these could be seen as a "mask" on top of the View they were linked to. I actually coded much of that but it was breaking too many SPIs as I was replaceing all instances of Collection<Address>, List<Address>, Set<Address>.. so the task was postponed and I think it would be a nightmare to try rebasing my old patch but I still think something in that league is eventually going to be necessary.
The basic principle is that - besides some exceptional cases - a mask of the View is good enough to represent any such Set<Address> as even when you need ordering like in List<Address>, the ordering is always going to be the same and all lists also need the property of no-repeated instanced provided by the Set. So you need a custom data structure, which we can make very efficient as our requirements are simple. Also there are plenty of points in the code in which defensive collections are created, the representation I was experimenting with would be an immutable collection, which you could mask recursively.. so with no mutations, you could guarantee that no copy would be done unless there was an actual need for it, and even then each copy would be cheap as it's again just a mask and a pointer to the inner set.
This wouldn't just be a custom collection, but you'd also have the "ViewManagementService" to be "the" only place where Address instances are maintained. If you had a de-serialization context, and the Unmarshaller had access to it, it could use it to incarnate references from the pool (as it is the pool). This would also make sure that you don't need to worry about cleanup of unused Address instances in the Unmarshaller cache, as nodes leaving would imply a View change and hence a cleanup from the root structure.
> CacheStatusResponse map uses too much memory
> --------------------------------------------
>
> Key: ISPN-4979
> URL: https://issues.jboss.org/browse/ISPN-4979
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Dan Berindei
> Assignee: William Burns
> Priority: Critical
> Fix For: 7.1.0.Final
>
>
> When the cluster is large and there are a log of caches, the {{CacheStatusResponse}} map on the new coordinator can get quite large. One of the problems that seems to be that the addresses in {{DefaultConsistentHash}} are duplicated on serialization, so the deserialized version occupies more memory.
> We need to investigate why the objects are not "shared" by the River marshaller, and maybe work around the problem by de-duplicating the addresses in the externalizer.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-4979:
---------------------------------------
That's not exactly what I meant, sorry I've been too short as I simply meant to refer to "old discussions". We once discussed the need to not allocate new Address instance copies so often - I had diagnosed this as an allocation hot spot 2-3 years ago - and the discussion was about what kind of data structure we should use to represent a "View", and to use the View as a sort of root for most other collections we normally need for sets of addresses as these could be seen as a "mask" on top of the View they were linked to. I actually coded much of that but it was breaking too many SPIs as I was replaceing all instances of Collection<Address>, List<Address>, Set<Address>.. so the task was postponed and I think it would be a nightmare to try rebasing my old patch but I still think something in that league is eventually going to be necessary.
The basic principle is that - besides some exceptional cases - a mask of the View is good enough to represent any such Set<Address> as even when you need ordering like in List<Address>, the ordering is always going to be the same and all lists also need the property of no-repeated instanced provided by the Set. So you need a custom data structure, which we can make very efficient as our requirements are simple. Also there are plenty of points in the code in which defensive collections are created, the representation I was experimenting with would be an immutable collection, which you could mask recursively.. so with no mutations, you could guarantee that no copy would be done unless there was an actual need for it, and even then each copy would be cheap as it's again just a mask and a pointer to the inner set.
This wouldn't just be a custom collection, but you'd also have the "ViewManagementService" to be "the" only place where Address instances are maintained. If you had a de-serialization context, and the Unmarshaller had access to it, it could use it to incarnate references from the pool (as it is the pool). This would also make sure that you don't need to worry about cleanup of unused Address instances in the Unmarshaller cache, as nodes leaving would imply a View change and hence a cleanup from the root structure.
> CacheStatusResponse map uses too much memory
> --------------------------------------------
>
> Key: ISPN-4979
> URL: https://issues.jboss.org/browse/ISPN-4979
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Dan Berindei
> Assignee: William Burns
> Priority: Critical
> Fix For: 7.1.0.Final
>
>
> When the cluster is large and there are a log of caches, the {{CacheStatusResponse}} map on the new coordinator can get quite large. One of the problems that seems to be that the addresses in {{DefaultConsistentHash}} are duplicated on serialization, so the deserialized version occupies more memory.
> We need to investigate why the objects are not "shared" by the River marshaller, and maybe work around the problem by de-duplicating the addresses in the externalizer.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months