[jboss-jira] [JBoss JIRA] (JGRP-1844) Remove shared transport

[Rich DiCroce (JIRA)]

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

Rich DiCroce commented on JGRP-1844:
------------------------------------

The situation I am in is that two applications share some Infinispan caches, but also have some of their own independent caches. The short explanation is that I have to create three separate cache managers (one shared, one for each application), each of which requires its own JGroups channel. Infinispan assumes that every node in the view is participating in the cache manager, which isn't true for the app-specific cache managers when using a fork channel.

That is arguably more of an Infinispan problem, and I'm going to file some issues in the Infinispan JIRA for those, but I don't know if or when those issues will ever be resolved. Shared transport is a useful workaround in the meantime. I also have my own fork channel that is used by only one of the two applications, and I need to be able to determine a coordinator within that subset of members. JGroups currently doesn't do anything to help with that, so instead of forking the channel that is shared by both applications, I'm forking the app-specific channel.

It would be nice if JGroups did something for applications using fork channels, so the application can easily determine which cluster members are participating in the fork. Alternatively, is it possible to put the FORK protocol lower in the stack, below the GMS protocol? Then forks would have their own separate views. I haven't tried that but I doubt it would work based on what I've read.

> Remove shared transport
> -----------------------
>
>                 Key: JGRP-1844
>                 URL: https://issues.jboss.org/browse/JGRP-1844
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 3.5
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2].
> Here's my reasoning:
> * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller
> * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared
> * TUNNEL doesn't work with shared transports (throws an exception)
> * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used
> * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste
> Thoughts ? My +100 for removing shared transports in 4.0...
> [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport
> [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)