JGraSS: JGroups as a Service ---------------------------- Key: JGRP-2411 URL: https://issues.jboss.org/browse/JGRP-2411 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Priority: Major Fix For: 5.2 Provide a separate server implementation of Channel (_server service_) which runs as a separate process, plus a client stub ({{RemoteChannel}}, implementing {{Channel}}) which communicates with the service. The communication is across pipes/sockets/shared memory (TBD) and assumes servers and clients are on the same host. Most method calls of {{Channel}} need to be supported. h3. Advantages h4. Fast replacement The server process could be replaced on the fly with a different server process, e.g. using a different configuration. If compiled down to a native image (using GraalVM), this would take only a few milliseconds. This could move the config permutations (UDP/TCP/NIO/PING/TCPPING/KUBE_PING/DNS_PING etc) from Infinispan into the separate server process. h4. Rolling upgrades We could have a Channel implementation, which communicates with multiple remote JGroups servers, sending messages to both and receiving messages from both servers. One server could be running 3.6. Later, a 4.x server could be added and when all members have a dual-channel, the 3.6 channels could be shut down, effectively performing a rolling upgrade of JGroups from a version to a different version. h3. Disadvantages This would be much slower, because of the serialization overhead. Perhaps shared memory could be used on the same host to avoid that...