[JBoss JIRA] (ELY-1493) java.util.concurrent.TimeoutException on slow machines
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1493?page=com.atlassian.jira.plugin.s... ]
Martin Choma commented on ELY-1493:
-----------------------------------
I hit this again
13:04:18 java.lang.RuntimeException: java.util.concurrent.TimeoutException
13:04:18 at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:458)
13:04:18 at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testParallelAccessToCS(KeystorePasswordStoreTest.java:439)
13:04:18 Caused by: java.util.concurrent.TimeoutException
13:04:18 at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
13:04:18 at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:456)
13:04:18 ... 1 more
> java.util.concurrent.TimeoutException on slow machines
> ------------------------------------------------------
>
> Key: ELY-1493
> URL: https://issues.jboss.org/browse/ELY-1493
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.2.0.Beta11
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Fix For: 1.2.0.Beta12
>
>
> On solaris 10 (slow machine) there occured timeout for task task2Future.get(1, TimeUnit.SECONDS) on line 492.
> Prolong timeout will probably reduce occurences.
> {noformat}
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:459)
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testParallelAccessToCS(KeystorePasswordStoreTest.java:439)
> Caused by: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:205)
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:457)
> ... 1 more
> Caused by: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest$1.call(KeystorePasswordStoreTest.java:492)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1493) java.util.concurrent.TimeoutException on slow machines
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1493?page=com.atlassian.jira.plugin.s... ]
Martin Choma edited comment on ELY-1493 at 6/14/18 12:09 PM:
-------------------------------------------------------------
I hit this again
{code}
13:04:18 java.lang.RuntimeException: java.util.concurrent.TimeoutException
13:04:18 at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:458)
13:04:18 at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testParallelAccessToCS(KeystorePasswordStoreTest.java:439)
13:04:18 Caused by: java.util.concurrent.TimeoutException
13:04:18 at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
13:04:18 at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:456)
13:04:18 ... 1 more
{code}
was (Author: mchoma):
I hit this again
13:04:18 java.lang.RuntimeException: java.util.concurrent.TimeoutException
13:04:18 at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:458)
13:04:18 at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testParallelAccessToCS(KeystorePasswordStoreTest.java:439)
13:04:18 Caused by: java.util.concurrent.TimeoutException
13:04:18 at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
13:04:18 at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:456)
13:04:18 ... 1 more
> java.util.concurrent.TimeoutException on slow machines
> ------------------------------------------------------
>
> Key: ELY-1493
> URL: https://issues.jboss.org/browse/ELY-1493
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.2.0.Beta11
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Fix For: 1.2.0.Beta12
>
>
> On solaris 10 (slow machine) there occured timeout for task task2Future.get(1, TimeUnit.SECONDS) on line 492.
> Prolong timeout will probably reduce occurences.
> {noformat}
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:459)
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testParallelAccessToCS(KeystorePasswordStoreTest.java:439)
> Caused by: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:205)
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:457)
> ... 1 more
> Caused by: java.util.concurrent.TimeoutException
> at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at org.wildfly.security.credential.store.KeystorePasswordStoreTest$1.call(KeystorePasswordStoreTest.java:492)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10577) Undertow subsystem should not depend on clustering code.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10577?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10577:
------------------------------------
[~pferraro] sorry, I was not precise enough.
WFLY-10352 did not introduce the dependency from undertow to clustering.common, I just noticed it was there while I was looking at the new MSC Service API.
I can understand the dependency to org.wildfly.clustering.service for web cache thingie.
However org.jboss.as.clustering.common does not deal about that. It is an abstraction on top of the Core API, right?
My concern is having subsystem code depends on another one for core features. That makes the whole codebase harder to maintain as we have different ways to do the same thing (dealing with MSC Service in that case).
If the Core API (or the MSC Service API) does not provide the correct abstraction (or need another level of abstraction), these features should be done in a place that benefits all subsystems.
By the way, the dependency from wildfly-undertow to wildfly-clustering-common is not direct and goes through wildfly-security > wildfly-clustering-infinispan-spi:
{code}
~/Developer/wildfly/undertow (master)$ mvn dependency:tree | ack -B 5 clustering.common
[INFO] | +- org.jboss.threads:jboss-threads:jar:2.3.2.Final:compile
[INFO] | \- org.jboss:jboss-vfs:jar:3.2.12.Final:compile
[INFO] +- org.wildfly:wildfly-security:jar:14.0.0.Beta1-SNAPSHOT:compile
[INFO] | +- org.wildfly.core:wildfly-domain-management:jar:6.0.0.Alpha1:compile
[INFO] | +- org.wildfly:wildfly-clustering-infinispan-spi:jar:14.0.0.Beta1-SNAPSHOT:compile
[INFO] | | +- org.wildfly:wildfly-clustering-common:jar:14.0.0.Beta1-SNAPSHOT:compile
~/Developer/wildfly/undertow (master)$
{code}
That's why I was not sure if the dependency was intentional or just a byproduct of being available...
> Undertow subsystem should not depend on clustering code.
> --------------------------------------------------------
>
> Key: WFLY-10577
> URL: https://issues.jboss.org/browse/WFLY-10577
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Jeff Mesnil
> Assignee: Paul Ferraro
>
> With WFLY-10352, Undertow subsystem now depends on Clustering code for Clustering's abstraction of the new MSC Service API. For example https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
> As far as I can tell, the org.jboss.as.clustering.common module is bundled in servlet-feature-pack just so Undertow extension can access its API.
> This is not correct. Undertow should not have to depend on clustering for this kind of abstraction.
> Either these abstractions should be provided by Core or they should not be allowed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10577) Undertow subsystem should not depend on clustering code.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10577?page=com.atlassian.jira.plugin... ]
Paul Ferraro edited comment on WFLY-10577 at 6/14/18 11:10 AM:
---------------------------------------------------------------
[~jmesnil] I think you might be mistaken.
WFLY-10352 did not not introduce any new dependencies to the Undertow subsystem. [1]
org.jboss.as.clustering.common and org.wildfly.clustering.service have been undertow subsystem dependencies for a while now. These dependencies are required so that Undertow's deployment unit processors can build the requisite clustering services for <distributable/> web applications (and for distributed single sign on).
That said, if you would prefer that I relocate some of these jboss-msc and wildfly-controller abstractions used by the clustering SPIs into wildfly-core, I would be in favor of that.
[1] https://github.com/wildfly/wildfly/commits/master/servlet-feature-pack/sr...
was (Author: pferraro):
[~jmesnil] I think you are mistaken.
WFLY-10352 did not not introduce any new dependencies to the Undertow subsystem. [1]
org.jboss.as.clustering.common and org.wildfly.clustering.service have been undertow subsystem dependencies for a while now. These dependencies are required so that Undertow's deployment unit processors can build the requisite clustering services for <distributable/> web applications (and for distributed single sign on).
That said, if you would prefer that I relocate some of these jboss-msc and wildfly-controller abstractions used by the clustering SPIs into wildfly-core, I would be in favor of that.
[1] https://github.com/wildfly/wildfly/commits/master/servlet-feature-pack/sr...
> Undertow subsystem should not depend on clustering code.
> --------------------------------------------------------
>
> Key: WFLY-10577
> URL: https://issues.jboss.org/browse/WFLY-10577
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Jeff Mesnil
> Assignee: Paul Ferraro
>
> With WFLY-10352, Undertow subsystem now depends on Clustering code for Clustering's abstraction of the new MSC Service API. For example https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
> As far as I can tell, the org.jboss.as.clustering.common module is bundled in servlet-feature-pack just so Undertow extension can access its API.
> This is not correct. Undertow should not have to depend on clustering for this kind of abstraction.
> Either these abstractions should be provided by Core or they should not be allowed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3930) Possible file permission issues in .properties files
by Martin Švehla (JIRA)
Martin Švehla created WFCORE-3930:
-------------------------------------
Summary: Possible file permission issues in .properties files
Key: WFCORE-3930
URL: https://issues.jboss.org/browse/WFCORE-3930
Project: WildFly Core
Issue Type: Bug
Components: Build System
Reporter: Martin Švehla
With new galleon build system we discovered differences in .properties files permissions. There's probably not one "true" setting, but the permissions should be reviewed to be consistent across versions (that's why I'm setting priority major, unless we decide it's problem for users).
Possible issue here is mgmt-groups.properties and application-roles.properties being readable by world.
Here are the differences between the last couple of major builds. Most important differences (imho) are:
* *.properties under /bin used to be 664, now they are 644
* /appclient/configuration/logging.properties and /domain/configuration/logging.properties used to be 664, now they're 600 in legacy build, 644 in galleon build
* mgmt-groups.properties and application-roles.properties are 644 in galleon build (i.e. readble by world)
{code}
$ find . -type f -name '*.properties' -exec stat --format '%A %a %n' {} \;
-rw-rw-r-- 664 ./jboss-eap-6.4.20/bin/add-user.properties
-rw-rw-r-- 664 ./jboss-eap-6.4.20/bin/jboss-cli-logging.properties
-rw-rw-r-- 664 ./jboss-eap-6.4.20/appclient/configuration/logging.properties
-rw------- 600 ./jboss-eap-6.4.20/standalone/configuration/mgmt-users.properties
-rw------- 600 ./jboss-eap-6.4.20/standalone/configuration/mgmt-groups.properties
-rw------- 600 ./jboss-eap-6.4.20/standalone/configuration/application-roles.properties
-rw-rw-r-- 664 ./jboss-eap-6.4.20/standalone/configuration/logging.properties
-rw------- 600 ./jboss-eap-6.4.20/standalone/configuration/application-users.properties
-rw------- 600 ./jboss-eap-6.4.20/domain/configuration/mgmt-users.properties
-rw------- 600 ./jboss-eap-6.4.20/domain/configuration/mgmt-groups.properties
-rw------- 600 ./jboss-eap-6.4.20/domain/configuration/application-roles.properties
-rw-rw-r-- 664 ./jboss-eap-6.4.20/domain/configuration/logging.properties
-rw------- 600 ./jboss-eap-6.4.20/domain/configuration/application-users.properties
-rw-rw-r-- 664 ./jboss-eap-7.1.2/bin/add-user.properties
-rw-rw-r-- 664 ./jboss-eap-7.1.2/bin/jboss-cli-logging.properties
-rw-rw-r-- 664 ./jboss-eap-7.1.2/migration/configuration/environment.properties
-rw-rw-r-- 664 ./jboss-eap-7.1.2/migration/configuration/logging.properties
-rw-rw-r-- 664 ./jboss-eap-7.1.2/appclient/configuration/logging.properties
-rw------- 600 ./jboss-eap-7.1.2/standalone/configuration/mgmt-users.properties
-rw------- 600 ./jboss-eap-7.1.2/standalone/configuration/mgmt-groups.properties
-rw------- 600 ./jboss-eap-7.1.2/standalone/configuration/application-roles.properties
-rw-rw-r-- 664 ./jboss-eap-7.1.2/standalone/configuration/logging.properties
-rw------- 600 ./jboss-eap-7.1.2/standalone/configuration/application-users.properties
-rw-rw-r-- 664 ./jboss-eap-7.1.2/domain/configuration/default-server-logging.properties
-rw------- 600 ./jboss-eap-7.1.2/domain/configuration/mgmt-users.properties
-rw------- 600 ./jboss-eap-7.1.2/domain/configuration/mgmt-groups.properties
-rw------- 600 ./jboss-eap-7.1.2/domain/configuration/application-roles.properties
-rw-rw-r-- 664 ./jboss-eap-7.1.2/domain/configuration/logging.properties
-rw------- 600 ./jboss-eap-7.1.2/domain/configuration/application-users.properties
-rw-rw-r-- 664 ./jboss-eap-7.2.0.CD12/bin/add-user.properties
-rw-rw-r-- 664 ./jboss-eap-7.2.0.CD12/bin/jboss-cli-logging.properties
-rw-rw-r-- 664 ./jboss-eap-7.2.0.CD12/appclient/configuration/logging.properties
-rw------- 600 ./jboss-eap-7.2.0.CD12/standalone/configuration/mgmt-users.properties
-rw------- 600 ./jboss-eap-7.2.0.CD12/standalone/configuration/mgmt-groups.properties
-rw------- 600 ./jboss-eap-7.2.0.CD12/standalone/configuration/application-roles.properties
-rw-rw-r-- 664 ./jboss-eap-7.2.0.CD12/standalone/configuration/logging.properties
-rw------- 600 ./jboss-eap-7.2.0.CD12/standalone/configuration/application-users.properties
-rw------- 600 ./jboss-eap-7.2.0.CD12/domain/configuration/mgmt-users.properties
-rw------- 600 ./jboss-eap-7.2.0.CD12/domain/configuration/mgmt-groups.properties
-rw------- 600 ./jboss-eap-7.2.0.CD12/domain/configuration/application-roles.properties
-rw-rw-r-- 664 ./jboss-eap-7.2.0.CD12/domain/configuration/logging.properties
-rw------- 600 ./jboss-eap-7.2.0.CD12/domain/configuration/application-users.properties
-rw-r--r-- 644 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/bin/add-user.properties
-rw-r--r-- 644 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/bin/jboss-cli-logging.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/appclient/configuration/logging.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/standalone/configuration/mgmt-users.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/standalone/configuration/mgmt-groups.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/standalone/configuration/application-roles.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/standalone/configuration/logging.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/standalone/configuration/application-users.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/domain/configuration/default-server-logging.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/domain/configuration/mgmt-users.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/domain/configuration/mgmt-groups.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/domain/configuration/application-roles.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/domain/configuration/logging.properties
-rw------- 600 ./wildfly-legacy-build-14.0.0.Beta1-SNAPSHOT/domain/configuration/application-users.properties
-rw-r--r-- 644 ./wildfly-14.0.0.Beta1-SNAPSHOT/bin/add-user.properties
-rw-r--r-- 644 ./wildfly-14.0.0.Beta1-SNAPSHOT/bin/jboss-cli-logging.properties
-rw-r--r-- 644 ./wildfly-14.0.0.Beta1-SNAPSHOT/appclient/configuration/logging.properties
-rw------- 600 ./wildfly-14.0.0.Beta1-SNAPSHOT/standalone/configuration/mgmt-users.properties
-rw-r--r-- 644 ./wildfly-14.0.0.Beta1-SNAPSHOT/standalone/configuration/mgmt-groups.properties
-rw-r--r-- 644 ./wildfly-14.0.0.Beta1-SNAPSHOT/standalone/configuration/application-roles.properties
-rw-r--r-- 644 ./wildfly-14.0.0.Beta1-SNAPSHOT/standalone/configuration/logging.properties
-rw------- 600 ./wildfly-14.0.0.Beta1-SNAPSHOT/standalone/configuration/application-users.properties
-rw-r--r-- 644 ./wildfly-14.0.0.Beta1-SNAPSHOT/domain/configuration/default-server-logging.properties
-rw------- 600 ./wildfly-14.0.0.Beta1-SNAPSHOT/domain/configuration/mgmt-users.properties
-rw-r--r-- 644 ./wildfly-14.0.0.Beta1-SNAPSHOT/domain/configuration/mgmt-groups.properties
-rw-r--r-- 644 ./wildfly-14.0.0.Beta1-SNAPSHOT/domain/configuration/application-roles.properties
-rw-r--r-- 644 ./wildfly-14.0.0.Beta1-SNAPSHOT/domain/configuration/logging.properties
-rw------- 600 ./wildfly-14.0.0.Beta1-SNAPSHOT/domain/configuration/application-users.propertie
{code}
Note: WF build is current master (commit 7027657)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10577) Undertow subsystem should not depend on clustering code.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10577?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10577:
-------------------------------------
[~jmesnil] I think you are mistaken.
WFLY-10352 did not not introduce any new dependencies to the Undertow subsystem. [1]
org.jboss.as.clustering.common and org.wildfly.clustering.service have been undertow subsystem dependencies for a while now. These dependencies are required so that Undertow's deployment unit processors can build the requisite clustering services for <distributable/> web applications (and for distributed single sign on).
That said, if you would prefer that I relocate some of these jboss-msc and wildfly-controller abstractions used by the clustering SPIs into wildfly-core, I would be in favor of that.
[1] https://github.com/wildfly/wildfly/commits/master/servlet-feature-pack/sr...
> Undertow subsystem should not depend on clustering code.
> --------------------------------------------------------
>
> Key: WFLY-10577
> URL: https://issues.jboss.org/browse/WFLY-10577
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Jeff Mesnil
> Assignee: Paul Ferraro
>
> With WFLY-10352, Undertow subsystem now depends on Clustering code for Clustering's abstraction of the new MSC Service API. For example https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
> As far as I can tell, the org.jboss.as.clustering.common module is bundled in servlet-feature-pack just so Undertow extension can access its API.
> This is not correct. Undertow should not have to depend on clustering for this kind of abstraction.
> Either these abstractions should be provided by Core or they should not be allowed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10562) Initialization of backup fails on Lifecycle context is no longer valid
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10562?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10562:
------------------------------------
[~swd847] this regression occurs because the service can be installed outside the scope of the start context.
In this use case, the Artemis server is started as a backup and put 'on hold'. None of the MSC service that uses Artemis resources are started as they have a dependency on this ActiveMQActivationService (maybe the term "barrier" would have been more appropriate).
When the Artemis becomes live (because its master has stopped and it failed over), we install the activation service which in turn install others Artemis-related service.
Would you be ok if I revert this one to install on the serviceContainer as before?
> Initialization of backup fails on Lifecycle context is no longer valid
> ----------------------------------------------------------------------
>
> Key: WFLY-10562
> URL: https://issues.jboss.org/browse/WFLY-10562
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> *Scenario:*
> * There are two Wildfly servers configured as messaging live-backup pair
> * Live server is killed
> *Expectation:* Backup server will become active.
> *Reality:* Backup server doesn't become active because of failure in initialisation \[1\].
> *Users impact:* Messaging HA does not work.
> *Blocker priority* was chosen because this is regression against Wildfly 13 and breaks all messaging HA scenarios.
> I found out that the regression is caused by WFLY-10538.
> The issue can be reproduced in Wildfly version: 5e5ac8378d7780a2b4c614670e0dd88ca30470d5
> \[1\]
> {code}
> 19:59:17,028 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=fde2ba47-6e7a-11e8-b92f-fa163e6eb24b) AMQ224000: Failure in initialisation: java.lang.IllegalStateException: Lifecycle context is no longer valid
> at org.jboss.msc.service.ServiceControllerImpl$StartContextImpl.getChildTarget(ServiceControllerImpl.java:2016) [jboss-msc-1.4.2.Final.jar:1.4.2.Final]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$3.activated(JMSService.java:163) [wildfly-messaging-activemq-14.0.0.Beta1-SNAPSHOT.jar:14.0.0.Beta1-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivateCallbacks(ActiveMQServerImpl.java:1897) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2112) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.server.impl.SharedStoreBackupActivation.run(SharedStoreBackupActivation.java:90) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2514) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month