[jboss-jira] [JBoss JIRA] (WFLY-8417) Create DistributedWorkManager implementation based on WF clustering API

Paul Ferraro (JIRA) issues at jboss.org
Mon Oct 9 10:50:00 EDT 2017


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

Paul Ferraro updated WFLY-8417:
-------------------------------
    Description: 
The upgrade to JGroups 4.0 will break the JGroups DistributedWorkManager implementation in IronJacamar (which uses JGroups 3.x).  JGroups is only used to broadcast/receive commands to the cluster.  This can be easily implemented using the WildFly clustering API.  Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage.

Additionally, the JGroupsTransport in ironjacamar has some issues:
* Performs blocking operations on view change
* Does a lot of unnecessary serialization of Address
* Doesn't leverage multicasts

  was:The upgrade to JGroups 4.0 will break the JGroups DistributedWorkManager implementation in IronJacamar (which uses JGroups 3.x).  JGroups is only used to broadcast/receive commands to the cluster.  This can be easily implemented using the WildFly clustering API.  Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage.



> Create DistributedWorkManager implementation based on WF clustering API
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8417
>                 URL: https://issues.jboss.org/browse/WFLY-8417
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering, JCA
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 12.0.0.Alpha1
>
>
> The upgrade to JGroups 4.0 will break the JGroups DistributedWorkManager implementation in IronJacamar (which uses JGroups 3.x).  JGroups is only used to broadcast/receive commands to the cluster.  This can be easily implemented using the WildFly clustering API.  Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage.
> Additionally, the JGroupsTransport in ironjacamar has some issues:
> * Performs blocking operations on view change
> * Does a lot of unnecessary serialization of Address
> * Doesn't leverage multicasts



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


More information about the jboss-jira mailing list