[JBoss JIRA] (DROOLS-3038) [DMN Designer] Added type can not be resolved
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3038?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3038:
-------------------------------------
[~karreiro] Here is video, will be stored for 30 days https://webmshare.com/Nyx31
> [DMN Designer] Added type can not be resolved
> ---------------------------------------------
>
> Key: DROOLS-3038
> URL: https://issues.jboss.org/browse/DROOLS-3038
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-09-26 12-57-20.png, Screenshot from 2018-09-26 12-58-02.png, Screenshot from 2018-09-26 12-58-12.png
>
>
> {{12:53:34,884 ERROR [org.kie.dmn.core.compiler.DMNCompilerImpl] (EJB default - 3) Unable to resolve type reference 'tNum' on node 'Decision-1'}} is error shown to user after reopening DMN model with used new defined item definition.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10638) Eliminate "Transactional caches are not supported." log warning from ORM 5.3.* deployments
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10638?page=com.atlassian.jira.plugin... ]
Scott Marlow closed WFLY-10638.
-------------------------------
> Eliminate "Transactional caches are not supported." log warning from ORM 5.3.* deployments
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-10638
> URL: https://issues.jboss.org/browse/WFLY-10638
> Project: WildFly
> Issue Type: Task
> Components: Clustering, JPA / Hibernate
> Affects Versions: 13.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 15.0.0.Alpha1
>
>
> Currently, during deployment of ORM 5.3.* applications, the following warning is logged in the server console, four times per persistence unit. It should not appear at all.
> {quote}
> HHH025030: Transactional caches are not supported. The configuration option will be ignored; please unset.
> {quote}
> The warning comes from ORM 5.3 integration code org.infinispan.hibernate.cache.v53.InfinispanRegionFactory#unsetTransactions.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1682:
------------------------------
Description:
{code:title=HipChat conversation}
Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential.
But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok.
I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case).
In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting
though for that one as that is where that loop happens but start with an ELY issue
{code}
was:
{code:title=HipChat conversation}
Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting though for that one as that is where that loop happens but start with an ELY issue
{code}
> Fallback to another SASL client mechanism when SASL client initialisation fails
> -------------------------------------------------------------------------------
>
> Key: ELY-1682
> URL: https://issues.jboss.org/browse/ELY-1682
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt
>
>
> {code:title=HipChat conversation}
> Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential.
> But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok.
> I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
> Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
> Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case).
> In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
> Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting
> though for that one as that is where that loop happens but start with an ELY issue
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1682:
------------------------------
Attachment: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt
> Fallback to another SASL client mechanism when SASL client initialisation fails
> -------------------------------------------------------------------------------
>
> Key: ELY-1682
> URL: https://issues.jboss.org/browse/ELY-1682
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt
>
>
> {code:title=HipChat conversation}
> Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
> Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
> Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
> Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting though for that one as that is where that loop happens but start with an ELY issue
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-4130) JwtValidator jku and kid header parameters
by Martin Mazanek (JIRA)
Martin Mazanek created WFCORE-4130:
--------------------------------------
Summary: JwtValidator jku and kid header parameters
Key: WFCORE-4130
URL: https://issues.jboss.org/browse/WFCORE-4130
Project: WildFly Core
Issue Type: Enhancement
Reporter: Martin Mazanek
Assignee: Martin Mazanek
Priority: Minor
JwtValidator implementation is missing some useful header parameters: kid for supporting multiple keys and jku for using remotes as a source of public keys.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10920) IllegalStateException: java.util.ConcurrentModificationException
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-10920?page=com.atlassian.jira.plugin... ]
tommaso borgato updated WFLY-10920:
-----------------------------------
Affects Version/s: 14.0.1.Final
> IllegalStateException: java.util.ConcurrentModificationException
> ----------------------------------------------------------------
>
> Key: WFLY-10920
> URL: https://issues.jboss.org/browse/WFLY-10920
> Project: WildFly
> Issue Type: Bug
> Components: MP Config
> Affects Versions: 14.0.1.Final, 14.0.0.Final
> Reporter: tommaso borgato
> Assignee: Jeff Mesnil
> Attachments: clusterbench-ee7-shared-sessions.ear, clusterbench-ee7.ear, perf18-consoleText.txt
>
>
> One of the many affected scenarios is [perflab_eap-7x-failover-http-session-shutdown-dist-sync-shared-sessions|h...]: it is a 4 nodes (running with the standalone-ha.xml configuration) fail-over scenario where the deployed EAR contains two WAR sharing http sessions:
> {{clusterbench-ee7-shared-sessions.ear/META-INF/jboss-all.xml}}:
> {noformat}
> <jboss umlns="urn:jboss:1.0">
> <shared-session-config xmlns="urn:jboss:shared-session-config:1.0">
> <session-config>
> <cookie-config>
> <path>/</path>
> </cookie-config>
> </session-config>
> </shared-session-config>
> </jboss>
> {noformat}
> During server shut-down the EAR is stopped and we observe the following error:
> {noformat}
> [JBossINF] [0m[0m05:49:46,803 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 99) WFLYCLINF0003: Stopped clusterbench-ee7-shared-sessions.ear cache from web container
> [JBossINF] [0m[0m05:49:46,805 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel ejb
> [JBossINF] [0m[31m05:49:46,813 ERROR [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0043: Deployment unit processor org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor@6953f688 unexpectedly threw an exception during undeploy phase POST_MODULE of subdeployment "clusterbench-ee7-web-default-2.war" of deployment "clusterbench-ee7-shared-sessions.ear": java.util.ConcurrentModificationException
> [JBossINF] at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
> [JBossINF] at java.util.HashMap$EntryIterator.next(HashMap.java:1476)
> [JBossINF] at java.util.HashMap$EntryIterator.next(HashMap.java:1474)
> [JBossINF] at io.smallrye.config.SmallRyeConfigProviderResolver.releaseConfig(SmallRyeConfigProviderResolver.java:71)
> [JBossINF] at org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.undeploy(SubsystemDeploymentProcessor.java:102)
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.safeUndeploy(DeploymentUnitPhaseService.java:211)
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:204)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1792)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1761)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> [JBossINF] [0m[31m05:49:46,812 ERROR [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0043: Deployment unit processor org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor@6953f688 unexpectedly threw an exception during undeploy phase POST_MODULE of subdeployment "clusterbench-ee7-web-default-1.war" of deployment "clusterbench-ee7-shared-sessions.ear": java.util.ConcurrentModificationException
> [JBossINF] at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
> [JBossINF] at java.util.HashMap$EntryIterator.next(HashMap.java:1476)
> [JBossINF] at java.util.HashMap$EntryIterator.next(HashMap.java:1474)
> [JBossINF] at io.smallrye.config.SmallRyeConfigProviderResolver.releaseConfig(SmallRyeConfigProviderResolver.java:71)
> [JBossINF] at org.wildfly.extension.microprofile.config.smallrye.deployment.SubsystemDeploymentProcessor.undeploy(SubsystemDeploymentProcessor.java:102)
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.safeUndeploy(DeploymentUnitPhaseService.java:211)
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.stop(DeploymentUnitPhaseService.java:204)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1792)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1761)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Also other scenarios like [perflab_eap-7x-failover-http-session-shutdown-dist-sync-nb-state-transfer...] and [perflab_eap-7x-failover-remote-jdg-session-shutdown-invalidation-sync-hot...] exhibits the same error: I assume it does not depend on the shared sessions configuration mentioned above;
> Find attached:
> - the complete server log (perf18-consoleText.txt)
> - the EAR used for the shared-sessions scenario (clusterbench-ee7-shared-sessions.ear)
> - the EAR used for the [perflab_eap-7x-failover-http-session-shutdown-dist-sync-nb-state-transfer...] scenario (clusterbench-ee7.ear)
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails
by Martin Choma (JIRA)
Martin Choma created ELY-1682:
---------------------------------
Summary: Fallback to another SASL client mechanism when SASL client initialisation fails
Key: ELY-1682
URL: https://issues.jboss.org/browse/ELY-1682
Project: WildFly Elytron
Issue Type: Bug
Components: SASL
Affects Versions: 1.7.0.CR1
Reporter: Martin Choma
{code:title=HipChat conversation}
Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting though for that one as that is where that loop happens but start with an ELY issue
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-3038) [DMN Designer] Added type can not be resolved
by Guilherme Carreiro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3038?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro commented on DROOLS-3038:
--------------------------------------------
[~jomarko],
I couldn't reproduce this issue locally. Could you please attach a video? Probably I'm missing some step.
Thank you.
> [DMN Designer] Added type can not be resolved
> ---------------------------------------------
>
> Key: DROOLS-3038
> URL: https://issues.jboss.org/browse/DROOLS-3038
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-09-26 12-57-20.png, Screenshot from 2018-09-26 12-58-02.png, Screenshot from 2018-09-26 12-58-12.png
>
>
> {{12:53:34,884 ERROR [org.kie.dmn.core.compiler.DMNCompilerImpl] (EJB default - 3) Unable to resolve type reference 'tNum' on node 'Decision-1'}} is error shown to user after reopening DMN model with used new defined item definition.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-9896) Cluster-cluster EJB transactional invocation rolls back if stateful bean is used and JBOSS-LOCAL-USER auth is not possible
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-9896?page=com.atlassian.jira.plugin.... ]
tommaso borgato updated WFLY-9896:
----------------------------------
Affects Version/s: 14.0.1.Final
> Cluster-cluster EJB transactional invocation rolls back if stateful bean is used and JBOSS-LOCAL-USER auth is not possible
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9896
> URL: https://issues.jboss.org/browse/WFLY-9896
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Transactions
> Affects Versions: 14.0.1.Final, 11.0.0.Final, 12.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
>
> Scenario:
> - server-1 (intermediary)
> -- Running standalone-ha profile (important)
> -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address
> -- Doesn't matter if the intermediary bean is stateless or stateful
> - server-2 (target)
> -- On a different machine than server-1 (important, otherwise transaction manager uses JBOSS-LOCAL-USER auth)
> -- Running standalone-ha profile (important)
> -- Target bean needs to be stateful (important)
> - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target bean on server-2.
> The first invocation is handled by EJB on target server, but when the transaction should be committed, The following is the log observed on server-1 (and also on the client):
> {code}
> 03:58:27,439 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.GA (WildFly Core 3.0.10.Final-redhat-1) started in 12893ms - Started 1013 of 1226 services (458 services are lazy, passive or on-demand)
> 03:59:00,563 INFO [org.wildfly.naming] (default task-7) WildFly Naming version 1.0.7.Final-redhat-1
> 03:59:00,585 INFO [org.jboss.ejb.client] (default task-7) JBoss EJB Client version 4.0.9.Final-redhat-1
> 03:59:01,335 INFO [stdout] (default task-7) Intermediate Stateless WhoAmIBean.whoAmI called as anonymous
> 03:59:01,809 WARN [com.arjuna.ats.arjuna] (default task-7) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffff0a105a36:-2ab20799:5a2f9a2b:1c, org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization@24aead2a >: org.wildfly.transaction.client.SynchronizationException: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client.XAOutflowedResources$1.beforeCompletion(XAOutflowedResources.java:83)
> at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:209)
> at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:220)
> at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:265)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:368)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1289)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:73)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:332)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:535)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:530)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:193)
> 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:748)
> Caused by: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:94)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.beforeCompletion(RemotingRemoteTransactionPeer.java:166)
> at org.wildfly.transaction.client.SubordinateXAResource.beforeCompletion(SubordinateXAResource.java:135)
> at org.wildfly.transaction.client.XAOutflowedResources$1.beforeCompletion(XAOutflowedResources.java:70)
> ... 56 more
> Caused by: org.wildfly.security.auth.AuthenticationException: JBREM000308: Authentication failed (no mechanisms left), tried:
> JBOSS-LOCAL-USER: org.wildfly.security.auth.AuthenticationException: JBREM000300: Authentication failed due to I/O error
> at org.jboss.remoting3.ConnectionPeerIdentityContext.doAuthenticate(ConnectionPeerIdentityContext.java:368)
> at org.jboss.remoting3.ConnectionPeerIdentityContext.authenticate(ConnectionPeerIdentityContext.java:174)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:505)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:494)
> at org.xnio.IoFuture$HandlingNotifier.notify(IoFuture.java:208)
> at org.xnio.AbstractIoFuture$NotifierRunnable.run(AbstractIoFuture.java:720)
> at org.xnio.IoUtils$2.execute(IoUtils.java:71)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:693)
> at org.xnio.AbstractIoFuture$CompleteState.withNotifier(AbstractIoFuture.java:132)
> at org.xnio.AbstractIoFuture.addNotifier(AbstractIoFuture.java:570)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:494)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:433)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentity(RemotingRemoteTransactionPeer.java:87)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:92)
> ... 59 more
> 03:59:01,820 WARN [com.arjuna.ats.jta] (default task-7) ARJUNA016129: Could not end XA resource Subordinate XAResource at remote+http://10.16.90.56:8080: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:94)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.end(RemotingRemoteTransactionPeer.java:157)
> at org.wildfly.transaction.client.SubordinateXAResource.end(SubordinateXAResource.java:130)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.doEnd(TransactionImple.java:1089)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.endAssociation(TransactionImple.java:1060)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.endAssociation(XAResourceRecord.java:1287)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:313)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3023)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3002)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1674)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1615)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1289)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:73)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:332)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:535)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:530)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:193)
> 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:748)
> Caused by: org.wildfly.security.auth.AuthenticationException: JBREM000308: Authentication failed (no mechanisms left), tried:
> JBOSS-LOCAL-USER: org.wildfly.security.auth.AuthenticationException: JBREM000300: Authentication failed due to I/O error
> at org.jboss.remoting3.ConnectionPeerIdentityContext.doAuthenticate(ConnectionPeerIdentityContext.java:368)
> at org.jboss.remoting3.ConnectionPeerIdentityContext.authenticate(ConnectionPeerIdentityContext.java:174)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:505)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:494)
> at org.xnio.IoFuture$HandlingNotifier.notify(IoFuture.java:208)
> at org.xnio.AbstractIoFuture$NotifierRunnable.run(AbstractIoFuture.java:720)
> at org.xnio.IoUtils$2.execute(IoUtils.java:71)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:693)
> at org.xnio.AbstractIoFuture$CompleteState.withNotifier(AbstractIoFuture.java:132)
> at org.xnio.AbstractIoFuture.addNotifier(AbstractIoFuture.java:570)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:494)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:433)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentity(RemotingRemoteTransactionPeer.java:87)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:92)
> ... 61 more
> 03:59:01,829 WARN [com.arjuna.ats.jta] (default task-7) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff0a105a36:-2ab20799:5a2f9a2b:f, node_name=1, branch_uid=0:ffff0a105a36:-2ab20799:5a2f9a2b:19, subordinatenodename=null, eis_name=unknown eis name > (Subordinate XAResource at remote+http://10.16.90.56:8080) failed with exception code XAException.XAER_RMFAIL: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:94)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.rollback(RemotingRemoteTransactionPeer.java:148)
> at org.wildfly.transaction.client.SubordinateXAResource.rollback(SubordinateXAResource.java:147)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:330)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3023)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3002)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1674)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1615)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1289)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:73)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:332)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:535)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:530)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:193)
> 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:748)
> Caused by: org.wildfly.security.auth.AuthenticationException: JBREM000308: Authentication failed (no mechanisms left), tried:
> JBOSS-LOCAL-USER: org.wildfly.security.auth.AuthenticationException: JBREM000300: Authentication failed due to I/O error
> at org.jboss.remoting3.ConnectionPeerIdentityContext.doAuthenticate(ConnectionPeerIdentityContext.java:368)
> at org.jboss.remoting3.ConnectionPeerIdentityContext.authenticate(ConnectionPeerIdentityContext.java:174)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:505)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:494)
> at org.xnio.IoFuture$HandlingNotifier.notify(IoFuture.java:208)
> at org.xnio.AbstractIoFuture$NotifierRunnable.run(AbstractIoFuture.java:720)
> at org.xnio.IoUtils$2.execute(IoUtils.java:71)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:693)
> at org.xnio.AbstractIoFuture$CompleteState.withNotifier(AbstractIoFuture.java:132)
> at org.xnio.AbstractIoFuture.addNotifier(AbstractIoFuture.java:570)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:494)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:433)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentity(RemotingRemoteTransactionPeer.java:87)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:92)
> ... 58 more
> 03:59:01,833 WARN [com.arjuna.ats.arjuna] (default task-7) ARJUNA012091: Top-level abort of action 0:ffff0a105a36:-2ab20799:5a2f9a2b:f received TwoPhaseOutcome.FINISH_ERROR from com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 03:59:01,838 ERROR [org.jboss.as.ejb3.invocation] (default task-7) WFLYEJB0034: EJB Invocation failed on component Intermediate for method public abstract java.lang.String example.ejb.WhoAmIBeanRemote.whoAmI(): javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:138)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:118)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:332)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:535)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:530)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:193)
> 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:748)
> Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1301)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:73)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92)
> ... 43 more
> Caused by: org.wildfly.transaction.client.SynchronizationException: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client.XAOutflowedResources$1.beforeCompletion(XAOutflowedResources.java:83)
> at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:209)
> at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:220)
> at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:265)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:368)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1289)
> ... 48 more
> Caused by: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:94)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.beforeCompletion(RemotingRemoteTransactionPeer.java:166)
> at org.wildfly.transaction.client.SubordinateXAResource.beforeCompletion(SubordinateXAResource.java:135)
> at org.wildfly.transaction.client.XAOutflowedResources$1.beforeCompletion(XAOutflowedResources.java:70)
> ... 56 more
> Caused by: org.wildfly.security.auth.AuthenticationException: JBREM000308: Authentication failed (no mechanisms left), tried:
> JBOSS-LOCAL-USER: org.wildfly.security.auth.AuthenticationException: JBREM000300: Authentication failed due to I/O error
> at org.jboss.remoting3.ConnectionPeerIdentityContext.doAuthenticate(ConnectionPeerIdentityContext.java:368)
> at org.jboss.remoting3.ConnectionPeerIdentityContext.authenticate(ConnectionPeerIdentityContext.java:174)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:505)
> at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:494)
> at org.xnio.IoFuture$HandlingNotifier.notify(IoFuture.java:208)
> at org.xnio.AbstractIoFuture$NotifierRunnable.run(AbstractIoFuture.java:720)
> at org.xnio.IoUtils$2.execute(IoUtils.java:71)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:693)
> at org.xnio.AbstractIoFuture$CompleteState.withNotifier(AbstractIoFuture.java:132)
> at org.xnio.AbstractIoFuture.addNotifier(AbstractIoFuture.java:570)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:494)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:433)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentity(RemotingRemoteTransactionPeer.java:87)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:92)
> ... 59 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months