]
Ondrej Chaloupka commented on WFLY-12610:
-----------------------------------------
I'm cloning the JBEAP-17611 to track the {{:recover}} call as a WFLY feature request.
Provide a proper :recover management operation for transactions
---------------------------------------------------------------
Key: WFLY-12610
URL:
https://issues.jboss.org/browse/WFLY-12610
Project: WildFly
Issue Type: Enhancement
Components: Transactions
Affects Versions: 18.0.0.Beta1
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
Priority: Major
Based on the operator work at
https://github.com/wildfly/wildfly-operator it seems that
the operations required by the admin to perform recovery are quite complex.
It seems that the customer must to:
1. make sure that tx recovery listener is enabled in the tx subsystem
1.a read the correct port from the socket binding, don't forget to also read the
portOffset and take it into account
2. connect to this tx-recovery-port opened by the server and send a SCAN command
3. read the Pod log with a regexp "ERROR.*Periodic Recovery"
3.a don't forget to timestamp the logs
4. read recursively all tx logs to check that there are no in-doubts tx
Oh and if you want to configure the tx recovery process, please add the correct system
properties om.arjuna.ats.arjuna.common.Recovery*
This creates a lot of complexities for the customer (and the operator code) that should
be encapsulated by the transactions subsystem.
Tthe subsystem should provide a :recover management operation
that deals with connecting with Narayana (no need to open a socket since Narayana is
IN-VM) and perform the scan / logs checking / etc. and return the useful information to
the user (the in-doubt TX)
Likewise, any recovery configuration should be handled by the transactions and not
through System properties.
[1]
https://github.com/wildfly/wildfly-operator/blob/master/pkg/controller/wi...