[
https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1844:
--------------------------------
I'll take a look at your explanation when I tackle this issue, but I can already tell
you if this is an Infinispan issue, then it won't prevent me from removing the shared
transport. In the worst casem you could always create full channels (with non-shared
transports).
No, FORK cannot be placed below GMS, or other protocols such as NAKACK2 or UNICAST3. It is
really meant to be located towards the top of the stack.
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)