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 commented on WFLY-5822: ------------------------------------------- After two days, two labs, four jobs, one 24 hour soak test, and two reboots of the perf lab machines, I have some 4 node timing results from my ad hoc timing jobs: EAP 7.x - 4 nodes - JDK 8 ----------------- -bash-4.2$ cat eap-7x-perf22-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}' 96.4953 8102435 -bash-4.2$ cat eap-7x-perf23-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}' 94.9006 8118185 -bash-4.2$ cat eap-7x-perf24-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}' 95.6555 8043827 -bash-4.2$ cat eap-7x-perf25-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}' 93.8335 8067639 The job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stre... EAP 6.x - 4 nodes - JDK 8 ----------------- -bash-4.2$ cat eap-6x-perf22-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}' 101.525 5788487 -bash-4.2$ cat eap-6x-perf23-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}' 99.5138 5805899 -bash-4.2$ cat eap-6x-perf24-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}' 100.601 5753810 -bash-4.2$ cat eap-6x-perf25-timing.txt | awk '{print $5}' | awk '{count+=$1;recs+=1} END {print count/recs " " recs}' 100.747 5697932 The job (run with JDK 8): 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

1
0
0 / 0

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

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-6121: ---------------------------------- Summary: Distributed SFSB cache entries may rehash to different nodes following topology change Key: WFLY-6121 URL: https://issues.jboss.org/browse/WFLY-6121 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-5904) A deadlock can result if an EJB is being passivated at the same time an invocation made

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5904?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-5904: ------------------------------- Affects Version/s: 10.0.0.Final > A deadlock can result if an EJB is being passivated at the same time an invocation made > --------------------------------------------------------------------------------------- > > Key: WFLY-5904 > URL: https://issues.jboss.org/browse/WFLY-5904 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 10.0.0.Final > Reporter: Stuart Douglas > Assignee: Paul Ferraro > Attachments: passivationTestFailureDump.txt > > > As seen in EJBClientDescriptorTestCase.testClientInvocationTimeout > This can be reproduced locally by adding a loop around the final invocations in the test: > {code} > for (int i = 0; i < 1000; ++i) {  > Assert.assertEquals("bar", remote1.getManagedBeanMessage());  > Assert.assertEquals("bar", remote2.getManagedBeanMessage());  > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-17) ServerProvisioner doesn't handle <artifact> with content

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFBUILD-17?page=com.atlassian.jira.plugin... ] David Lloyd updated WFBUILD-17: ------------------------------- Fix Version/s: 1.1.3.Final > ServerProvisioner doesn't handle <artifact> with content > -------------------------------------------------------- > > Key: WFBUILD-17 > URL: https://issues.jboss.org/browse/WFBUILD-17 > Project: WildFly Build Tools > Issue Type: Bug > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.3.Final > > > Needs a bigger regex. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-17) ServerProvisioner doesn't handle <artifact> with content

by David Lloyd (JIRA)

David Lloyd created WFBUILD-17: ---------------------------------- Summary: ServerProvisioner doesn't handle <artifact> with content Key: WFBUILD-17 URL: https://issues.jboss.org/browse/WFBUILD-17 Project: WildFly Build Tools Issue Type: Bug Reporter: David Lloyd Assignee: David Lloyd Needs a bigger regex. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6119) service.bat fails when wildfly folder path contains spaces

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-6119?page=com.atlassian.jira.plugin.... ] Cheng Fang reassigned WFLY-6119: -------------------------------- Assignee: Tomaz Cerar (was: Cheng Fang) > service.bat fails when wildfly folder path contains spaces > ---------------------------------------------------------- > > Key: WFLY-6119 > URL: https://issues.jboss.org/browse/WFLY-6119 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 9.0.0.Final > Reporter: Andrea Scarpino > Assignee: Tomaz Cerar > Priority: Minor > > service.bat does not work when Wildfly is run from Program Files (x86) > {noformat} > C:\Program Files (x86)\wildfly-9.0.0.Final\bin\service>service.bat install > Using the X86-64bit version of prunsrv > \wildfly-9.0.0.Final\domain\log non atteso. > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6119) service.bat fails when wildfly folder path contains spaces

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-6119?page=com.atlassian.jira.plugin.... ] Cheng Fang updated WFLY-6119: ----------------------------- Component/s: Scripts (was: Batch) > service.bat fails when wildfly folder path contains spaces > ---------------------------------------------------------- > > Key: WFLY-6119 > URL: https://issues.jboss.org/browse/WFLY-6119 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 9.0.0.Final > Reporter: Andrea Scarpino > Assignee: Cheng Fang > Priority: Minor > > service.bat does not work when Wildfly is run from Program Files (x86) > {noformat} > C:\Program Files (x86)\wildfly-9.0.0.Final\bin\service>service.bat install > Using the X86-64bit version of prunsrv > \wildfly-9.0.0.Final\domain\log non atteso. > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5366) Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.

