[ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on WFLY-88: --------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com&gt; made a comment on [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746] Hi David, I've checked the current state of the issue (as it's longer time that I've been checking it) and I can say that there is still the problem in the waking up the ejb remote connection when the remote server (remote server which is called from client server - via outbound connection from client server) crashes and then comes up again. Then the client sever (it started the tx) does not know nothing about the remote server is up and that the recovery can be done. This happen just for the distributed JTA transactions. The JTS transactions manage the distributed communication between nodes and the recovery starts without problem. The workaround for the recovery is to call a remote method from the client server to the remote server after the remote server comes back to life. Then the crash recovery will start. The test scenario when this problem occurs look: - transaction is started on the client server - the client server does call via outbound connection to the remote server (tx context is propagated to remote server) - the remote server sends a message to a queue (simulation of some action done during the transaction) - finishing the remote call and the bean method - the transaction started 2PC. The prepare phase is done and the commit phase is started. The remote server crashes at the entry to the commit method - client server is still alive - remote server comes to life - the crash recovery should proceed the commit as all the participant agreed on it I would put here the explanation from Jaikiran: When a connection breaks down between the server and the client, specifically when the client goes down and comes back up again, then the server and the client will not auto communicate with each other. In other words, the server will have no knowledge (in EJB resource sense) that the client has come back up again. That effectively means that the EJB tx recovery process will have no clue of the EJB nodes to communicate with. To deal with that, there should be some communication from the client (which is now up) to the server to reestablish that connection. In a real application, it would be the first invocation from the client to the server. I've checked that the call from the client server to remote one really establishes the connection and recovery starts. B the next call from the client to server could take some time and meanwhile the transaction could be rollbacked because of the timeout. What do you think about this? I think that current behavior is not correct. We agreed on it with Jaikiran before as well but he haven't got a time to fix it (https://bugzilla.redhat.com/show_bug.cgi?id=952746#c15). Thanks Ondra -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira