[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/31/15 11:50 AM:
----------------------------------------------------------------------
Just based on a very preliminary check of the number of gets and puts in the test (my disk drive is full and I can't easily download these large logs in their entirety), I see the following stats on perf18 when I run the test for 3 iterations:
EAP 6.4.0.GA
# ISPN gets: 6776
# ISPN puts: 6843
EAP 7.0.0.DR4
# ISPN gets: ~ 700,000 (yes, seven hundred thousand)
# ISPN puts: 109
In other words, in the EAP 7 test, there are an abnormal amount of gets being made to the cache for what should be roughly the same number of client invocations arriving at the server as we are running the same test on two server versions. There are also too few puts its seems.
was (Author: rachmato):
Just based on a very preliminary check of the number of gets and puts in the test (my disk drive is full and I can't easily download these large logs in their entirety), I see the following stats on perf18 when I run the test for 3 iterations:
EAP 6.4.0.GA
# ISPN gets: 6776
# ISPN puts: 6843
EAP 7.0.0.DR4
# ISPN gets: ~ 700,000 (yes, seven hundred thousand)
# ISPN puts: 109
In other words, in the EAP 7 test, there are an abnormal amount of gets being made to the cache for what should be roughly the same number of client invocations arriving at the server as we are running the same test on two server versions.
> 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
> Priority: Critical
>
> 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)
9 years, 11 months
[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1982:
--------------------------------
Even better: a ring buffer with {{high}} and {{llow}} markers: unless {{low +1 > high}}, we never have to shift (copy) data toward the left. If that condition is true, we have to grow the buffer. Also consider shrinking (compacting) the ring buffer.
> RequestCorrelator: use IntHashMap / LongHashmap for request correlation
> -----------------------------------------------------------------------
>
> Key: JGRP-1982
> URL: https://issues.jboss.org/browse/JGRP-1982
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 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 commented on JGRP-1993:
--------------------------------
Richard, do you have a box with IBM JDK 8 on which I can reproduce this ?
> 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
> Priority: Minor
> Fix For: 3.6.8
>
>
> 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)
9 years, 11 months
[JBoss JIRA] (WFCORE-591) revertReloadRequired() throws a NPE is reloadRequired has not been called
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-591?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-591:
------------------------------------------------
Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1294591|https://bugzilla.redhat.com/show_bug.cgi?id=1294591] from VERIFIED to ASSIGNED
> revertReloadRequired() throws a NPE is reloadRequired has not been called
> -------------------------------------------------------------------------
>
> Key: WFCORE-591
> URL: https://issues.jboss.org/browse/WFCORE-591
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha19
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 1.0.0.Beta1
>
>
> If an operation step handler calls org.jboss.as.controller.OperationContext#revertReloadRequired() when org.jboss.as.controller.OperationContext#reloadRequired() has not been called, it throws a NPE:
> {noformat}
> java.lang.NullPointerException
> at org.jboss.as.controller.ControlledProcessState.revertReloadRequired(ControlledProcessState.java:181)
> at org.jboss.as.controller.AbstractOperationContext.revertReloadRequired(AbstractOperationContext.java:1037)
> at org.jboss.as.controller.test.RevertReloadRequiredTestCase$TestResourceAddHandler.rollbackRuntime(RevertReloadRequiredTestCase.java:98)
> at org.jboss.as.controller.AbstractAddStepHandler$1$1.handleRollback(AbstractAddStepHandler.java:133)
> at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1419)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1385)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1367)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1323)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1283)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1172)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:929)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1182)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205)
> {noformat}
> The NPE is caused by this.activeStep.restartStamp field which is set only when reloadRequired() (or restartRequired()) is called.
> My OSH may call reloadRequired() or not depending on some runtime state and I could add some logic to make sure I call
> I can fix my handle to check that I call context.revertReloadRequired() only I had previously called reloadRequired () first.
> However, in order to make the OperationContext more robust, I think that the revertReloadRequired() method should instead be a no-op if there is no reload required.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1257) support query filter implementation in MBeanServerConnection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1257?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated WFCORE-1257:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1294010
Bugzilla Update: Perform
> support query filter implementation in MBeanServerConnection
> ------------------------------------------------------------
>
> Key: WFCORE-1257
> URL: https://issues.jboss.org/browse/WFCORE-1257
> Project: WildFly Core
> Issue Type: Feature Request
> Components: JMX
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
>
> There is no implementation for query filter in MBeanServerConnection, marked as TODO
> {code:title=ModelControllerMBeanHelper.java|borderStyle=solid}
> Set<ObjectName> queryNames(final ObjectName name, final QueryExp query) {
> return new RootResourceIterator<Set<ObjectName>>(accessControlUtil, getRootResourceAndRegistration().getResource(),
> new ObjectNameMatchResourceAction<Set<ObjectName>>(name) {
> Set<ObjectName> set = new HashSet<ObjectName>();
> @Override
> public boolean onResource(ObjectName resourceName) {
> if (name == null || name.apply(resourceName)) {
> //TODO check query
> set.add(resourceName);
> }
> return true;
> }
> @Override
> public Set<ObjectName> getResult() {
> if (set.size() == 1 && set.contains(ModelControllerMBeanHelper.createRootObjectName(domain))) {
> return Collections.emptySet();
> }
> return set;
> }
> }).iterate();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1257) support query filter implementation in MBeanServerConnection
by Chao Wang (JIRA)
Chao Wang created WFCORE-1257:
---------------------------------
Summary: support query filter implementation in MBeanServerConnection
Key: WFCORE-1257
URL: https://issues.jboss.org/browse/WFCORE-1257
Project: WildFly Core
Issue Type: Feature Request
Components: JMX
Affects Versions: 2.0.5.Final
Reporter: Chao Wang
There is no implementation for query filter in MBeanServerConnection, marked as TODO
{code:title=ModelControllerMBeanHelper.java|borderStyle=solid}
Set<ObjectName> queryNames(final ObjectName name, final QueryExp query) {
return new RootResourceIterator<Set<ObjectName>>(accessControlUtil, getRootResourceAndRegistration().getResource(),
new ObjectNameMatchResourceAction<Set<ObjectName>>(name) {
Set<ObjectName> set = new HashSet<ObjectName>();
@Override
public boolean onResource(ObjectName resourceName) {
if (name == null || name.apply(resourceName)) {
//TODO check query
set.add(resourceName);
}
return true;
}
@Override
public Set<ObjectName> getResult() {
if (set.size() == 1 && set.contains(ModelControllerMBeanHelper.createRootObjectName(domain))) {
return Collections.emptySet();
}
return set;
}
}).iterate();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5918) ServletContext.getResourceAsStream fails in latest CR5 version
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5918?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-5918:
---------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> ServletContext.getResourceAsStream fails in latest CR5 version
> --------------------------------------------------------------
>
> Key: WFLY-5918
> URL: https://issues.jboss.org/browse/WFLY-5918
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.CR5
> Environment: Wildfly 10.0.0 CR5
> Windows 7
> JDK 1.8_66 64Bit
> Reporter: Alban Chadenas
> Assignee: Stuart Douglas
>
> Struts 1 ActionServlet fails to initialize with latest Wildfly 10.0.0 CR5 though it was working fine on the previous CR4 release. The failure occurs when Servlet tries to read the /WEB-INF/web.xml inside my web application.
> Looking at the struts source code, getServletContext().getResourceAsStream("/WEB-INF/web.xml") returns null during the Servlet initialization.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 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/30/15 2:33 PM:
---------------------------------------------------------------------
Set up some basic byteman scripts to dump out the following information on the server side. The node specified in [BYTEMAN-Get (node)] is the node the invocation is being processed on.
Infinispan processing a get request in DistributionInterceptor. Dumps out command, isOriginLocal. origin, cacheTopologyId, primaryOwner and isKeyLocal:
{noformat}
[BYTEMAN-Get(perf18)] command = GetKeyValueCommand {key=eac549bf-6076-4d09-a6c4-1f9f545e8c6a, flags=null}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan processing a put request in DistributionInterceptor. Dumps out command, isOriginLocal. origin, cacheTopologyId, primaryOwner and isKeyLocal:
{noformat}
[BYTEMAN-Put(perf18)] command = PutKeyValueCommand{key=UnknownSessionID [6868556952675068536750685266705766505570704954555069526651494854], value=org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanEntry@1bb137da, flags=[FORCE_SYNCHRONOUS], putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan needing to do a remote get for a value during DistributionInterceptor processing. Dumps out the key which needs to be accessed remotely:
{noformat}
[BYTEMAN-RetrieveFromRemote(perf18)] key = perf18
{noformat}
This is a first approximation to seeing what is going on here.
The jobs are here:
EAP 6.4.0.GA
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
EAP 7.0.0.DR4
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
was (Author: rachmato):
Set up some basic byteman scripts to dump out the following information on the server side. The node specified in [BYTEMAN-Get (node)] is the node the invocation is being processed on.
Infinispan processing a get request in DistributionInterceptor:
{noformat}
[BYTEMAN-Get(perf18)] command = GetKeyValueCommand {key=eac549bf-6076-4d09-a6c4-1f9f545e8c6a, flags=null}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan processing a put request in DistributionInterceptor:
{noformat}
[BYTEMAN-Put(perf18)] command = PutKeyValueCommand{key=UnknownSessionID [6868556952675068536750685266705766505570704954555069526651494854], value=org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanEntry@1bb137da, flags=[FORCE_SYNCHRONOUS], putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan needing to do a remote get for a value during DistributionInterceptor processing:
{noformat}
[BYTEMAN-RetrieveFromRemote(perf18)] key = perf18
{noformat}
This is a first approximation to seeing what is going on here.
The jobs are here:
EAP 6.4.0.GA
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
EAP 7.0.0.DR4
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
> 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
> Priority: Critical
>
> 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)
9 years, 11 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/30/15 2:22 PM:
---------------------------------------------------------------------
Set up some basic byteman scripts to dump out the following information on the server side. The node specified in [BYTEMAN-Get (node)] is the node the invocation is being processed on.
Infinispan processing a get request in DistributionInterceptor:
{noformat}
[BYTEMAN-Get(perf18)] command = GetKeyValueCommand {key=eac549bf-6076-4d09-a6c4-1f9f545e8c6a, flags=null}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan processing a put request in DistributionInterceptor:
{noformat}
[BYTEMAN-Put(perf18)] command = PutKeyValueCommand{key=UnknownSessionID [6868556952675068536750685266705766505570704954555069526651494854], value=org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanEntry@1bb137da, flags=[FORCE_SYNCHRONOUS], putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan needing to do a remote get for a value during DistributionInterceptor processing:
{noformat}
[BYTEMAN-RetrieveFromRemote(perf18)] key = perf18
{noformat}
This is a first approximation to seeing what is going on here.
The jobs are here:
EAP 6.4.0.GA
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
EAP 7.0.0.DR4
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
was (Author: rachmato):
Set up some basic byteman scripts to dump out the following information on the server side:
Infinispan processing a get request in DistributionInterceptor:
{noformat}
[BYTEMAN-Get(perf18)] command = GetKeyValueCommand {key=eac549bf-6076-4d09-a6c4-1f9f545e8c6a, flags=null}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan processing a put request in DistributionInterceptor:
{noformat}
[BYTEMAN-Put(perf18)] command = PutKeyValueCommand{key=UnknownSessionID [6868556952675068536750685266705766505570704954555069526651494854], value=org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanEntry@1bb137da, flags=[FORCE_SYNCHRONOUS], putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan needing to do a remote get for a value during DistributionInterceptor processing:
{noformat}
[BYTEMAN-RetrieveFromRemote(perf18)] key = perf18
{noformat}
This is a first approximation to seeing what is going on here.
The jobs are here:
EAP 6.4.0.GA
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
EAP 7.0.0.DR4
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
> 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
> Priority: Critical
>
> 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)
9 years, 11 months
