[
https://issues.redhat.com/browse/JGRP-1424?page=com.atlassian.jira.plugin...
]
Dan Berindei commented on JGRP-1424:
------------------------------------
One scenario where multiple transports would help is with container images: if we could
include both transports in the configuration and select one of them at runtime, then fewer
users would need to extend the image with a custom configuration. OTOH the Infinispan
configuration already allows a user to include multiple JGroups stacks and select one of
them at runtime, so the only gain would be the simplification of our default stacks.
WRT automatically detecting when IP multicasting is available, I agree it's hard to
get right. I have created ISPN-12235 to perform a multicast test on startup, but I'm
not sure exactly how it's going to work.
I also agree WRT using multiple bind addresses: it's really easy to bind to 0.0.0.0
and block connections on unwanted IPs from the firewall, and users who need more complex
rules are probably better off configuring them at the OS level.
TP: use of multiple transports
------------------------------
Key: JGRP-1424
URL:
https://issues.redhat.com/browse/JGRP-1424
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Major
Fix For: 5.1
Refactor TP so that the socket sending and receiving is done in a separate class (UDP,
TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP,
e.g. UDP and TCP.
The UDP transport could then be used for cluster wide messages (null destination) and the
TCP transport could be used for unicast messages (non-null destination).
Or this could be overridden by a message flag on a per-message basis !
We could even attach multiple transports of the same type, e.g. one per physical network
(10.x.x.x and 192.168.x.x), and do round-robin sending over them.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)