[
https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi...
]
Richard Achmatowicz edited comment on WFLY-13871 at 9/17/20 9:00 AM:
---------------------------------------------------------------------
Ok, i'll have look. Thanks for the feedback. Looks like the initial module update
when the client connects is causing this to happen.
UPDATE: I can see that when a client first connects, the two listeners (cluster topology,
module update) are registered and, upon registration, the module update listener sends out
the current list of started modules. This needs to be adjusted to check if the server is
in a suspended state and if so, not send out any modules.
was (Author: rachmato):
Ok, i'll have look. Thanks for the feedback. Looks like the initial module update
when the client connects is causing this to happen.
Re-implement correct suspend/resume behaviour for EJB client
------------------------------------------------------------
Key: WFLY-13871
URL:
https://issues.redhat.com/browse/WFLY-13871
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 21.0.0.Beta1
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Priority: Major
Fix For: 21.0.0.Beta1
When a server is suspended, in order to avoid receipt of invocations which will never be
correctly processed, all connected clients should be notified that all modules on that
server are now unavailable; when the server is resumed, all connected clients should be
notified that all modules on that server are now again available so that the server may
again take part in processing invocations.
This behaviour was present in versions of EAP before EAP 7.1 but was not ported over to
the new EJB client server-side classes which were substantially refactored.
This issue will re-instante that behaviour. The two cases of standalone and clustered
deployments should be considered.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)