[jboss-jira] [JBoss JIRA] (WFLY-4697) EJBCLient access to SFSBs does not play well with clean shutdown
[
https://issues.jboss.org/browse/WFLY-4697?page=com.atlassian.jira.plugin....
]
Richard Achmatowicz commented on WFLY-4697:
-------------------------------------------
I don't believe that the module unavailability messages on their own will trigger the
client to disconnect. They just inform the client that, on the end of that particular
connection, there are no modules available. A consequence of this is that the connection
will not receive further invocations by the client (or at least, not until a later module
available message is sent from the server back to the client).
The connection is closed from the client side generally only when the client specifically
un-registers the EJBReceiver which makes use of the channel. Having a connection to a node
which has no deployments is currently possible.
I don't really understand what you mean when you say that graceful shutdown will
timeout. My understanding is this:
* when the suspend phase starts, aside from other stuff happening with the ejb and web
interceptors to allow active invocations time to complete, because each open channel is
registered as a ServerActivity, it will cause the module unavailable messages to be sent
to the client along open channels and these operations will not block
* once the suspend phase completes and shutdown starts, any open Remoting channels are
going to get closed as the Remoting endpoint is stopped, which is what happens at the
moment
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)