[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5932:
--------------------------------------
I have a fix for this here: https://github.com/stuartwdouglas/wildfly/tree/WFLY-5932
Unfortunately it requires a new undertow release before it can be merged, as it relies on a new option I had to add to Undertow.
> Invalidating a session of an SSO on a different node than where the session was created does not logout the user
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5932
> URL: https://issues.jboss.org/browse/WFLY-5932
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Priority: Blocker
>
> See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate):
> * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2
> Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected):
> * Access A1, authenticate, invalidate session on A1, access A1
> * Access A1, authenticate, access A2, invalidate session on A1, access A1
> Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-4908) Redeploy dependent ear fails with duplicate resource error for persistence unit
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-4908?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-4908.
------------------------------
Resolution: Done
> Redeploy dependent ear fails with duplicate resource error for persistence unit
> -------------------------------------------------------------------------------
>
> Key: WFLY-4908
> URL: https://issues.jboss.org/browse/WFLY-4908
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 8.2.0.Final, 9.0.0.CR2, 9.0.0.Final, 10.0.0.CR4
> Environment: OS:
> Debian GNU/Linux 8.0 (jessie)
> Linux 3.16.0-4-amd64 x86_64 GNU/Linux
> JVM:
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> Wildfly:
> 9.0.0.Final
> Reporter: Юрий Витковский
> Assignee: Scott Marlow
> Fix For: 10.1.0.Final
>
>
> I have two EARs:
> {code}
> module1.ear
> |
> +--ejb.jar
> |
> +--META-INF
> |
> +--persistence.xml with persistence unit "module1-pu"
> {code}
> and
> {code}
> module2.ear
> |
> +--META-INF
> | |
> | +--jboss-all.xml
> |
> +--ejb.jar
> |
> +--META-INF
> |
> +--persistence.xml with persistence unit "module2-pu"
> {code}
> module2.ear/META-INF/jboss-all.xml contains:
> {code:xml}
> <jboss xmlns="urn:jboss:1.0">
> <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
> <dependency name="module1.ear" />
> </jboss-deployment-dependencies>
> </jboss>
> {code}
> When I redeploy module1.ear, module2.ear not redeployed automatically with error: *java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource module2.ear/ejb.jar#module2-pu* (on wildfly 8.2.0.Final: *java.lang.IllegalStateException: JBAS014666: Duplicate resource module2.ear/ejb.jar#module2-pu*)
> Full redeploy log:
> {code}
> 09:11:31,425 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'module2.ear/ejb.jar#module2-pu'
> 09:11:31,426 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'module2.ear/ejb.jar#module2-pu'
> 09:11:31,431 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'module1.ear/ejb.jar#module1-pu'
> 09:11:31,434 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'module1.ear/ejb.jar#module1-pu'
> 09:11:31,437 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: ejb.jar) in 17ms
> 09:11:31,438 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment module1.ear (runtime-name: module1.ear) in 18ms
> 09:11:31,495 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0009: Undeployed "module1.ear" (runtime-name: "module1.ear")
> 09:11:31,495 INFO [org.jboss.as.controller] (management-handler-thread - 3) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."module1.ear".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."module2.ear".PARSE, service jboss.deployment.subunit."module2.ear"."ejb.jar".PARSE]
>
>
> 09:11:31,558 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /opt/wildfly/standalone/data/content/69/baf0eeab47c006bc1f3d99b21b4355fac62d13/content
> 09:11:43,170 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /opt/wildfly/standalone/data/content/69/baf0eeab47c006bc1f3d99b21b4355fac62d13/content
> 09:11:43,266 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "module1.ear" (runtime-name: "module1.ear")
> 09:11:43,268 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0207: Starting subdeployment (runtime-name: "ejb.jar")
> 09:11:43,273 INFO [org.jboss.as.jpa] (MSC service thread 1-1) WFLYJPA0002: Read persistence.xml for module1-pu
> 09:11:43,289 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'module1.ear/ejb.jar#module1-pu'
> 09:11:43,289 INFO [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 63) HHH000204: Processing PersistenceUnitInfo [
> name: module1-pu
> ...]
> 09:11:43,292 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0010: Starting Persistence Unit (phase 2 of 2) Service 'module1.ear/ejb.jar#module1-pu'
> 09:11:43,293 INFO [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 63) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
> 09:11:43,293 WARN [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 63) HHH000431: Unable to determine H2 database version, certain features may not work
> 09:11:43,294 INFO [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] (ServerService Thread Pool -- 63) HHH000397: Using ASTQueryTranslatorFactory
> 09:11:43,296 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0070: Deployment restart detected for deployment module2.ear, performing full redeploy instead.
> 09:11:43,296 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0070: Deployment restart detected for deployment ejb.jar, performing full redeploy instead.
> 09:11:43,296 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: ejb.jar) in 0ms
> 09:11:43,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment module2.ear (runtime-name: module2.ear) in 1ms
> 09:11:43,298 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "module2.ear" (runtime-name: "module2.ear")
> 09:11:43,299 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0207: Starting subdeployment (runtime-name: "ejb.jar")
> 09:11:43,300 INFO [org.jboss.as.jpa] (MSC service thread 1-2) WFLYJPA0002: Read persistence.xml for module2-pu
> 09:11:43,307 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'module2.ear/ejb.jar#module2-pu'
> 09:11:43,308 INFO [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 63) HHH000204: Processing PersistenceUnitInfo [
> name: module2-pu
> ...]
> 09:11:43,312 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "ejb.jar" of deployment "module2.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource module2.ear/ejb.jar#module2-pu
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:248)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:143)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addManagementConsole(PersistenceUnitServiceHandler.java:1128)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseTwo(PersistenceUnitServiceHandler.java:704)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:289)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleJarDeployment(PersistenceUnitServiceHandler.java:162)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:133)
> at org.jboss.as.jpa.processor.PersistenceCompleteInstallProcessor.deploy(PersistenceCompleteInstallProcessor.java:55)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> ... 5 more
>
>
> 09:11:43,376 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "module1.ear" (runtime-name : "module1.ear")
> 09:11:43,376 INFO [org.jboss.as.controller] (management-handler-thread - 2) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.subunit."module2.ear"."ejb.jar" (unavailable) dependents: [service jboss.deployment.unit."module2.ear".PARSE]
> service jboss.deployment.subunit."module2.ear"."ejb.jar".STRUCTURE (unavailable) dependents: [service jboss.deployment.unit."module2.ear".PARSE]
> service jboss.deployment.subunit."module2.ear"."ejb.jar".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."module2.ear".deploymentCompleteService]
> WFLYCTL0185: Newly corrected services:
> service jboss.deployment.unit."module1.ear".deploymentCompleteService (new available)
> WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."module2.ear"."ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "ejb.jar" of deployment "module2.ear"
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6116) ISPN000112: exception while committing: javax.transaction.xa.XAException
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6116:
------------------------------------
Summary: ISPN000112: exception while committing: javax.transaction.xa.XAException
Key: WFLY-6116
URL: https://issues.jboss.org/browse/WFLY-6116
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
{noformat}
15:34:39,087 WARN [org.infinispan.transaction.tm.DummyTransaction] (default task-1) ISPN000112: exception while committing: javax.transaction.xa.XAException
at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidateImpl(TransactionXaAdapter.java:242)
at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidate(TransactionXaAdapter.java:235)
at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:103)
at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:389)
at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:435)
at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:314)
at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:105)
at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:73)
at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.close(ActiveTransactionBatch.java:48)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:77)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:768)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5850:
--------------------------------------
I think CDI is being to aggressive, I have created https://issues.jboss.org/browse/WFLY-6115
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Stuart Douglas
> Priority: Critical
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 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 2/2/16 12:44 PM:
--------------------------------------------------------------------
I've done an informal measurement of individual invocation response times from the client side by:
(i) instrumenting each EJBClient invocation to measure the time taken to process invoke() and writing that value to sysout on the client node
(ii) collecting up all such measurements on each client and averaging them
Here are the results:
[TIMING] method invocation took 359 ms
[TIMING] method invocation took 333 ms
[TIMING] method invocation took 365 ms
[TIMING] method invocation took 378 ms
[TIMING] method invocation took 388 ms
[TIMING] method invocation took 360 ms
[TIMING] method invocation took 403 ms
[TIMING] method invocation took 316 ms
[TIMING] method invocation took 342 ms
[TIMING] method invocation took 360 ms
[NOTE: these measurements above are not indicative of what happens later on in the test]
.....
-bash-4.2$ cat eap-7x-perf30-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}'
150.916 15786362
-bash-4.2$ cat eap-7x-perf31-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}'
148.895 15676367
----------------------------------
[TIMING] method invocation took 198 ms
[TIMING] method invocation took 197 ms
[TIMING] method invocation took 195 ms
[TIMING] method invocation took 211 ms
[TIMING] method invocation took 209 ms
[TIMING] method invocation took 201 ms
[TIMING] method invocation took 213 ms
[TIMING] method invocation took 214 ms
[TIMING] method invocation took 215 ms
[NOTE: these measurements above are not indicative of what happens later on in the test]
-bash-4.2$ cat eap-6x-perf30-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}'
346.394 8957198
-bash-4.2$ cat eap-6x-perf31-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}'
346.85 8814924
This is both with JDK 8 using a 2 node server configuration.
>From these results, which take measurements from inside the EJB client code, lit looks as though EAP 7 is on average faster. This seems to be corroborated by the response time charts:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stre...
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-6x-stre...
It would be helpful to see the SmartFrog per invocation response times to compare; these would be measures from the client itself.
Also, why is the same test processing double the number of invocations?
Both tests take 44 minutes to run...
Throughput is also better (which may explain the above):
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stre...
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-6x-stre...
was (Author: rachmato):
I've done an informal measurement of individual invocation response times from the client side by:
(i) instrumenting each EJBClient invocation to measure the time taken to process invoke() and writing that value to sysout on the client node
(ii) collecting up all such measurements on each client and averaging them
Here are the results:
[TIMING] method invocation took 359 ms
[TIMING] method invocation took 333 ms
[TIMING] method invocation took 365 ms
[TIMING] method invocation took 378 ms
[TIMING] method invocation took 388 ms
[TIMING] method invocation took 360 ms
[TIMING] method invocation took 403 ms
[TIMING] method invocation took 316 ms
[TIMING] method invocation took 342 ms
[TIMING] method invocation took 360 ms
[NOTE: these measurements above are not indicative of what happens later on in the test]
.....
-bash-4.2$ cat eap-7x-perf30-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}'
150.916 15786362
-bash-4.2$ cat eap-7x-perf31-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}'
148.895 15676367
----------------------------------
[TIMING] method invocation took 198 ms
[TIMING] method invocation took 197 ms
[TIMING] method invocation took 195 ms
[TIMING] method invocation took 211 ms
[TIMING] method invocation took 209 ms
[TIMING] method invocation took 201 ms
[TIMING] method invocation took 213 ms
[TIMING] method invocation took 214 ms
[TIMING] method invocation took 215 ms
[NOTE: these measurements above are not indicative of what happens later on in the test]
-bash-4.2$ cat eap-6x-perf30-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}'
346.394 8957198
-bash-4.2$ cat eap-6x-perf31-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}'
346.85 8814924
This is both with JDK 8 using a 2 node server configuration.
>From these results, which take measurements from inside the EJB client code, lit looks as though EAP 7 is on average faster. This seems to be corroborated by the response time charts:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stre...
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-6x-stre...
It would be helpful to see the SmartFrog per invocation response times to compare; these would be measures from the client itself.
Also, why is the same test processing double the number of invocations?
Both tests take 44 minutes to run...
Throughput is also better:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stre...
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-6x-stre...
> 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)
10 years, 2 months
