[JBoss JIRA] (ISPN-6182) Scala blueprint generator prevent successfull builds of the core module on JDK 1.9
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-6182?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-6182:
---------------------------------------
I've renamed the issue description as we still have the issue of Scala blueprints not working on JDK9, but at least now we can build infinispan-core.
> Scala blueprint generator prevent successfull builds of the core module on JDK 1.9
> ----------------------------------------------------------------------------------
>
> Key: ISPN-6182
> URL: https://issues.jboss.org/browse/ISPN-6182
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 8.1.1.Final
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 8.2.0.CR1
>
>
> On JDK 1.9 the build of some modules fails with:
> error: scala.reflect.internal.MissingRequirementError: object java.lang.Object in compiler mirror not found.
> at scala.reflect.internal.MissingRequirementError$.signal(MissingRequirementError.scala:17)
> at scala.reflect.internal.MissingRequirementError$.notFound(MissingRequirementError.scala:18)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:53)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:66)
> at scala.reflect.internal.Mirrors$RootsBase.getClassByName(Mirrors.scala:102)
> at scala.reflect.internal.Mirrors$RootsBase.getRequiredClass(Mirrors.scala:105)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass$lzycompute(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.init(Definitions.scala:1387)
> at scala.tools.nsc.Global$Run.<init>(Global.scala:1053)
> at scala.tools.nsc.Driver.doCompile(Driver.scala:31)
> at scala.tools.nsc.MainClass.doCompile(Main.scala:23)
> at scala.tools.nsc.Driver.process(Driver.scala:51)
> at scala.tools.nsc.Driver.main(Driver.scala:64)
> at scala.tools.nsc.Main.main(Main.scala)
> The underlying problem is https://issues.scala-lang.org/browse/SI-9103 which means that Scala does not work on JDK 1.9 yet.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6182) Scala blueprint generator does not work on JDK 1.9
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-6182?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-6182:
----------------------------------
Fix Version/s: 8.2.0.CR1
> Scala blueprint generator does not work on JDK 1.9
> --------------------------------------------------
>
> Key: ISPN-6182
> URL: https://issues.jboss.org/browse/ISPN-6182
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 8.1.1.Final
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 8.2.0.CR1
>
>
> On JDK 1.9 the build of some modules fails with:
> error: scala.reflect.internal.MissingRequirementError: object java.lang.Object in compiler mirror not found.
> at scala.reflect.internal.MissingRequirementError$.signal(MissingRequirementError.scala:17)
> at scala.reflect.internal.MissingRequirementError$.notFound(MissingRequirementError.scala:18)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:53)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:66)
> at scala.reflect.internal.Mirrors$RootsBase.getClassByName(Mirrors.scala:102)
> at scala.reflect.internal.Mirrors$RootsBase.getRequiredClass(Mirrors.scala:105)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass$lzycompute(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.init(Definitions.scala:1387)
> at scala.tools.nsc.Global$Run.<init>(Global.scala:1053)
> at scala.tools.nsc.Driver.doCompile(Driver.scala:31)
> at scala.tools.nsc.MainClass.doCompile(Main.scala:23)
> at scala.tools.nsc.Driver.process(Driver.scala:51)
> at scala.tools.nsc.Driver.main(Driver.scala:64)
> at scala.tools.nsc.Main.main(Main.scala)
> The underlying problem is https://issues.scala-lang.org/browse/SI-9103 which means that Scala does not work on JDK 1.9 yet.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6182) Scala blueprint generator does not work on JDK 1.9
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-6182?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-6182:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Scala blueprint generator does not work on JDK 1.9
> --------------------------------------------------
>
> Key: ISPN-6182
> URL: https://issues.jboss.org/browse/ISPN-6182
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 8.1.1.Final
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 8.2.0.CR1
>
>
> On JDK 1.9 the build of some modules fails with:
> error: scala.reflect.internal.MissingRequirementError: object java.lang.Object in compiler mirror not found.
> at scala.reflect.internal.MissingRequirementError$.signal(MissingRequirementError.scala:17)
> at scala.reflect.internal.MissingRequirementError$.notFound(MissingRequirementError.scala:18)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:53)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:66)
> at scala.reflect.internal.Mirrors$RootsBase.getClassByName(Mirrors.scala:102)
> at scala.reflect.internal.Mirrors$RootsBase.getRequiredClass(Mirrors.scala:105)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass$lzycompute(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.init(Definitions.scala:1387)
> at scala.tools.nsc.Global$Run.<init>(Global.scala:1053)
> at scala.tools.nsc.Driver.doCompile(Driver.scala:31)
> at scala.tools.nsc.MainClass.doCompile(Main.scala:23)
> at scala.tools.nsc.Driver.process(Driver.scala:51)
> at scala.tools.nsc.Driver.main(Driver.scala:64)
> at scala.tools.nsc.Main.main(Main.scala)
> The underlying problem is https://issues.scala-lang.org/browse/SI-9103 which means that Scala does not work on JDK 1.9 yet.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6184) Test failure: testNodeLeavesWhileIteratingOverContainerCausingRehashToLoseValues
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6184?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6184:
-------------------------------
Status: Open (was: New)
> Test failure: testNodeLeavesWhileIteratingOverContainerCausingRehashToLoseValues
> --------------------------------------------------------------------------------
>
> Key: ISPN-6184
> URL: https://issues.jboss.org/browse/ISPN-6184
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.2.0.Beta1
> Reporter: Sanne Grinovero
>
> {noformat}~~~~~~~~~~~~~~~~~~~~~~~~~ ENVIRONMENT INFO ~~~~~~~~~~~~~~~~~~~~~~~~~~
> jgroups.bind_addr = 127.0.0.1
> java.runtime.version = 9-ea+101-2016-01-13-182959.javare.4276.nc
> java.runtime.name =Java(TM) SE Runtime Environment
> java.vm.version = 9-ea+101-2016-01-13-182959.javare.4276.nc
> java.vm.vendor = Oracle Corporation
> os.name = Linux
> os.version = 4.3.4-300.fc23.x86_64
> sun.arch.data.model = 64
> sun.cpu.endian = little
> protocol.stack = null
> infinispan.test.jgroups.protocol = tcp
> infinispan.unsafe.allow_jdk8_chm = [Forced: requires JDK8 now]
> java.net.preferIPv4Stack = true
> java.net.preferIPv6Stack = null
> log4.configurationFile = log4j2.xml
> MAVEN_OPTS = null
> ~~~~~~~~~~~~~~~~~~~~~~~~~ ENVIRONMENT INFO ~~~~~~~~~~~~~~~~~~~~~~~~~~
> Tests run: 6722, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 332.801 sec <<< FAILURE! - in TestSuite
> testNodeLeavesWhileIteratingOverContainerCausingRehashToLoseValues(org.infinispan.iteration.DistributedEntryRetrieverTxTest) Time elapsed: 0.037 sec <<< FAILURE!
> org.infinispan.util.concurrent.TimeoutException: Timed out before caches had complete views. Expected 3 members in each view. Views are as follows: [[DistributedEntryRetrieverTxTest-NodeAH-26588|3] (4) [DistributedEntryRetrieverTxTest-NodeAH-26588, DistributedEntryRetrieverTxTest-NodeAI-13493, DistributedEntryRetrieverTxTest-NodeAJ-14867, DistributedEntryRetrieverTxTest-NodeAK-46951], [DistributedEntryRetrieverTxTest-NodeAH-26588|3] (4) [DistributedEntryRetrieverTxTest-NodeAH-26588, DistributedEntryRetrieverTxTest-NodeAI-13493, DistributedEntryRetrieverTxTest-NodeAJ-14867, DistributedEntryRetrieverTxTest-NodeAK-46951], [DistributedEntryRetrieverTxTest-NodeAH-26588|3] (4) [DistributedEntryRetrieverTxTest-NodeAH-26588, DistributedEntryRetrieverTxTest-NodeAI-13493, DistributedEntryRetrieverTxTest-NodeAJ-14867, DistributedEntryRetrieverTxTest-NodeAK-46951]]
> at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:294)
> at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:281)
> at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:379)
> at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:983)
> at org.infinispan.test.MultipleCacheManagersTest.killMember(MultipleCacheManagersTest.java:445)
> at org.infinispan.iteration.DistributedEntryRetrieverTest.testNodeLeavesWhileIteratingOverContainerCausingRehashToLoseValues(DistributedEntryRetrieverTest.java:264)
> 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:520)
> 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.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1158)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632)
> at java.lang.Thread.run(Thread.java:804)
> Results :
> Failed tests:
> DistributedEntryRetrieverTxTest>DistributedEntryRetrieverTest.testNodeLeavesWhileIteratingOverContainerCausingRehashToLoseValues:264->MultipleCacheManagersTest.killMember:445 » Timeout
> Tests run: 6722, Failures: 1, Errors: 0, Skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6184) Test failure: testNodeLeavesWhileIteratingOverContainerCausingRehashToLoseValues
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-6184:
-------------------------------------
Summary: Test failure: testNodeLeavesWhileIteratingOverContainerCausingRehashToLoseValues
Key: ISPN-6184
URL: https://issues.jboss.org/browse/ISPN-6184
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 8.2.0.Beta1
Reporter: Sanne Grinovero
{noformat}~~~~~~~~~~~~~~~~~~~~~~~~~ ENVIRONMENT INFO ~~~~~~~~~~~~~~~~~~~~~~~~~~
jgroups.bind_addr = 127.0.0.1
java.runtime.version = 9-ea+101-2016-01-13-182959.javare.4276.nc
java.runtime.name =Java(TM) SE Runtime Environment
java.vm.version = 9-ea+101-2016-01-13-182959.javare.4276.nc
java.vm.vendor = Oracle Corporation
os.name = Linux
os.version = 4.3.4-300.fc23.x86_64
sun.arch.data.model = 64
sun.cpu.endian = little
protocol.stack = null
infinispan.test.jgroups.protocol = tcp
infinispan.unsafe.allow_jdk8_chm = [Forced: requires JDK8 now]
java.net.preferIPv4Stack = true
java.net.preferIPv6Stack = null
log4.configurationFile = log4j2.xml
MAVEN_OPTS = null
~~~~~~~~~~~~~~~~~~~~~~~~~ ENVIRONMENT INFO ~~~~~~~~~~~~~~~~~~~~~~~~~~
Tests run: 6722, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 332.801 sec <<< FAILURE! - in TestSuite
testNodeLeavesWhileIteratingOverContainerCausingRehashToLoseValues(org.infinispan.iteration.DistributedEntryRetrieverTxTest) Time elapsed: 0.037 sec <<< FAILURE!
org.infinispan.util.concurrent.TimeoutException: Timed out before caches had complete views. Expected 3 members in each view. Views are as follows: [[DistributedEntryRetrieverTxTest-NodeAH-26588|3] (4) [DistributedEntryRetrieverTxTest-NodeAH-26588, DistributedEntryRetrieverTxTest-NodeAI-13493, DistributedEntryRetrieverTxTest-NodeAJ-14867, DistributedEntryRetrieverTxTest-NodeAK-46951], [DistributedEntryRetrieverTxTest-NodeAH-26588|3] (4) [DistributedEntryRetrieverTxTest-NodeAH-26588, DistributedEntryRetrieverTxTest-NodeAI-13493, DistributedEntryRetrieverTxTest-NodeAJ-14867, DistributedEntryRetrieverTxTest-NodeAK-46951], [DistributedEntryRetrieverTxTest-NodeAH-26588|3] (4) [DistributedEntryRetrieverTxTest-NodeAH-26588, DistributedEntryRetrieverTxTest-NodeAI-13493, DistributedEntryRetrieverTxTest-NodeAJ-14867, DistributedEntryRetrieverTxTest-NodeAK-46951]]
at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:294)
at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:281)
at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:379)
at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:983)
at org.infinispan.test.MultipleCacheManagersTest.killMember(MultipleCacheManagersTest.java:445)
at org.infinispan.iteration.DistributedEntryRetrieverTest.testNodeLeavesWhileIteratingOverContainerCausingRehashToLoseValues(DistributedEntryRetrieverTest.java:264)
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:520)
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.access$000(SuiteRunner.java:38)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1158)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632)
at java.lang.Thread.run(Thread.java:804)
Results :
Failed tests:
DistributedEntryRetrieverTxTest>DistributedEntryRetrieverTest.testNodeLeavesWhileIteratingOverContainerCausingRehashToLoseValues:264->MultipleCacheManagersTest.killMember:445 » Timeout
Tests run: 6722, Failures: 1, Errors: 0, Skipped: 0
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6086) Hadoop MapReduce task fails after the prefered ispn server stopped
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-6086?page=com.atlassian.jira.plugin.... ]
Anna Manukyan commented on ISPN-6086:
-------------------------------------
Hi Gustavo,
another update here:
the same issue appears in case when the data is read and write to infinispan server (2 node cluster):
reading from node1, writing result to node2.
While map/reduce execution the node2 is stopped. After map/reduce completion no result is available (in node1 corresponding cache). The stacktrace is attached.
You can find the test here:
https://github.com/andyuk1986/infinispan-hadoop/blob/JBQA-12612/core/src/...
> Hadoop MapReduce task fails after the prefered ispn server stopped
> -------------------------------------------------------------------
>
> Key: ISPN-6086
> URL: https://issues.jboss.org/browse/ISPN-6086
> Project: Infinispan
> Issue Type: Bug
> Components: Hadoop Integration
> Reporter: Anna Manukyan
> Assignee: Gustavo Fernandes
> Attachments: FailoverHandlingTest_WritingToInfinispan.log, FailoverTest_when_prefered_stopped.log
>
>
> I have added tests to the infinispan-hadoop testsuite testing the load balancing of mapreduce task in case if the input server which is specified as a parameter to Hadoop configuration is stopped.
> The test is performed on 4 node cluster. The data read is performed from Infinispan cache, the write is performed to HDFS.
> There are 200000 entries in the cache. As soon as the Hadoop Job is submitted for performing map/reduce task, the preferred server is stopped.
> As a result, the Hadoop Map/Reduce result map is empty.
> You can find the test execution log attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6086) Hadoop MapReduce task fails after the prefered ispn server stopped
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-6086?page=com.atlassian.jira.plugin.... ]
Anna Manukyan updated ISPN-6086:
--------------------------------
Attachment: FailoverHandlingTest_WritingToInfinispan.log
> Hadoop MapReduce task fails after the prefered ispn server stopped
> -------------------------------------------------------------------
>
> Key: ISPN-6086
> URL: https://issues.jboss.org/browse/ISPN-6086
> Project: Infinispan
> Issue Type: Bug
> Components: Hadoop Integration
> Reporter: Anna Manukyan
> Assignee: Gustavo Fernandes
> Attachments: FailoverHandlingTest_WritingToInfinispan.log, FailoverTest_when_prefered_stopped.log
>
>
> I have added tests to the infinispan-hadoop testsuite testing the load balancing of mapreduce task in case if the input server which is specified as a parameter to Hadoop configuration is stopped.
> The test is performed on 4 node cluster. The data read is performed from Infinispan cache, the write is performed to HDFS.
> There are 200000 entries in the cache. As soon as the Hadoop Job is submitted for performing map/reduce task, the preferred server is stopped.
> As a result, the Hadoop Map/Reduce result map is empty.
> You can find the test execution log attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6183) Initial state transfer fails with unexpected timeout
by Vladimir Dzhuvinov (JIRA)
[ https://issues.jboss.org/browse/ISPN-6183?page=com.atlassian.jira.plugin.... ]
Vladimir Dzhuvinov updated ISPN-6183:
-------------------------------------
Description:
Hi guys,
I would like to report a somewhat odd issue with initial state transfer. It was observed in two instances - an Infinispan 7.2.5 cluster with 2 nodes and an Infinispan 7.2.5 cluster with 6 nodes. The two clusters have been running for about a month, the smaller for dev purposes with very light load - about a dozen cached objects. Upon adding an extra node an initial state transfer exception was encountered with both clusters, after about 4 minutes which is the default timeout setting for such situations. Several attempts were made to add a new node, incl. one with increased timeout (10 mins), but state transfer would still not complete, a throw an exception:
{code:java}
"message": "Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl",
"name": "org.infinispan.commons.CacheException",
"cause": {
"commonElementCount": 25,
"localizedMessage": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"message": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"name": "org.infinispan.commons.CacheException",
"extendedStackTrace": [
{
"class": "org.infinispan.statetransfer.StateTransferManagerImpl",
"method": "waitForInitialStateTransferToComplete",
"file": "StateTransferManagerImpl.java",
"line": 222,
"exact": false,
"location": "StateTransferManagerImpl.class",
"version": "?"
},
{code}
The JMX console reported "stateTransferInProgress=true" and "joinComplete=true".
The original clusters where then shut down and started again together with the new node, after which the clusters were successfully formed.
Attached is the exception stack trace and the JGroups config (based on the stock S3 ping).
was:
Hi guys,
I would like to report a somewhat odd issue with initial state transfer. It was observed in two instances - an Infinispan 7.2.5 cluster with 2 nodes and an Infinispan 7.2.5 cluster with 6 nodes. The two clusters have been running for about a month, the smaller for dev purposes with very light load - about a dozen cached objects. Upon adding a third node an initial state transfer exception was encountered with both clusters, after about 4 minutes which is the default timeout setting for such situations. Several attempts were made to add a new node, incl. one with increased timeout (10 mins), but state transfer would still not complete, a throw an exception:
{code:java}
"message": "Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl",
"name": "org.infinispan.commons.CacheException",
"cause": {
"commonElementCount": 25,
"localizedMessage": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"message": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"name": "org.infinispan.commons.CacheException",
"extendedStackTrace": [
{
"class": "org.infinispan.statetransfer.StateTransferManagerImpl",
"method": "waitForInitialStateTransferToComplete",
"file": "StateTransferManagerImpl.java",
"line": 222,
"exact": false,
"location": "StateTransferManagerImpl.class",
"version": "?"
},
{code}
The JMX console reported "stateTransferInProgress=true" and "joinComplete=true".
The original clusters where then shut down and started again together with the new node, after which the clusters were successfully formed.
Attached is the exception stack trace and the JGroups config (based on the stock S3 ping).
> Initial state transfer fails with unexpected timeout
> ----------------------------------------------------
>
> Key: ISPN-6183
> URL: https://issues.jboss.org/browse/ISPN-6183
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.2.5.Final
> Environment: Java 7 on AWS EC2
> Reporter: Vladimir Dzhuvinov
> Attachments: default-jgroups-s3ping.xml, state-transfer-timeout-stack-trace.txt
>
>
> Hi guys,
> I would like to report a somewhat odd issue with initial state transfer. It was observed in two instances - an Infinispan 7.2.5 cluster with 2 nodes and an Infinispan 7.2.5 cluster with 6 nodes. The two clusters have been running for about a month, the smaller for dev purposes with very light load - about a dozen cached objects. Upon adding an extra node an initial state transfer exception was encountered with both clusters, after about 4 minutes which is the default timeout setting for such situations. Several attempts were made to add a new node, incl. one with increased timeout (10 mins), but state transfer would still not complete, a throw an exception:
> {code:java}
> "message": "Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl",
> "name": "org.infinispan.commons.CacheException",
> "cause": {
> "commonElementCount": 25,
> "localizedMessage": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
> "message": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
> "name": "org.infinispan.commons.CacheException",
> "extendedStackTrace": [
> {
> "class": "org.infinispan.statetransfer.StateTransferManagerImpl",
> "method": "waitForInitialStateTransferToComplete",
> "file": "StateTransferManagerImpl.java",
> "line": 222,
> "exact": false,
> "location": "StateTransferManagerImpl.class",
> "version": "?"
> },
> {code}
> The JMX console reported "stateTransferInProgress=true" and "joinComplete=true".
> The original clusters where then shut down and started again together with the new node, after which the clusters were successfully formed.
> Attached is the exception stack trace and the JGroups config (based on the stock S3 ping).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6183) Initial state transfer fails with unexpected timeout
by Vladimir Dzhuvinov (JIRA)
[ https://issues.jboss.org/browse/ISPN-6183?page=com.atlassian.jira.plugin.... ]
Vladimir Dzhuvinov updated ISPN-6183:
-------------------------------------
Description:
Hi guys,
I would like to report a somewhat odd issue with initial state transfer. It was observed in two instances - an Infinispan 7.2.5 cluster with 2 nodes and an Infinispan 7.2.5 cluster with 6 nodes. The two clusters have been running for about a month, the smaller for dev purposes with very light load - about a dozen cached objects. Upon adding an extra node an initial state transfer exception was encountered with both clusters, after about 4 minutes which is the default timeout setting for such situations. Several attempts were made to add a new node, incl. one with increased timeout (10 mins), but state transfer would still not complete, and throw an exception:
{code:java}
"message": "Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl",
"name": "org.infinispan.commons.CacheException",
"cause": {
"commonElementCount": 25,
"localizedMessage": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"message": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"name": "org.infinispan.commons.CacheException",
"extendedStackTrace": [
{
"class": "org.infinispan.statetransfer.StateTransferManagerImpl",
"method": "waitForInitialStateTransferToComplete",
"file": "StateTransferManagerImpl.java",
"line": 222,
"exact": false,
"location": "StateTransferManagerImpl.class",
"version": "?"
},
{code}
The JMX console reported "stateTransferInProgress=true" and "joinComplete=true".
The original clusters where then shut down and started again together with the new node, after which the clusters were successfully formed.
Attached is the exception stack trace and the JGroups config (based on the stock S3 ping).
was:
Hi guys,
I would like to report a somewhat odd issue with initial state transfer. It was observed in two instances - an Infinispan 7.2.5 cluster with 2 nodes and an Infinispan 7.2.5 cluster with 6 nodes. The two clusters have been running for about a month, the smaller for dev purposes with very light load - about a dozen cached objects. Upon adding an extra node an initial state transfer exception was encountered with both clusters, after about 4 minutes which is the default timeout setting for such situations. Several attempts were made to add a new node, incl. one with increased timeout (10 mins), but state transfer would still not complete, a throw an exception:
{code:java}
"message": "Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl",
"name": "org.infinispan.commons.CacheException",
"cause": {
"commonElementCount": 25,
"localizedMessage": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"message": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"name": "org.infinispan.commons.CacheException",
"extendedStackTrace": [
{
"class": "org.infinispan.statetransfer.StateTransferManagerImpl",
"method": "waitForInitialStateTransferToComplete",
"file": "StateTransferManagerImpl.java",
"line": 222,
"exact": false,
"location": "StateTransferManagerImpl.class",
"version": "?"
},
{code}
The JMX console reported "stateTransferInProgress=true" and "joinComplete=true".
The original clusters where then shut down and started again together with the new node, after which the clusters were successfully formed.
Attached is the exception stack trace and the JGroups config (based on the stock S3 ping).
> Initial state transfer fails with unexpected timeout
> ----------------------------------------------------
>
> Key: ISPN-6183
> URL: https://issues.jboss.org/browse/ISPN-6183
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.2.5.Final
> Environment: Java 7 on AWS EC2
> Reporter: Vladimir Dzhuvinov
> Attachments: default-jgroups-s3ping.xml, state-transfer-timeout-stack-trace.txt
>
>
> Hi guys,
> I would like to report a somewhat odd issue with initial state transfer. It was observed in two instances - an Infinispan 7.2.5 cluster with 2 nodes and an Infinispan 7.2.5 cluster with 6 nodes. The two clusters have been running for about a month, the smaller for dev purposes with very light load - about a dozen cached objects. Upon adding an extra node an initial state transfer exception was encountered with both clusters, after about 4 minutes which is the default timeout setting for such situations. Several attempts were made to add a new node, incl. one with increased timeout (10 mins), but state transfer would still not complete, and throw an exception:
> {code:java}
> "message": "Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl",
> "name": "org.infinispan.commons.CacheException",
> "cause": {
> "commonElementCount": 25,
> "localizedMessage": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
> "message": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
> "name": "org.infinispan.commons.CacheException",
> "extendedStackTrace": [
> {
> "class": "org.infinispan.statetransfer.StateTransferManagerImpl",
> "method": "waitForInitialStateTransferToComplete",
> "file": "StateTransferManagerImpl.java",
> "line": 222,
> "exact": false,
> "location": "StateTransferManagerImpl.class",
> "version": "?"
> },
> {code}
> The JMX console reported "stateTransferInProgress=true" and "joinComplete=true".
> The original clusters where then shut down and started again together with the new node, after which the clusters were successfully formed.
> Attached is the exception stack trace and the JGroups config (based on the stock S3 ping).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6183) Initial state transfer fails with unexpected timeout
by Vladimir Dzhuvinov (JIRA)
Vladimir Dzhuvinov created ISPN-6183:
----------------------------------------
Summary: Initial state transfer fails with unexpected timeout
Key: ISPN-6183
URL: https://issues.jboss.org/browse/ISPN-6183
Project: Infinispan
Issue Type: Bug
Components: State Transfer
Affects Versions: 7.2.5.Final
Environment: Java 7 on AWS EC2
Reporter: Vladimir Dzhuvinov
Attachments: default-jgroups-s3ping.xml, state-transfer-timeout-stack-trace.txt
Hi guys,
I would like to report a somewhat odd issue with initial state transfer. It was observed in two instances - an Infinispan 7.2.5 cluster with 2 nodes and an Infinispan 7.2.5 cluster with 6 nodes. The two clusters have been running for about a month, the smaller for dev purposes with very light load - about a dozen cached objects. Upon adding a third node an initial state transfer exception was encountered with both clusters, after about 4 minutes which is the default timeout setting for such situations. Several attempts were made to add a new node, incl. one with increased timeout (10 mins), but state transfer would still not complete, a throw an exception:
{code:java}
"message": "Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl",
"name": "org.infinispan.commons.CacheException",
"cause": {
"commonElementCount": 25,
"localizedMessage": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"message": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"name": "org.infinispan.commons.CacheException",
"extendedStackTrace": [
{
"class": "org.infinispan.statetransfer.StateTransferManagerImpl",
"method": "waitForInitialStateTransferToComplete",
"file": "StateTransferManagerImpl.java",
"line": 222,
"exact": false,
"location": "StateTransferManagerImpl.class",
"version": "?"
},
{code}
The JMX console reported "stateTransferInProgress=true" and "joinComplete=true".
The original clusters where then shut down and started again together with the new node, after which the clusters were successfully formed.
Attached is the exception stack trace and the JGroups config (based on the stock S3 ping).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months