[
https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1844:
--------------------------------
Why can't you create multiple fork channels ? Each fork channel is independent from
the others, while they have the same view and address.
The reason for sharing the views is that I made a big mistake a couple of years ago by
introducing "service views" which complicated things and were never quite
correct compared to JGroups views (google for jgroups "service view").
Can you clarify your use case above with an example ? I'm pretty dead set on removing
the shared transport, unless there's a convincing use case / requirement against
it...
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)