[
https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin....
]
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)