[jboss-jira] [JBoss JIRA] (WFLY-4697) EJBCLient access to SFSBs does not play well with clean shutdown

[Richard Achmatowicz (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083478#comment-13083478 ] 

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)