[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=13113551#comment-13113551 ] 

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

I have a project with a (probably rare) use case that requires participation in multiple independent channels. Shared transport is useful for reducing resource usage in this case. Fork channels are not an acceptable substitute because each channel has different participants, and fork channels have the limitation that the fork's view is always the same as the main channel's view.

So if shared transport is to be deprecated and removed, some accommodation should be made to deal with the above. Perhaps by changing fork channels such that their view is a subset of the main view. Fork allows "asymmetric" clusters where fork channels may be present on some members but not others, but that is currently not reflected in the fork's view. That means there's no way to easily determine which members are actually participating in the fork. This feels very strange to me, especially since fork channels do have their own addresses. It seems like it should be the other way around: rather than inheriting membership but not address, the fork channel should inherit address but not membership.

> 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)