[jboss-jira] [JBoss JIRA] Commented: (JBAS-7254) Remove ChannelFactory additional_data usage

Tue May 4 16:20:07 EDT 2010

    [ https://jira.jboss.org/jira/browse/JBAS-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12528954#action_12528954 ] 

Brian Stansberry commented on JBAS-7254:
----------------------------------------

Assigned to myself. I've been doing a lot of work on ClusterPartition these days and at the same time we've been discussing the JGroups UUID.get() method as the source for the values passed to Channel.setName(). Since I'm messing with this code, it's easy enough for me to do.

Note that contrary to the description, I'm not going to deprecate verifyNodeIsUnique. JGroups logical addresses resolve the problems JGroups has internally with node reincarnation, but they don't resolve the problems an application has (e.g. no response to RPC from the zombie member.)

> Remove ChannelFactory additional_data usage
> -------------------------------------------
>
>                 Key: JBAS-7254
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7254
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 6.0.0.CR1
>
>
> org.jboss.ha.framework.server.JChannelFactory supports a form of logical addresses by setting additional_data on the channel (see setChannelUniqueId()).  This should be replaced by calling the JGroups 2.8 Channel.setName() method.
> The ClusterPartition.verifyNodeIsUnique() method uses the additional_data to try to ensure that the same node cannot rejoin the group until its previous incarnation has been removed from the view. Confirm that JGroups 2.8 handles this itself, removing the need for the AS to do it. Then make verifyNodeIsUnique a deprecated no-op (if this JIRA is done for AS 5.2) and remove it for AS 6.  Can't just remove the method in 5.2 as it is protected; some subclass somewhere may invoke or override it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira