[
https://issues.jboss.org/browse/WFLY-4697?page=com.atlassian.jira.plugin....
]
Richard Achmatowicz commented on WFLY-4697:
-------------------------------------------
In the case of a managed transaction context. there are two problems when an invocation
arrives at a server and comes back to the client with a NoSuchEJBException:
(i) the invocation will be automatically retried by the EJBClient retry mechanism, which
should not happen as there is no replicated transaction state on the other nodes in the
cluster
(ii) the retry will not take into account the fact that the TransactionInterceptor on the
client side has already set up an XAResource on the client side to represent the server
receiving the invocation, and that XAResource will ultimately fail when it tries to commit
or rollback as it points to the wrong node. In fact, because the NoSuchEJBException was
raised, no work was done on the server side, as we did not reach the EJB interceptors.
We need to disable retry of invocations in a managed context, because of point (i).
Due to the way the EJBClient invocation mechanism works, as well as the way transactions
are associated to invocation threads, this is tricky. It is possible to assign a
RETRY_DISABLED_KEY attachment to the invocation context when we know that the invocation
is in an EJBCLientmanagedTransactionContext, so that when we are processing a response in
the NoSuchEJBExceptionResponseHandler, we can avoid doing a retry at the message
send/receive level. Additionally, the TransactionInterceptor processing of the result is
only called when we call EJBClientInvocationContext.getResult(). It would be possible at
this point to somehow clean up the XAResource, perhaps without triggering a rollback?
EJBCLient access to SFSBs does not play well with clean shutdown
----------------------------------------------------------------
Key: WFLY-4697
URL:
https://issues.jboss.org/browse/WFLY-4697
Project: WildFly
Issue Type: Bug
Components: Clustering, EJB, Remoting
Affects Versions: 10.0.0.Alpha1
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
The clean shutdown mechanism allows EJB and web applications to make use of shutdown
interceptors to allow the application server to refuse requests when a server is in the
process of shutting down. These interceptors are tied to the processing of EJB invocations
and web requests.
In the case of EJBCLient invocations, they arrive at the remoting connector, and undergo
some preliminary processing before being sent to the EJB interface in question. When a
server is shutting down, EJBCLient invocations can arrive at the RemoteConnector and start
processing, even when the EJB interface has been locked down, so to speak.
I am seeing various types of exceptions arising from this preliminary processing (e.g.
NPE on DeploymentRepository lookups) and these get returned to the client as exceptions on
the SFSB invocation, before even reaching the SFSB interceptors.
If the EJBCLient is running in a managed transaction context, these returned exceptions
will case the SFSB to be discarded (as the SFSB invocation is considered failed with the
exception returned) and the transaction will attempt to rollback. If the rollback
processing fails (because the original node in the transaction is down the bean gets
removed anyway. The SFSB session state is lost, even if there is another node in the
cluster which can support the invocation.
In short, it looks as though the clean shutdown mechanism needs to be used to also lock
down the processing of EJBCLient invocations in some way.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)