[infinispan-issues] [JBoss JIRA] (ISPN-3697) Improved lifecycle control of JGroupsChannelLookup
[
https://issues.jboss.org/browse/ISPN-3697?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-3697:
------------------------------------
I think it's too late for SPI changes in 6.0 now.
If creating a new Channel on restart is not an option, I guess your best option is indeed
to return a Channel wrapper that disables close() from getJGroupsChannel(). But I
don't think you need another method to do the actual closing, your JGroups service
should still have access to the original Channel.
For the future, I guess I would prefer to see Wildfly take over the management of the
channel completely. In principle, a new node joining the JGroups view should not influence
the running Infinispan caches in any way until it also starts a cache - although ATM there
may be some problems with broadcast sync RPCs - e.g. writes in replicated+sync caches and
ClusterTopologyManager's recovery process (when the coordinator leaves the cluster).
Improved lifecycle control of JGroupsChannelLookup
--------------------------------------------------
Key: ISPN-3697
URL: https://issues.jboss.org/browse/ISPN-3697
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Affects Versions: 6.0.0.CR1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 6.0.0.Final
Currently, a JGroupsChannelLookup can indicate whether the JGroupsTransport should
connect the provided channel and disconnect/close the provided channel.
In the case of Wildfly, we'd like to distinguish between disconnect and close. We
have a service that provided the channel, but we allow the JGroupsTransport to manage the
lifecycle. This leads to conditions where infinispan's cache manager can restart, but
the jgroups channel service does not, e.g.
https://issues.jboss.org/browse/WFLY-2458
To fix this, I need to introduce hacks into the channel returned by the channel service,
such that Channel.close() is a no-op, and introduce a separate method invisible to
Infinispan to perform the actual close().
So what I propose is the following:
boolean shouldConnect(); // Notice that I renamed this, because there is no such
distinction between "start" and "connect".
boolean shouldDisconnect();
boolean shouldClose();
--
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