[jboss-jira] [JBoss JIRA] (WFLY-5188) DistributedWorkManager needs to handle unknown fork responses.

[Paul Ferraro (JIRA)]

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

Paul Ferraro updated WFLY-5188:
-------------------------------
    Description: 
The JGroupsTransport employed by the DistributedWorkManager uses synchronous multicasting via the RpcDispatcher.  Since the JCA default configuration was modified to use fork channels, we need to ensure that it handles an exception case specific for fork channels, i.e. the case where a message is received by a node on which no such DWM exists.

As I see it, there are 2 ways we can fix this:
# Configure the RpcDispatcher with a custom response marshaller capable of recognizing unknown fork responses
# Implement a transport that leverages CommandDispatcher, which already handles this exception case.

#1 is the easiest.  The only hiccup is that the RpcDispatcher field in JGroupsTransport is private, which requires reflection to access from a subclass.

#2 is probably the ideal long term solution.  The DistributedWorkManager already employs a command pattern, so using CommandDispatcher is a natural fit.  Using the CommandDispatcher will also simplifies marshalling/unmarshalling of the transport parameters.  Additionally, using the public clustering API allows us to remove the direct dependency on org.jgroups module from the connector subsystems.  The only hiccup here is that in order to optimize the marshalling of the command objects, requires the use of the marshalling API introduced as part of WFLY-5091, which, at the time of this writing, has not yet been merged into WF master.

Given the above, I suggest a 2 phase solution, where we implement #1 for now, and #2 when the missing pieces are in place.

  was:
The JGroupsTransport employed by the DistributedWorkManager uses synchronous multicasting via the RpcDispatcher.  Since the JCA default configuration was modified to use fork channels, we need to ensure that it handles an exception case specific for fork channels, i.e. the case where a message is received by a node on which no such DWM exists.

As I see it, there are 2 ways we can fix this:
# Configure the RpcDispatcher with a custom response marshaller capable of recognizing unknown fork responses
# Implement a transport that leverages CommandDispatcher, which already handles this exception case.

#1 is the easiest.  The only hiccup is that the RpcDispatcher field in JGroupsTransport is private, which requires reflection to access from a subclass.

#2 is probably the ideal long term solution.  The DistributedWorkManager already employs a command pattern, so using CommandDispatcher is a natural fit.  Additionally, this allows us to remove the direct dependency on org.jgroups module from the connector subsystems.  The only hiccup here is that in order to optimize the marshalling of the command objects, requires the use of the marshalling API introduced as part of WFLY-5091, which, at the time of this writing, has not yet been merged into WF master.

Given the above, I suggest a 2 phase solution, where we implement #1 for now, and #2 when the missing pieces are in place.



> DistributedWorkManager needs to handle unknown fork responses.
> --------------------------------------------------------------
>
>                 Key: WFLY-5188
>                 URL: https://issues.jboss.org/browse/WFLY-5188
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JCA
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The JGroupsTransport employed by the DistributedWorkManager uses synchronous multicasting via the RpcDispatcher.  Since the JCA default configuration was modified to use fork channels, we need to ensure that it handles an exception case specific for fork channels, i.e. the case where a message is received by a node on which no such DWM exists.
> As I see it, there are 2 ways we can fix this:
> # Configure the RpcDispatcher with a custom response marshaller capable of recognizing unknown fork responses
> # Implement a transport that leverages CommandDispatcher, which already handles this exception case.
> #1 is the easiest.  The only hiccup is that the RpcDispatcher field in JGroupsTransport is private, which requires reflection to access from a subclass.
> #2 is probably the ideal long term solution.  The DistributedWorkManager already employs a command pattern, so using CommandDispatcher is a natural fit.  Using the CommandDispatcher will also simplifies marshalling/unmarshalling of the transport parameters.  Additionally, using the public clustering API allows us to remove the direct dependency on org.jgroups module from the connector subsystems.  The only hiccup here is that in order to optimize the marshalling of the command objects, requires the use of the marshalling API introduced as part of WFLY-5091, which, at the time of this writing, has not yet been merged into WF master.
> Given the above, I suggest a 2 phase solution, where we implement #1 for now, and #2 when the missing pieces are in place.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)