[JBoss JIRA] (WFLY-5307) CacheException: Initial state transfer timed out for cache
by Thiago Presa (JIRA)
[ https://issues.jboss.org/browse/WFLY-5307?page=com.atlassian.jira.plugin.... ]
Thiago Presa commented on WFLY-5307:
------------------------------------
Thanks for the response, Radoslav. I ended up opening another issue (see WFLY-5831), where I attach more info from my logs. There is no particular use case - it is being triggered apparently by the EJB cache. I was just trying to deploy a new application in a working WF10 CR4 domain cluster with HA. I have very little knowledge about jgroups and infinispan, so if you can point me to relevant information I can provide that might help, that would be great.
> CacheException: Initial state transfer timed out for cache
> ----------------------------------------------------------
>
> Key: WFLY-5307
> URL: https://issues.jboss.org/browse/WFLY-5307
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Beta1, 10.0.0.CR2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Critical
> Labels: clean_undeploy, clustering_revalidate
> Fix For: 10.0.0.CR4
>
>
> EAP 7.0.0.DR9
> Scenario: failover-ejb-ejbremote-undeploy-dist-async
> During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):
> {code}
> [JBossINF] [0m[0m15:29:55,511 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
> [JBossINF] [0m[0m15:29:55,513 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 86) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> [JBossINF] [0m[0m15:29:55,516 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
> [JBossINF] [0m[0m15:29:55,538 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:55,539 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:56,499 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> [JBossINF] [0m[0m15:30:00,507 INFO [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl@5293c097.
> [JBossINF] [0m[0m15:30:01,323 INFO [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl@4dfb0a03.
> [JBossINF] [0m[33m15:30:55,461 WARN [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF]
> [JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> [JBossINF] at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> [JBossINF] at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
> [JBossINF] at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
> [JBossINF] at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
> [JBossINF] at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
> [JBossINF] ... 4 more
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
> [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
> [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> [JBossINF] ... 19 more
> [JBossINF]
> [JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
> {code}
> Which ends up with WFLYSRV0021: *Deploy of deployment "clusterbench-ee7.ear" was rolled back*.
> In this very same testrun, there was another issue with application deployment on perf20, may be related: JBEAP-1043
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (WFLY-5307) CacheException: Initial state transfer timed out for cache
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5307?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-5307:
--------------------------------------
Thiago, this particular issues was confirmed fixed by QE, can you head over to forums and describe your use case more? (e.g. are you defining your own cache)
> CacheException: Initial state transfer timed out for cache
> ----------------------------------------------------------
>
> Key: WFLY-5307
> URL: https://issues.jboss.org/browse/WFLY-5307
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Beta1, 10.0.0.CR2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Critical
> Labels: clean_undeploy, clustering_revalidate
> Fix For: 10.0.0.CR4
>
>
> EAP 7.0.0.DR9
> Scenario: failover-ejb-ejbremote-undeploy-dist-async
> During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):
> {code}
> [JBossINF] [0m[0m15:29:55,511 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
> [JBossINF] [0m[0m15:29:55,513 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 86) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> [JBossINF] [0m[0m15:29:55,516 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
> [JBossINF] [0m[0m15:29:55,538 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:55,539 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:56,499 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> [JBossINF] [0m[0m15:30:00,507 INFO [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl@5293c097.
> [JBossINF] [0m[0m15:30:01,323 INFO [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl@4dfb0a03.
> [JBossINF] [0m[33m15:30:55,461 WARN [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF]
> [JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> [JBossINF] at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> [JBossINF] at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
> [JBossINF] at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
> [JBossINF] at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
> [JBossINF] at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
> [JBossINF] ... 4 more
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
> [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
> [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> [JBossINF] ... 19 more
> [JBossINF]
> [JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
> {code}
> Which ends up with WFLYSRV0021: *Deploy of deployment "clusterbench-ee7.ear" was rolled back*.
> In this very same testrun, there was another issue with application deployment on perf20, may be related: JBEAP-1043
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (JGRP-1993) ENCRYPTAsymmetricTest fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1993?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1993:
---------------------------
Fix Version/s: 3.6.7
> ENCRYPTAsymmetricTest fails on IBM jdk 1.8
> ------------------------------------------
>
> Key: JGRP-1993
> URL: https://issues.jboss.org/browse/JGRP-1993
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Environment: IBM jdk 1.8
> Reporter: Richard Janík
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange fails on IBM jdk 1.8 (JGroups 3.6.6.Final):
> {code}
> Error Message
> expected [javax.crypto.spec.SecretKeySpec@174de] but found [com.ibm.crypto.provider.AESSecretKey@e562eaa8]
> Stacktrace
> java.lang.AssertionError
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:496)
> at org.testng.Assert.assertEquals(Assert.java:125)
> at org.testng.Assert.assertEquals(Assert.java:167)
> at org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange(ENCRYPTAsymmetricTest.java:404)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1124)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> at org.testng.TestRunner.privateRun(TestRunner.java:774)
> at org.testng.TestRunner.run(TestRunner.java:624)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:359)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312)
> at org.testng.SuiteRunner.run(SuiteRunner.java:261)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.run(TestNG.java:1048)
> at org.testng.TestNG.privateMain(TestNG.java:1355)
> at org.testng.TestNG.main(TestNG.java:1324)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-5822 at 12/10/15 11:07 AM:
----------------------------------------------------------------------
In general, there are two settings which affect creation of SFSBs: max-allowed-connected-nodes in the EJBCLient configuration, and the DeploymentNodeSelector.
max-allowed-connected-nodes determines the maximum number of Remoting connections that can exist between an EJBCLient and a cluster it is connected to. The default is 10. This means that if we have a cluster of 1000 nodes, all 1000 nodes will be known by the client, but only 10 of those nodes will have live Remoting connections open. The client will only select nodes from those which have open connections (and so have an EJBReceiver registered). However, our cluster sizes are generally < 10, so this should not impact the test.
When a session is to be created for an application deployment, the client looks up all nodes which supports that deployment (getEJBReceivers(app, module, distinct) and gets back a list of open connections which support the deployment in the cluster. This list is then passed to the DeploymentNodeSelector which selects one node from the list. The default implementation is based in selecting a node at random.
was (Author: rachmato):
In general, there are two settings which affect creation of SFSBs: max-open-connections in the EJBCLient configuration, and the DeploymentNodeSelector.
max-allowed-connected-nodes determines the maximum number of Remoting connections that can exist between an EJBCLient and a cluster it is connected to. The default is 10. This means that if we have a cluster of 1000 nodes, all 1000 nodes will be known by the client, but only 10 of those nodes will have live Remoting connections open. The client will only select nodes from those which have open connections (and so have an EJBReceiver registered). However, our cluster sizes are generally < 10, so this should not impact the test.
When a session is to be created for an application deployment, the client looks up all nodes which supports that deployment (getEJBReceivers(app, module, distinct) and gets back a list of open connections which support the deployment in the cluster. This list is then passed to the DeploymentNodeSelector which selects one node from the list. The default implementation is based in selecting a node at random.
> Clustering performance regression in ejbremote-dist-sync scenario
> ------------------------------------------------------------------
>
> Key: WFLY-5822
> URL: https://issues.jboss.org/browse/WFLY-5822
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
>
> Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why?
> Compare these results:
> stress-ejbremote-dist-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
> ---------------------------------------
> Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand:
> stress-ejbremote-repl-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-5822:
-------------------------------------------
In general, there are two settings which affect creation of SFSBs: max-open-connections in the EJBCLient configuration, and the DeploymentNodeSelector.
max-allowed-connected-nodes determines the maximum number of Remoting connections that can exist between an EJBCLient and a cluster it is connected to. The default is 10. This means that if we have a cluster of 1000 nodes, all 1000 nodes will be known by the client, but only 10 of those nodes will have live Remoting connections open. The client will only select nodes from those which have open connections (and so have an EJBReceiver registered). However, our cluster sizes are generally < 10, so this should not impact the test.
When a session is to be created for an application deployment, the client looks up all nodes which supports that deployment (getEJBReceivers(app, module, distinct) and gets back a list of open connections which support the deployment in the cluster. This list is then passed to the DeploymentNodeSelector which selects one node from the list. The default implementation is based in selecting a node at random.
> Clustering performance regression in ejbremote-dist-sync scenario
> ------------------------------------------------------------------
>
> Key: WFLY-5822
> URL: https://issues.jboss.org/browse/WFLY-5822
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
>
> Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why?
> Compare these results:
> stress-ejbremote-dist-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
> ---------------------------------------
> Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand:
> stress-ejbremote-repl-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
