[JBoss JIRA] (WFCORE-995) Add possibility to enable debug mode by setting environment variable in standalone scripts
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-995?page=com.atlassian.jira.plugin... ]
Tomaz Cerar reassigned WFCORE-995:
----------------------------------
Assignee: Tomaz Cerar (was: James Perkins)
> Add possibility to enable debug mode by setting environment variable in standalone scripts
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-995
> URL: https://issues.jboss.org/browse/WFCORE-995
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Scripts
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> It's common practice in Docker to control image run by configuring environment variables.
> E.g.
> {code:bash}
> docker run -e POSTGRES_PASSWORD=mysecretpassword -d postgres
> {code}
> The Cloud Enablement team adds such a possibility to EAP docker images. They [replaces|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-d...] initial value of {{DEBUG_MODE}}:
> {code:bash}
> # Enhance standalone.sh to make remote JAVA debugging possible by specifying
> # DEBUG=true environment variable
> sed -i 's|DEBUG_MODE=false|DEBUG_MODE="${DEBUG:-false}"|' $JBOSS_HOME/bin/standalone.sh
> {code}
> It's not a clean solution. This change should be made in original scripts and not on a Dockerfile level.
> Please allow configuring the {{DEBUG_MODE}} from environment variables (in similar as e.g. the {{JAVA_OPTS}} are handled.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5654) Arquillian use "-Djava.net.preferIPv4Stack=true" also with IPv6
by Marek Kopecký (JIRA)
Marek Kopecký created WFLY-5654:
-----------------------------------
Summary: Arquillian use "-Djava.net.preferIPv4Stack=true" also with IPv6
Key: WFLY-5654
URL: https://issues.jboss.org/browse/WFLY-5654
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 10.0.0.CR4
Reporter: Marek Kopecký
Assignee: Marek Kopecký
*Description of problem:*
Arquillian use "-Djava.net.preferIPv4Stack=true" also with IPv6 profile. This property is set in AbstractCommandBuilder of WildFly-Core:
https://github.com/wildfly/wildfly-core/blob/master/launcher/src/main/jav...
There should be option for disable of this option in arquillian.xml file. And testsuite should use this option with IPv6 profile.
*How reproducible:*
Always
*Steps to Reproduce:*
# ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIPV6_1 -Dnode1=$MYTESTIPV6_2 -Dipv6 -Dts.manualmode -Dtest=OutboundLdapConnectionTestCase -DtestLogToFile=false -Djboss.dist=$JBOSS_DIST -Dts.noSmoke
*Actual results:*
{noformat}
07:04:26,054 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/jdk1.8.0_last/bin/java,
...
-Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv4Stack=false
...
{noformat}
*Expected results:*
EAP is not started with "-Djava.net.preferIPv4Stack=true" property with IPv6 profile
*Additional info:*
Jenkins reproducer job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5653) Arquillian use "-Djava.net.preferIPv4Stack=true" also with IPv6 profile
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-5653?page=com.atlassian.jira.plugin.... ]
Marek Kopecký moved JBEAP-1862 to WFLY-5653:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5653 (was: JBEAP-1862)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Test Suite
(was: Test Suite)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR4
(was: 7.0.0.DR13 (Alpha))
> Arquillian use "-Djava.net.preferIPv4Stack=true" also with IPv6 profile
> -----------------------------------------------------------------------
>
> Key: WFLY-5653
> URL: https://issues.jboss.org/browse/WFLY-5653
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.CR4
> Reporter: Marek Kopecký
> Assignee: Marek Kopecký
>
> *Description of problem:*
> Arquillian use "-Djava.net.preferIPv4Stack=true" also with IPv6 profile. This property is set in AbstractCommandBuilder of WildFly-Core:
> https://github.com/wildfly/wildfly-core/blob/master/launcher/src/main/jav...
> There should be option for disable of this option in arquillian.xml file. And testsuite should use this option with IPv6 profile.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIPV6_1 -Dnode1=$MYTESTIPV6_2 -Dipv6 -Dts.manualmode -Dtest=OutboundLdapConnectionTestCase -DtestLogToFile=false -Djboss.dist=$JBOSS_DIST -Dts.noSmoke
> *Actual results:*
> {noformat}
> 07:04:26,054 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/jdk1.8.0_last/bin/java,
> ...
> -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv4Stack=false
> ...
> {noformat}
> *Expected results:*
> EAP is not started with "-Djava.net.preferIPv4Stack=true" property with IPv6 profile
> *Additional info:*
> Jenkins reproducer job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5520) EAP 6 HA migrated configs fails to boot server
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-5520?page=com.atlassian.jira.plugin.... ]
Ladislav Thon commented on WFLY-5520:
-------------------------------------
https://issues.jboss.org/browse/WFLY-5092?focusedCommentId=13097893#comme... has a list of mgmt operations that are required to migrate EAP 6.4 configuration. Since we have to do additional steps beyond {{:migrate}} anyway (removing the legacy subsystems and extensions), I'm personally fine with the requirement of performing {{/subsystem=ejb3:undefine-attribute(name=default-clustered-sfsb-cache)}} (if it is documented!). On the other hand, I agree that it's basically a bug :-)
Can we get a decision if we want to fix this or not? [~rhusar] (as the assignee)?
> EAP 6 HA migrated configs fails to boot server
> ----------------------------------------------
>
> Key: WFLY-5520
> URL: https://issues.jboss.org/browse/WFLY-5520
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR2
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
> Attachments: eap-6.1-migrated-configs.zip, eap-6.4-migrated-configs.zip
>
>
> If you try (curated) EAP 6 standalone-ha.xml configuration on WildFly the server will fail to boot due to an EJB3 subsystem attribute.
> Server boot console log:
> mbp:migration-tests emmartins$ ./default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT/bin/standalone.sh -c standalone-ha.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/emmartins/wildfly/migration-tests/default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 11:37:25,583 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 11:37:25,896 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 11:37:25,985 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) starting
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 7) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'default-clustered-sfsb-cache' in the resource at address '/subsystem=ejb3' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,385 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: "WFLYEJB0451: Attribute 'default-clustered-sfsb-cache' is not supported on current version servers; it is only allowed if its value matches 'default-sfsb-cache'"
> 11:37:27,586 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem ejb3 boot operations"
> 11:37:27,588 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem ejb3 boot operations\""
> 11:37:27,591 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 11:37:27,594 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 11:37:27,603 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) stopped in 6ms
> Attached is the standalone-ha.xml config, with just threads subsystem removed, and web subsystem migrated to undertow, that should be able to boot the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JBVFS-202) Invalid Local file header in ZIP file
by Martin Both (JIRA)
[ https://issues.jboss.org/browse/JBVFS-202?page=com.atlassian.jira.plugin.... ]
Martin Both commented on JBVFS-202:
-----------------------------------
I've found the main bug in class VirtualJarFileInputStream.
The method "private byte get()" returns sometimes a legal 0xFF value
which is read in method "public int read()".
But the conversion of the byte value 0xFF in an int value results in -1.
The value -1 results in a next state and cuts the current state abruptly.
You have to change the get method to
private int get() {
return buffer[bufferPosition++] & 0xFF;
}
Now the Zip file has still invalid(!) crc check sums but it will be read without ZipExceptions.
So there are more bugs in this part of JBoss but I do not care at this point.
You see the old class VirtualJarFileInputStream is very untestet and buggy.
My answer how to readjust the bugs is: Simple use the class and you will see it does'nt work.
Now the deployment of my project with embedded EJBContainer is one step further but
still it does not work. Maybe another bug in JBoss? I think so.
Caused by: java.lang.NullPointerException
at org.jboss.wsf.stack.cxf.metadata.MetadataBuilder.createDDEndpoint(MetadataBuilder.java:213)
at org.jboss.wsf.stack.cxf.metadata.MetadataBuilder.build(MetadataBuilder.java:83)
at org.jboss.wsf.stack.cxf.deployment.aspect.DescriptorDeploymentAspect.generateMetadataFromDeployment(DescriptorDeploymentAspect.java:135)
at org.jboss.wsf.stack.cxf.deployment.aspect.DescriptorDeploymentAspect.start(DescriptorDeploymentAspect.java:68)
> Invalid Local file header in ZIP file
> -------------------------------------
>
> Key: JBVFS-202
> URL: https://issues.jboss.org/browse/JBVFS-202
> Project: JBoss VFS
> Issue Type: Bug
> Reporter: Martin Both
> Assignee: Tomaz Cerar
>
> I'm try to use the Embeddable EJBContainer of JBoss EAP 6.4.
> I get a ZipException: invalid CEN header (bad signature)
> JBoss writes an invalid Zip- file in
> JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6/content
> The reason is, that the zip file content contains a Local file header with no size for the file data. No Zip-Tool can unzip that and even JBoss cannot read that again.
> Compare the method bufferLocalFileHeader() with the method bufferNextCentralFileHeader() of class org.jboss.vfs,VirtualJarFileInputStream.
> The one wirtes file sizes the other one not. If you would read the file format specification of zip files than you would know that after the LocallFileHeader the file data is written. Without knowledge of the compressed size it is not possible to read that.
> Deployment with Embeddable EJBContainer does not work for me due to this bug.
> Trace:
> 2015-11-09 11:16:02,392 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.4.0.GA (AS 7.5.0.Final-redhat-21) wurde gestartet in 2502ms - 168 von 205 Diensten gestartet (61 Services sind "lazy", passiv oder werden bei Bedarf geladen)
> 2015-11-09 11:16:03,094 INFO [org.jboss.as.repository] (pool-4-thread-1) JBAS014900: Content an Speicherort C:\Users\A300859\workspaces\ProKom2.0_trunk\Servers\JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6\content hinzugefügt
> 2015-11-09 11:16:03,120 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starte Deployment von "classes" (runtime-name: "classes")
> 2015-11-09 11:16:03,159 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit.classes.STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment "classes" fehlgeschlagen
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:97) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 5 more
> Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)
> at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.8.0_60]
> at java.util.zip.ZipFile.<init>(ZipFile.java:219) [rt.jar:1.8.0_60]
> at java.util.zip.ZipFile.<init>(ZipFile.java:149) [rt.jar:1.8.0_60]
> at java.util.jar.JarFile.<init>(JarFile.java:166) [rt.jar:1.8.0_60]
> at java.util.jar.JarFile.<init>(JarFile.java:130) [rt.jar:1.8.0_60]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:90) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:77) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:386) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:410) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentMountProvider$Factory$ServerDeploymentRepositoryImpl.mountDeploymentContent(DeploymentMountProvider.java:105) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:93) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 6 more
> 2015-11-09 11:16:03,161 ERROR [org.jboss.as.controller.management-operation] (pool-4-thread-1) JBAS014612: Operation ("deploy") fehlgeschlagen - Adresse: ([("deployment" => "classes")]) - Fehlerbeschreibung: {"JBAS014671: Fehlgeschlagene Dienste" => {"jboss.deployment.unit.classes.STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment \"classes\" fehlgeschlagen
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
> Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)"}}
> 2015-11-09 11:16:03,163 ERROR [org.jboss.as.server] (pool-4-thread-1) JBAS015870: Deploy von Deployment "classes" wurde mit folgender Fehlermeldung zurückgesetzt:
> {"JBAS014671: Fehlgeschlagene Dienste" => {"jboss.deployment.unit.classes.STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment \"classes\" fehlgeschlagen
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
> Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)"}}
> 2015-11-09 11:16:03,165 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Deployment von classes in (runtime-name: "classes") 2ms gestoppt
> 2015-11-09 11:16:03,166 INFO [org.jboss.as.controller] (pool-4-thread-1) JBAS014774: Dienst-Statusbericht
> JBAS014777: Dienste, deren Start fehlgeschlagen ist: service jboss.deployment.unit.classes.STRUCTURE
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5389) NPE during activation of backup server in colocated replicated topology
by Ondřej Kalman (JIRA)
[ https://issues.jboss.org/browse/WFLY-5389?page=com.atlassian.jira.plugin.... ]
Ondřej Kalman updated WFLY-5389:
--------------------------------
Summary: NPE during activation of backup server in colocated replicated topology (was: NPE during activation of backup server in collocated replicated topology)
> NPE during activation of backup server in colocated replicated topology
> -----------------------------------------------------------------------
>
> Key: WFLY-5389
> URL: https://issues.jboss.org/browse/WFLY-5389
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR1
> Reporter: Ondřej Kalman
> Assignee: Clebert Suconic
>
> I'm getting this exception when one of nodes in collocated replicated topology fails and backup is trying to get up.
> 11:41:44,643 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: java.lang.NullPointerException
> at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> 11:41:44,644 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) java.lang.NullPointerException
> 11:41:44,644 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
> 11:41:44,645 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1049) ConcreteResourceRegistration#registerSubModel is not thread safe
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1049?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1049:
------------------------------------------
I've been looking into the cost of just doing synchronization/locking instead of what's in https://github.com/wildfly/wildfly-core/pull/1207.
I been testing boot time on my quad core macbook, looking at various approaches to solving this. I tested standalone boot time with the standalone.xml and standalone-full.xml configs. I would shut down all CPU-draining apps, build the server, then start/stop the config 4 times to warm any FS caches, and then start/stop the server 7 times recording the logged start up time. I'd throw out the lowest and highest value and calc an average of the other 5. Results, in ms, standalone.xml and then standalone-full.xml:
master[1] 2479 3395
no-lock[2] 2547 3276
sync[3] 2561 3363
lock[4] 2568 3358
lock2[5] 2546 3340
[1] The "master" figures are current WildFly master.
[2] https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... (PR #1207)
[3] Locking using "synchronized" -- https://github.com/wildfly/wildfly-core/compare/master...bstansberry:sync...
[4] Locking using java.util.concurrent.lock https://github.com/wildfly/wildfly-core/compare/master...bstansberry:lock...
[5] Same as 4 but a slight change in locking in one method. https://github.com/wildfly/wildfly-core/compare/master...bstansberry:lock... -- submitted as https://github.com/wildfly/wildfly-core/pull/1231
Since [5] is competitive with [2] with the default profile, and is competitive with master with the full profile, I'll go with [5]. It is conceptually simpler than [2].
Interestingly enough, through quite a few various boot time tests (not just those reported above) I'd see the approaches using locking performing better than master for the "full" profile, while performing worse for the default profile. The latter is not surprising; the former is. My *guess* is this is because master uses FastCopyHashMap, copying the map for every attribute/operation/child addition. The locking approaches don't need this copying, since the maps are guarded. My guess is full includes more subsystems with more attributes, so more copying cost.
I don't delude myself that these figures are highly precise. :) But I've done enough tests to sense that they are reasonable; there is some cost to this fix but not a huge one, and maybe little or none with the full profile.
> ConcreteResourceRegistration#registerSubModel is not thread safe
> ----------------------------------------------------------------
>
> Key: WFCORE-1049
> URL: https://issues.jboss.org/browse/WFCORE-1049
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Stuart Douglas
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> registerSubModel checks for existing, then registers, however it is invoked by two threads at the same time it is possible they will both see the resource as not existing and both register.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months