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

[Bela Ban (Jira)]

     [ https://issues.jboss.org/browse/JGRP-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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.

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...

  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.




> 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: 4.1.9
>
>
> 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)