]
Ondrej Chaloupka closed WFWIP-222.
----------------------------------
Resolution: Rejected
The behaviour is expected and the transaction resolution is in hands of different
component than the recovery. The transactions on the server were started but was not moved
to the {{PREPARED}} state. They are in-flight stored only in memory. It's
responsibility of the transaction reaper to finish them. It really does so but the reaper
is not dependent on the recovery processing. The reaper roll-backs the transactions after
transaction timeout is over. If the reaper is not capable to do so for the remote
resources (e.g. WildFly goes down meanwhile) then the database/jms/... will roll-back the
transaction after the timeout on its own (aka. prepare was not called -> no promise
from the remote resource on the processing was done -> transaction timeouts after the
timeout is over)
when client is scaled down with in-doubt transactions, tx
participants on server are resolved with delay
--------------------------------------------------------------------------------------------------------
Key: WFWIP-222
URL:
https://issues.jboss.org/browse/WFWIP-222
Project: WildFly WIP
Issue Type: Bug
Reporter: Martin Simka
Assignee: Ondrej Chaloupka
Priority: Blocker
Attachments: tx-server.log
this follows up on WFWIP-206
While testing tx recovery in OpenShift I see that when client is scaled down with
in-doubt transactions, tx participants on server are resolved with delay.
Scenario:
*ejb client* (app tx-client, pod tx-client-0):
* EJB business method
** lookup remote EJB
** enlist XA resource 1 to transaction
** enlist XA resource 2 to transaction
** call remote EJB
*ejb server* (app tx-server, pod tx-server-0):
* EJB business method
** enlist XA resource 1 to transaction
** enlist XA resource 2 to transaction
*testTxStatelessClientSecondPrepareJvmHalt*
JVM on client crashes in PREPARE phase of second XA resource on client. Then openshift
restarts pod, but pod is immediately scaled down. Transactions on client pod are
rollbacked during scale down, but on server they are rollbacked some time later. I'm
not sure if it is periodic recovery or tx timeout.
server log with {{com.arjuna}} trace attached.
Feel free to reject if it is expected behavior.