[jboss-jira] [JBoss JIRA] (JGRP-2411) JGraSS: JGroups as a Service

[ https://issues.jboss.org/browse/JGRP-2411?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2411: --------------------------- Description: 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... was: 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. 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. 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... -- This message was sent by Atlassian Jira (v7.13.8#713008)