by Eduardo Silva (JIRA)

[ https://issues.jboss.org/browse/WFLY-5366?page=com.atlassian.jira.plugin.... ] Eduardo Silva commented on WFLY-5366: ------------------------------------- The JBOSS_MARKERFILE variable can be defined, on your shell script. for instance: JBOSS_MARKERFILE=$JBOSS_HOME/standalone/tmp/startup-marker Take a look at: wildfly-VERSION/docs/contrib/scripts/init.d/wildfly-init-redhat.sh > Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently. > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-5366 > URL: https://issues.jboss.org/browse/WFLY-5366 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 10.0.0.CR1 > Environment: Linux/Debian > Reporter: Thorsten Moeller > Fix For: Awaiting Volunteers > > > If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded. > Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same. > I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5149) Accept properties file in scripts for starting as a service

by Eduardo Silva (JIRA)

[ https://issues.jboss.org/browse/WFLY-5149?page=com.atlassian.jira.plugin.... ] Eduardo Silva commented on WFLY-5149: ------------------------------------- Seems that this feature is already done since Wildfly 8: https://docs.jboss.org/author/display/WFLY8/Command+line+parameters ... Instead of passing the parameters directly, you can put them into a properties file, and pass the properties file to the script, as in the two examples below. $JBOSS_HOME/bin/domain.sh --properties=/some/location/jboss.properties $JBOSS_HOME/bin/domain.sh -P=/some/location/jboss.properties ... > Accept properties file in scripts for starting as a service > ----------------------------------------------------------- > > Key: WFLY-5149 > URL: https://issues.jboss.org/browse/WFLY-5149 > Project: WildFly > Issue Type: Feature Request > Components: Scripts > Affects Versions: 10.0.0.Beta1 > Environment: Microsoft Windows > Reporter: Roman Syroeshko > Fix For: Awaiting Volunteers > > > Currently $JBOSS_HOME\bin\service\service.bat does not allow passing properties file. We run WildFly in domain mode using the followed command. > {code} > domain.bat --properties=jboss.properties > {code} > Now, it's impossible to install WildFly as a service like that without hacking out-of-the-box files. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5569) Module dependencies don't work correctly when JAAS login is used in deployments

by Eduardo Silva (JIRA)

[ https://issues.jboss.org/browse/WFLY-5569?page=com.atlassian.jira.plugin.... ] Eduardo Silva commented on WFLY-5569: ------------------------------------- With Elytron replacing JAAS as the integration point with the backing store of identities, this will still being relevant? > Module dependencies don't work correctly when JAAS login is used in deployments > ------------------------------------------------------------------------------- > > Key: WFLY-5569 > URL: https://issues.jboss.org/browse/WFLY-5569 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > > When user wants to use direct JAAS login call from a deployment (e.g. servlet), (s)he will experience problems when LoginModule is placed in custom AS module. > Login modules works correctly if they come from PicketBox, but new modules doesn't work. > This issue is based on [this StackOverflow question|http://stackoverflow.com/questions/33203277/wildfly-and-jaas-log...] -- 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