[
https://jira.jboss.org/jira/browse/JBAS-7253?page=com.atlassian.jira.plug...
]
Vladimir Blagojevic commented on JBAS-7253:
-------------------------------------------
Brian,
Conversion is not as easy as anticipated. The problem is that getOriginalJGAddress,
although not exported in ClusterNode API is used internally in
ClusterPartirion#callAsyncMethodOnNode and ClusterPartition#callMethodOnNode. These two
methods invoke calls on JGroups dispatcher, which in turns now needs Address instead of
IpAddress. Therefore, we need to keep Address in ClusterNodeImpl as well as IpAddress.
It seems that a better solution would be to have a ClusterNodeImpl that accepts regular
Address and IpAddressResolver interface that can be used to translate the Address into
IpAddress. Or we pass both Address and IpAddress directly.
Let me know.
Don't assume Address object available from Channel is an
IpAddress
------------------------------------------------------------------
Key: JBAS-7253
URL:
https://jira.jboss.org/jira/browse/JBAS-7253
Project: JBoss Application Server
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assignee: Vladimir Blagojevic
Fix For: JBossAS-6.0.0.M3
In JGroups 2.8, the Address type will typically not be IpAddress, so simply casting the
Address to IpAddress and passing it to the ClusterNodeImpl ctor is invalid. The calling
node needs to find the underlying InetAddress/port from the JGroups channel and pass the
values to the constructor. Instead something like this needs to be done to get the
IpAddress:
IpAddress physicalAddress = (IpAddress) channel.downcall(new
Event(Event.GET_PHYSICAL_ADDRESS, a));
The ClusterNodeImpl.getOriginalJGAddress() method can be removed. It is not part of the
ClusterNode interface, which is the API for this class.
It is tempting to remove the ClusterNodeImpl.originalJGAddress field and change the
ClusterNodeImpl ctor to take InetAddress + port instead of IpAddress. However, this
changes the serialization format of the class. We'd need to have a jboss-dev list
discussion before doing that.
Eclipse reports 3 places where the ClusterNodeImpl ctor is called; 2 in ClusterPartition
and one in RspFilterAdapter. RspFilterAdapter is called every time an RPC response comes
in, so calling channel.downcall each time is clearly not reasonable. I think the thing to
do is to find/cache in ClusterPartition the IpAddresses each time a new view comes in. In
a ConcurrentMap<Address, IpAddress>. Then add a new IpAddressResolver interface that
ClusterPartition implements by doing a map lookup or a channel.downcall is necessary.
Probably better to use a separate class for this map/channel.downcall functionality.
ClusterPartition will pass a ref to IpAddressResolver to any RspFilterAdapter it creates.
--
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