[JBoss JIRA] (WFLY-10417) Security API - Soteria - Jaspic - Error getting ServerAuthContext
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-10417?page=com.atlassian.jira.plugin... ]
Stuart Douglas commented on WFLY-10417:
---------------------------------------
According to giithub the commit I linked has only been part of 5.0.3.Beta1, while WF is on 5.0.2.Final.
> Security API - Soteria - Jaspic - Error getting ServerAuthContext
> -----------------------------------------------------------------
>
> Key: WFLY-10417
> URL: https://issues.jboss.org/browse/WFLY-10417
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 13.0.0.Beta1
> Environment: Wildfly 13.0.0.Beta1 and an EAR Application using JavaEE 8 Security API
> Reporter: Alessandro Moscatelli
> Assignee: Ilia Vassilev
> Priority: Critical
> Fix For: 13.0.0.CR1
>
> Attachments: image-2018-05-24-13-41-05-322.png, soteria.zip
>
>
> I am testing the new Wildfly release and the new Java EE8 Security API.
> I noticed this serious (I truly believe) bug, and it also accours almost randomly.
>
> The deployed application is an EAR.
>
> If I deploy the EAR with a started Wildfly 13.0.0.Beta1 everything is fine.
> Then if I stop and start / restart the application server, I can see the startup and the EAR is redeployed but sometimes (like 50% of time) the bug/error accours.
> Usually after a couple of times (stop/start/restart) I can reproduce the issue.
> Before the bug accours every call to pages and APIs works correctly. After the bug accours every call triggers the AuthException.
> After the bug accours, if I redeploy the SAME EAR everything is fine again 100% of times.
> This seems like Wildfly does something different when redeploying an application on startup and when being already startup up and then processing an application deploy.
>
> I can provide my EAR if you want, but I would prefer not to if this is not necessary.
> The security domain as defined as suggested :
>
> <security-domain name="auth" cache-type="default">
> <authentication-jaspi>
> <login-module-stack name="dummy">
> <login-module code="Dummy" flag="optional"/>
> </login-module-stack>
> <auth-module code="Dummy"/>
> </authentication-jaspi>
> </security-domain>
>
> META-INF/jboss-app.xml inside the EAR :
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-app>
> <security-domain>auth</security-domain>
> </jboss-app>
>
> META-INF/jboss-web.xml inside the WAR inside the EAR :
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>auth</security-domain>
> </jboss-web>
>
> Log :
>
> 17:04:18,556 ERROR [org.jboss.security] (default task-1) PBOX00374: Error getting ServerAuthContext for authContextId default-host /optoplus-services-web and security domain auth: javax.security.auth.message.AuthException
> at org.jboss.security.auth.message.config.JBossServerAuthConfig.getAuthContext(JBossServerAuthConfig.java:187)
> at org.jboss.security.plugins.auth.JASPIServerAuthenticationManager.isValid(JASPIServerAuthenticationManager.java:99)
> at org.wildfly.extension.undertow.security.jaspi.JASPICAuthenticationMechanism.authenticate(JASPICAuthenticationMechanism.java:123)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:48)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> UPDATE !!
> Now I finally got WHY it was random !!
> The problem is related to EAR containing multiple WAR registering different contexts :
> 13:29:37,661 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 80) Initializing Soteria 1.0 for context '/soteria-web2'
> 13:29:37,661 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 76) Initializing Soteria 1.0 for context '/soteria-web'
> 13:29:37,738 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 80) WFLYUT0021: Registered web context: '/soteria-web2' for server 'default-server'
> 13:29:37,745 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/soteria-web' for server 'default-server'
> 13:29:37,781 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "soteria-ear-1.0.0.ear" (runtime-name : "soteria-ear-1.0.0.ear")
> 13:29:37,908 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://0.0.0.0:9990
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Beta1 (WildFly Core 5.0.0.Beta3) started in 10500ms - Started 707 of 931 services (430 services are lazy, passive or on-demand)
> 13:30:09,195 ERROR [org.jboss.security] (default task-1) PBOX00374: Error getting ServerAuthContext for authContextId default-host /soteria-web and security domain auth: javax.security.auth.message.AuthException
> *+In case of a reboot (or stop and start) of Wildfly, only ONE of the TWO contexts manages to get the ServerAuthContext !+*
> I attached an example project you can use to reproduce and detailed steps !
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2596) KieScanner does not load new rules
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2596?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-2596:
-------------------------------------
I reproduced this issue. Note that it only affects stateless session.
> KieScanner does not load new rules
> ----------------------------------
>
> Key: DROOLS-2596
> URL: https://issues.jboss.org/browse/DROOLS-2596
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.6.0.Final, 7.7.0.Final
> Reporter: Viacheslav Krot
> Assignee: Mario Fusco
> Attachments: drools7_bug.zip, drools7_bug_rules.zip
>
>
> There is a problem with adding new rules via KieScanner. If I add new .drl files to rules artifact - new rules are not fired. KieScanner successfully updates artifact, it applies changes to previously loaded rules, but it does not see new rules.
> I've created a simple project reproducing this bug.
> Steps to reproduce:
> - unpack drools7_bug and drools7_bug_rules projects
> - build drools7_bug (mvn clean install)
> - updated repository url in drools7_bug_rules pom, deploy it
> - run Main in drools7_bug. rule1 is fired, prints to stderr once a second.
> - copy rule2.drl from src/main/tmp to src/main/resources. change output string in rule1.
> - deploy artifact
> - now I expect both rules fired, but only rule1 is works, no output from rule2. Make sure new artifact was loaded in scanner jmx bean. Rule1 writes new string to stderr, it was updated.
> - now simply restart Main, both rules are fired.
> There are no error or warning, new rules simply don't work. Am I doing something wrong?
> Same scenario worked perfect until version 7.5.0. You can update version in pom and same scenario passes successfully. 7.6.0 and 7.7.0 don't though
> I added api module with pojos just to reproduce our usecase as close as possible.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10463) Weak affinity set up by EJB client 4 is not followed with invocations running against stateful bean deploment on WildFly 13
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10463?page=com.atlassian.jira.plugin... ]
Paul Ferraro closed WFLY-10463.
-------------------------------
Resolution: Rejected
After running the reproducer, I don't see anything anomalous with the behavior. Setting the provider URL allows the client to discover other nodes in the cluster. The client appropriately load balances SFSB creation to different nodes. All invocations for a given bean consistently invoke on the same node, as there are no topology changes during the test, so weak affinity is always maintained.
> Weak affinity set up by EJB client 4 is not followed with invocations running against stateful bean deploment on WildFly 13
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10463
> URL: https://issues.jboss.org/browse/WFLY-10463
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 13.0.0.Beta1
> Environment: WildFly 13 beta runtimes. EJB client version does not matter (tested with {{org.wildfly:wildfly-ejb-client-bom:12.0.0.Final}}).
> Reporter: Michal Jurc
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: repro.zip
>
>
> Remote EJB client with {{InitialContext}} setting up weak affinity will not hold up the affinity, resulting in a behaviour that's different to previous releases of WildFly. In previous versions of WildFly, {{java.naming.provider.url}} property of {{InitialContext}} was enough to enforce weak affinity to a node in remote EJB client.
> This is a regression compared to WildFly 12. The client version does not change the behaviour, which leads me to believe the issue is server-side.
> Update: The issue affects only stateful bean invocations.
> {code}
> while (true) {
> try {
> final Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName());
> props.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
> final InitialContext ejbCtx = new InitialContext(props);
> final HelloBeanRemote bean = (HelloBeanRemote) ejbCtx
> .lookup("ejb:/server/HelloBean!" + HelloBeanRemote.class.getName() + "?stateful");
> for (int i = 0; i < 10; i++) {
> System.out.println(bean.hello());
> }
> } catch(Exception e) {
> System.out.println("Call failed!!!!");
> e.printStackTrace();
> }
> final Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName());
> props.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
> {code}
> {code}11:56:02,452 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 0
> 11:56:02,460 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 1
> 11:56:02,465 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 2
> 11:56:02,472 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 3
> 11:56:02,477 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 4
> 11:56:02,488 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 5
> 11:56:02,496 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 6
> 11:56:02,502 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 7
> 11:56:02,507 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 8
> 11:56:02,515 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 9
> 11:56:03,535 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 0
> 11:56:03,544 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 1
> 11:56:03,555 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 2
> 11:56:03,561 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 3
> 11:56:03,568 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 4
> 11:56:03,586 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 5
> 11:56:03,595 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 6
> 11:56:03,602 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 7
> 11:56:03,616 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 8
> 11:56:03,628 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 9
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10474) AMQ119012: Timed out waiting to receive initial broadcast from cluster
by Erich Duda (JIRA)
Erich Duda created WFLY-10474:
---------------------------------
Summary: AMQ119012: Timed out waiting to receive initial broadcast from cluster
Key: WFLY-10474
URL: https://issues.jboss.org/browse/WFLY-10474
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 13.0.0.Beta1
Reporter: Erich Duda
Assignee: Jeff Mesnil
Priority: Critical
In messaging HA scenarios we see that tests sometimes fail because of exception \[1\]. The exception is thrown from {{ServerLocatorImpl::createSessionFactory}} which waits until initial broadcast from cluster is received, but it is not received in 10 seconds timeout. In following scenario the issue causes split brain - both live and backup are active at the same time.
*Scenario*
* There are two Wildfly/Artemis servers configured as Live-Backup pair
* Live server is killed
* Backup server becomes new Live server
* Live server is restarted and failback is performed
*Expectation:* Failback performs successfully. Original Live becomes Live again and original Backup becomes Backup again.
*Reality:* After the Live is restarted, it does not detect that there is already another active Live with the same nodeId and it activates (becomes Live) so both Live and Backup are active at the same time.
*Technical details*
I found out that original Live server does not detect that its Backup is active, because SharedNothingLiveActivation::isNodeIdUsed returns false. I added more logs to this method and found out that the {{false}} is returned from line \[2\] after that the exception \[1\] is thrown.
I tried to downgrade Artemis to {{1.5.5.jbossorg-010}} version but I hit the same issue. So the issue is not caused by recent Artemis upgrade.
I am still investigating whether it is regression or not because the failure is intermittent and occurs one from 5 runs.
We see the issue with JGroups. I haven't tried to run the test with Netty multicast configuration yet.
\[1\]
{code}
ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:749) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:627) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connectNoWarnings(ServerLocatorImpl.java:633) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.isNodeIdUsed(SharedNothingLiveActivation.java:280) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:90) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:539) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:485) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:413) [artemis-jms-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
{code}
\[2\] https://github.com/rh-messaging/jboss-activemq-artemis/blob/465eb8733e465...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months