[infinispan-issues] [JBoss JIRA] (ISPN-3697) Improved lifecycle control of JGroupsChannelLookup

[Dan Berindei (JIRA)]

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

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