February 2016 - jboss-jira - Jboss List Archives

[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:42 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: 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. >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... > 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

1
0
0 / 0

[JBoss JIRA] (WFCORE-1352) Embedded logged leaving filehandles open after stop

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1352?page=com.atlassian.jira.plugi... ] Ken Wills updated WFCORE-1352: ------------------------------ Description: After stop-embedded-server or stop-embedded-host-controller commands, logs in standalone/logs/ or domain/logs/ are still held open. (was: After stop-embedded-server or stop-embedded-host-controller commands, ) > Embedded logged leaving filehandles open after stop > --------------------------------------------------- > > Key: WFCORE-1352 > URL: https://issues.jboss.org/browse/WFCORE-1352 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Environment: Windows > Reporter: Ken Wills > Assignee: Ken Wills > Priority: Minor > > After stop-embedded-server or stop-embedded-host-controller commands, logs in standalone/logs/ or domain/logs/ are still held open. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1334) Allow disabling audit log rotation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1334?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1334: ------------------------------------------ [~thofman] I see. Don't worry about that. That came in https://github.com/wildfly/wildfly-core/pull/497 which was an effort to allow flexibility for a possible future reorganization of where this kind of configuration is located. If we ever do that reorg, the functionality would just be moved elsewhere, including the disabling function covered here. > Allow disabling audit log rotation > ---------------------------------- > > Key: WFCORE-1334 > URL: https://issues.jboss.org/browse/WFCORE-1334 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Affects Versions: 2.0.7.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > https://bugzilla.redhat.com/show_bug.cgi?id=1301554 > org.jboss.as.controller.audit.FileAuditLogHandler always rotates audit-log.log at startup/reload. An option to disable log rotation is necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1352) Embedded logged leaving filehandles open after stop

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1352?page=com.atlassian.jira.plugi... ] Ken Wills updated WFCORE-1352: ------------------------------ Description: After stop-embedded-server or stop-embedded-host-controller commands, (was: JBEAP-1779 makes sure that installed EAP distribution is aligned with the zip as much as possible by removing all post-installation configuration task leftovers. Following directories are not removed by the installer on Windows (server.log file inside of them), once some post-installation configuration task is included (e.g. logging level change). {noformat} EAP-7.0.0\domain\log EAP-7.0.0\standalone\log {noformat} *reproduce* \- Install EAP on Windows, change the level of console logger to Warning) > Embedded logged leaving filehandles open after stop > --------------------------------------------------- > > Key: WFCORE-1352 > URL: https://issues.jboss.org/browse/WFCORE-1352 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Environment: Windows > Reporter: Ken Wills > Assignee: Ken Wills > Priority: Minor > > After stop-embedded-server or stop-embedded-host-controller commands, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1352) Embedded logged leaving filehandles open after stop

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1352?page=com.atlassian.jira.plugi... ] Ken Wills moved JBEAP-3157 to WFCORE-1352: ------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1352 (was: JBEAP-3157) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Logging (was: Packaging and Installation) Target Release: (was: 7.0.0.GA) Affects Version/s: (was: 7.0.0.ER4) > Embedded logged leaving filehandles open after stop > --------------------------------------------------- > > Key: WFCORE-1352 > URL: https://issues.jboss.org/browse/WFCORE-1352 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Environment: Windows > Reporter: Ken Wills > Assignee: Ken Wills > Priority: Minor > > JBEAP-1779 makes sure that installed EAP distribution is aligned with the zip as much as possible by removing all post-installation configuration task leftovers. > Following directories are not removed by the installer on Windows (server.log file inside of them), once some post-installation configuration task is included (e.g. logging level change). > {noformat} > EAP-7.0.0\domain\log > EAP-7.0.0\standalone\log > {noformat} > *reproduce* > \- Install EAP on Windows, change the level of console logger to Warning -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[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:37 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. >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... 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. > 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

1
0
0 / 0

[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: ------------------------------------------- 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. > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-288) SecurityDomainJndiInjectable should allow "java:/jaas" prefixed security domain on demand

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFLY-288?page=com.atlassian.jira.plugin.s... ] Stefan Guilhen closed WFLY-288. ------------------------------- Resolution: Out of Date > SecurityDomainJndiInjectable should allow "java:/jaas" prefixed security domain on demand > ----------------------------------------------------------------------------------------- > > Key: WFLY-288 > URL: https://issues.jboss.org/browse/WFLY-288 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Anil Saldanha > Assignee: Stefan Guilhen > Fix For: 10.1.0.Final > > > Currently, security domain strings of the form "java:/jaas/sd" are not resolving properly. IMO we should allow users to deploy applications on AS4,5,6,7 if they need to. > So have a flag inside the SecurityDomainJndiInjectable class that is turned off by default. If you turn it on, then "java:/jaas" is unprefixed if present. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6064) Distributed SFSB cache entries may rehash to different nodes following topology change

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6064?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-6064: -------------------------------------- Tangent failure in CI: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87591&tab=buil... https://gist.github.com/rhusar/380c8ecb0a03d1284f86 > Distributed SFSB cache entries may rehash to different nodes following topology change > -------------------------------------------------------------------------------------- > > Key: WFLY-6064 > URL: https://issues.jboss.org/browse/WFLY-6064 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR5 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > A distributed SFSB is stored in 2 cache entries, one mapping the bean ID to a serialization group ID, and another mapping the group ID to a map of bean instances. > We ensure that both cache entries will hash to the local node, but following a topology change, these entries could get re-mapped to different nodes. > If we made the group ID = the bean Id of the first bean in the group, this solves the problem for 90% of use cases. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4786) Clustering integration tests fails once -Dnode0 and -Dnode1 are used

by Romain Pelisse (JIRA)

[ https://issues.jboss.org/browse/WFLY-4786?page=com.atlassian.jira.plugin.... ] Romain Pelisse updated WFLY-4786: --------------------------------- Labels: rpelisse_wip (was: ) > Clustering integration tests fails once -Dnode0 and -Dnode1 are used > -------------------------------------------------------------------- > > Key: WFLY-4786 > URL: https://issues.jboss.org/browse/WFLY-4786 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 10.0.0.Alpha3 > Reporter: Petr Kremensky > Assignee: Romain Pelisse > Priority: Minor > Labels: rpelisse_wip > Attachments: maven.logs, results.zip, testsuite.clustering.logs.zip > > > Tests from wildfly-ts-integ-clustering module fails once we change default binding interfaces by -Dnode0 and -Dnode1 properties. > See https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-... > * build 5 binds to localhost (no -Dnode*) > * build 6 uses -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 > Similar failures were addressed for EAP 6 by https://bugzilla.redhat.com/show_bug.cgi?id=1076015 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016