[JBoss JIRA] (WFLY-13283) WFLYTX0001: Unable to roll back active transaction exception thrown from RTS inbound bridge
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/WFLY-13283?page=com.atlassian.jira.plugi... ]
Ondrej Chaloupka updated WFLY-13283:
------------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/13140)
> WFLYTX0001: Unable to roll back active transaction exception thrown from RTS inbound bridge
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-13283
> URL: https://issues.redhat.com/browse/WFLY-13283
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 19.0.0.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> This is an integration problem of REST-AT transaction inbound bridge with WFTC client.
> It's in the same way as there was for XTS txnbridge https://issues.redhat.com/browse/WFLY-9455
> The trouble is that REST-AT bridge implementation works with Narayana transaction manager. All the calls which go to the {{javax.transaction.TransactionManager}} is integrated to Narayana transaction manager backed by {{AtomicActions}} etc.
> But WildFly is fully integrated with WFTC TransactionManager as a wrapper over the Narayana one.
> The inbound bridge manages merging the REST-AT context with JTA context. On incoming REST call the InboundBridge is started and resume a transaction:
> https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/m...
> It's implemented by `ContainerRequestFilter` which is invoked on incoming call before the method is executed:
> https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/m...
> After execution is needed the transaction would be suspended again. In current time it happens for Narayana transaction but not for the WFTC transaction
> Narayana `ContainerResponseFilter` handling:
> * https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/m...
> * https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/m...
> (btw. the same is about handling of JAX-WS XTS txnbridge: https://github.com/jbosstm/narayana/blob/5.10.4.Final/txbridge/src/main/j...)
> Now the issue is that WFLY WFTC Transaction is not suspended on the outbound. It means the EJB still think there is an active transaction. But it's only the WFTC wrapper which wraps an empty Narayana transaction. All the real business work was done, the real transaction was suspended.
> When the call leaves the EJB there is a action which ensures no transaction leaves the EJB method (https://github.com/wildfly/wildfly/blob/19.0.0.Final/transactions/src/mai...). When there is some active context it's rolled-back. So WFTC Transaction rollback is called but as the WFTC holds an empty wrapper the rollback finishes with exception server log message[1].
> [1]
> {quote}
> ERROR [org.jboss.as.txn] (default task-1) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0
> ERROR [org.jboss.as.txn] (default task-1) WFLYTX0001: Unable to roll back active transaction: javax.transaction.SystemException: WFTXN0032: Rollback not allowed on imported transaction
> at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:105)
> at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83)
> at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:137)
> at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:67)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1543)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> 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:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFCORE-5092) Windows Service cannot be stopped when using custom JAVA_HOME path
by Lukas Vydra (Jira)
[ https://issues.redhat.com/browse/WFCORE-5092?page=com.atlassian.jira.plug... ]
Lukas Vydra commented on WFCORE-5092:
-------------------------------------
Hi [~wraaflaub], I suppose that passing JAVA_HOME variable via /environment parameter is a supported solution.
In the case of NO_PAUSE env variable, I don't think that calling jboss-cli.bat from service.bat with pausing makes any sense. So I have added NOPAUSE=Y to StopParams in PR.
> Windows Service cannot be stopped when using custom JAVA_HOME path
> ------------------------------------------------------------------
>
> Key: WFCORE-5092
> URL: https://issues.redhat.com/browse/WFCORE-5092
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 11.0.0.Final
> Reporter: Walter Raaflaub
> Assignee: Lukas Vydra
> Priority: Major
>
> I am running keycloak in a Wildfly container as a Windows service on Windows Server 2019. The service starts up and works correctly; but it hangs when I try to stop it.
> There is no global JAVA_HOME environment variable defined on the server; I'm using a custom JAVA_HOME path that I have configured in standalone.conf.bat.
> While stopping, the service issues the following warning in stdout.log:
> {noformat}
> JAVA_HOME is not set. Unexpected results may occur.
> Set JAVA_HOME to the directory of your local JDK to avoid this message.
> Drcken Sie eine beliebige Taste . . .
> {noformat}
> (Drücken Sie eine beliebige Taste . . . = German vor "Press any key ...")
> It seems that when stopping the service, the JAVA_HOME setting is not correctly passed to the jboss-cli.bat script. The script seems to be waiting for user input, which is akward in a Windows service. That means that also the NOPAUSE setting is not passed correctly to the jboss-cli.bat script.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years