[JBoss JIRA] (JBTM-2495) Installing Blacktie 5.2.2 with Wildfly 9.0.1.Final Fails: Docs needs to say use WFLY "master" (or appropriate)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2495?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2495:
--------------------------------
Fix Version/s: (was: 5.next)
> Installing Blacktie 5.2.2 with Wildfly 9.0.1.Final Fails: Docs needs to say use WFLY "master" (or appropriate)
> --------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2495
> URL: https://issues.jboss.org/browse/JBTM-2495
> Project: JBoss Transaction Manager
> Issue Type: Sub-task
> Components: BlackTie, Documentation
> Affects Versions: 5.0.0.M2
> Environment: RHEL 6.3
> Reporter: Joice Joy
> Assignee: Amos Feng
> Priority: Minor
>
> I am installing Blacktie 5.2.2 Final with Wildfly 9.0.1 but the Wildfly server fails to start the Blacktie service
> But the server does not start the blacktie service:
> This is from quickstart quickstart/blacktie
>
>
>
> =========================================================================
>
>
> JBoss Bootstrap Environment
>
>
> JBOSS_HOME: /fxtest/trep/wildfly/wildfly-9.0.1.Final
>
>
> JAVA: /fxtest/trep/java/jdk1.8.0_51/bin/java
>
>
> JAVA_OPTS: -server -XX:+UseCompressedOops -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE
>
>
> =========================================================================
>
>
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
> 07:35:52,490 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final
> 07:35:52,892 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 07:35:53,007 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0049: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) starting
> 07:35:55,053 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'job-repository-type' in the resource at address '/subsystem=batch' 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.
> 07:35:55,055 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' 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.
> 07:35:55,121 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment blacktie-admin-services-ear-5.2.2.Final.ear
> 07:35:55,361 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 24) WFLYDR0001: Content added at location /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/content/6a/4973c6ad23d3978c57f955fd341a56f1bc550a/content
> 07:35:55,390 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> 07:35:55,422 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.1.Final
> 07:35:55,438 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.1.Final
> 07:35:55,482 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.9.Final
> 07:35:55,548 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem.
> 07:35:55,554 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors
> 07:35:55,557 INFO [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 42) WFLYIIOP0001: Activating IIOP Subsystem
> 07:35:55,602 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.4.Final)
> 07:35:55,615 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main]
> 07:35:55,652 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 07:35:55,661 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem
> 07:35:55,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0018: Started Driver service with driver-name = h2
> 07:35:55,827 INFO [org.jboss.as.security] (ServerService Thread Pool -- 59) WFLYSEC0002: Activating Security Subsystem
> 07:35:55,829 INFO [org.jboss.as.security] (MSC service thread 1-4) WFLYSEC0001: Current PicketBox version=4.9.2.Final
> 07:35:55,849 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> 07:35:55,849 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension
> 07:35:55,998 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.2.9.Final starting
> 07:35:56,034 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.2.9.Final starting
> 07:35:56,095 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service
> 07:35:56,119 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
> 07:35:56,352 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path /fxtest/trep/wildfly/wildfly-9.0.1.Final/welcome-content
> 07:35:56,417 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012: Started server default-server.
> 07:35:56,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting
> 07:35:56,589 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080
> 07:35:56,945 INFO [org.wildfly.iiop.openjdk] (MSC service thread 1-3) WFLYIIOP0009: CORBA ORB Service started
> 07:35:56,969 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 07:35:57,030 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) WFLYDS0013: Started FileSystemDeploymentService for directory /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/deployments
> 07:35:57,059 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name: "blacktie-admin-services-ear-5.2.2.Final.ear")
> 07:35:57,187 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221000: live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingjournal,bindingsDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingbindings,largeMessagesDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messaginglargemessages,pagingDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingpaging)
> 07:35:57,193 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221006: Waiting to obtain live lock
> 07:35:57,287 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221012: Using AIO Journal
> 07:35:57,387 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support CORE
> 07:35:57,414 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Final
> 07:35:57,439 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support AMQP
> 07:35:57,443 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support STOMP
> 07:35:57,502 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221034: Waiting to obtain live lock
> 07:35:57,504 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221035: Live Server Obtained live lock
> 07:35:58,108 INFO [org.jboss.messaging] (MSC service thread 1-3) WFLYMSG0016: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor acceptor
> 07:35:58,112 INFO [org.jboss.messaging] (MSC service thread 1-1) WFLYMSG0016: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor-throughput acceptor
> 07:35:58,206 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221007: Server is now live
> 07:35:58,207 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221001: HornetQ Server version 2.4.7.Final (2.4.7.Final, 124) [9d12c6a3-4666-11e5-8632-95a54ac84561]
> 07:35:58,210 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221003: trying to deploy queue jms.queue.ExpiryQueue
> 07:35:58,514 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 66) WFLYMSG0002: Bound messaging object to jndi name java:/ConnectionFactory
> 07:35:58,519 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 67) WFLYMSG0002: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> 07:35:58,519 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 65) HQ221003: trying to deploy queue jms.queue.DLQ
> 07:35:58,623 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0007: Registered connection factory java:/JmsXA
> 07:35:58,721 INFO [org.hornetq.ra] (MSC service thread 1-4) HornetQ resource adaptor started
> 07:35:58,721 INFO [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-4) IJ020002: Deployed: file://RaActivatorhornetq-ra
> 07:35:58,733 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0002: Bound JCA ConnectionFactory [java:/JmsXA]
> 07:35:58,733 INFO [org.jboss.as.messaging] (MSC service thread 1-4) WFLYMSG0002: Bound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jaxb-api.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference.
> 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jaxb-impl.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference.
> 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jsr173_1.0_api.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference.
> 07:35:58,763 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry activation.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference.
> 07:35:58,780 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "blacktie-admin-services-5.2.2.Final.jar")
> 07:35:58,885 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "blacktie-admin-services-5.2.2.Final.jar" of deployment "blacktie-admin-services-ear-5.2.2.Final.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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml
> at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:98)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> ... 5 more
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml
> at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:95)
> ... 6 more
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
> Message: Unexpected element '{urn:jboss:messaging-activemq-deployment:1.0}messaging-deployment'
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:89)
> ... 6 more
>
>
> 07:35:58,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "blacktie-admin-services-ear-5.2.2.Final.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"blacktie-admin-services-ear-5.2.2.Final.ear\".\"blacktie-admin-services-5.2.2.Final.jar\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"blacktie-admin-services-ear-5.2.2.Final.ear\".\"blacktie-admin-services-5.2.2.Final.jar\".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment \"blacktie-admin-services-5.2.2.Final.jar\" of deployment \"blacktie-admin-services-ear-5.2.2.Final.ear\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
> Message: Unexpected element '{urn:jboss:messaging-activemq-deployment:1.0}messaging-deployment'"}}
> 07:35:58,980 INFO [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name : "blacktie-admin-services-ear-5.2.2.Final.ear")
> 07:35:58,982 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "blacktie-admin-services-5.2.2.Final.jar" of deployment "blacktie-admin-services-ear-5.2.2.Final.ear"
>
>
> 07:35:59,202 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 07:35:59,202 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> 07:35:59,202 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) started (with errors) in 7156ms - Started 247 of 423 services (2 services failed or missing dependencies, 222 services are lazy, passive or on-demand)
> 07:35:59,243 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: blacktie-admin-services-5.2.2.Final.jar) in 9ms
> 07:35:59,332 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment blacktie-admin-services-ear-5.2.2.Final.ear (runtime-name: blacktie-admin-services-ear-5.2.2.Final.ear) in 98ms
> 07:35:59,413 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0002: Content removed from location /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/content/6a/4973c6ad23d3978c57f955fd341a56f1bc550a/content
> 07:35:59,414 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0009: Undeployed "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name: "blacktie-admin-services-ear-5.2.2.Final.ear")
> 07:35:59,414 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2409:
--------------------------------
Fix Version/s: 5.next
> XARecoveryModuleHelpersUnitTest hang
> ------------------------------------
>
> Key: JBTM-2409
> URL: https://issues.jboss.org/browse/JBTM-2409
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.1.1
> Reporter: Michael Musgrove
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
> Attachments: 32287.jstack, hang.jstack
>
>
> The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang.
> The junit test thread:
> - starts 2 threads that will remove a recovery helper
> - triggers xaRecoveryModule.periodicWorkFirstPass()
> - triggers xaRecoveryModule.periodicWorkSecondPass()
> - joins with remover threads
> The jstack output shows:
> - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish;
> - the junit test thread is waiting to join with these two threads;
> Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2409:
--------------------------------
Priority: Minor (was: Major)
> XARecoveryModuleHelpersUnitTest hang
> ------------------------------------
>
> Key: JBTM-2409
> URL: https://issues.jboss.org/browse/JBTM-2409
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.1.1
> Reporter: Michael Musgrove
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.next
>
> Attachments: 32287.jstack, hang.jstack
>
>
> The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang.
> The junit test thread:
> - starts 2 threads that will remove a recovery helper
> - triggers xaRecoveryModule.periodicWorkFirstPass()
> - triggers xaRecoveryModule.periodicWorkSecondPass()
> - joins with remover threads
> The jstack output shows:
> - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish;
> - the junit test thread is waiting to join with these two threads;
> Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (JBTM-2419) Consider reducing the number of JMH perf test forks on PRs
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2419?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2419:
--------------------------------
Fix Version/s: 5.next
> Consider reducing the number of JMH perf test forks on PRs
> ----------------------------------------------------------
>
> Key: JBTM-2419
> URL: https://issues.jboss.org/browse/JBTM-2419
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Testing
> Affects Versions: 5.1.1
> Reporter: Michael Musgrove
> Fix For: 5.next
>
>
> We run our JMH tests multiple times in order to estimate run-to-run variance. The [JMH docs|http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/m...] state:
> bq. JVMs are complex systems, and the non-determinism is inherent for them. This requires us to always account the run-to-run variance as the one of the effects in our experiments. Forking aggregates the results across several JVM launches.
> Currently we set the number of forks to 10. We run each test 6 times with each run lasting 1 min. Since we have 10 tests this means it takes 10 * 10 * 6 minutes for the benchmarks to complete. In the future we want to keep adding new performance tests and the time taken to run a PR will become prohibitive. I would like to propose one of the following solutions:
> - reduce the number of forks;
> - run a subset of performance tests on each PR and then run them all once a week or so on the main build
> My preference is to reduce the number of forks to 3. Note that the PR requester has the option to disable performance tests for his PR (by including !PERF in the comment section).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (JBTM-2419) Consider reducing the number of JMH perf test forks on PRs
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2419?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2419:
--------------------------------
Priority: Minor (was: Major)
> Consider reducing the number of JMH perf test forks on PRs
> ----------------------------------------------------------
>
> Key: JBTM-2419
> URL: https://issues.jboss.org/browse/JBTM-2419
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Testing
> Affects Versions: 5.1.1
> Reporter: Michael Musgrove
> Priority: Minor
> Fix For: 5.next
>
>
> We run our JMH tests multiple times in order to estimate run-to-run variance. The [JMH docs|http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/m...] state:
> bq. JVMs are complex systems, and the non-determinism is inherent for them. This requires us to always account the run-to-run variance as the one of the effects in our experiments. Forking aggregates the results across several JVM launches.
> Currently we set the number of forks to 10. We run each test 6 times with each run lasting 1 min. Since we have 10 tests this means it takes 10 * 10 * 6 minutes for the benchmarks to complete. In the future we want to keep adding new performance tests and the time taken to run a PR will become prohibitive. I would like to propose one of the following solutions:
> - reduce the number of forks;
> - run a subset of performance tests on each PR and then run them all once a week or so on the main build
> My preference is to reduce the number of forks to 3. Note that the PR requester has the option to disable performance tests for his PR (by including !PERF in the comment section).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months