question on tribes member alive time

[Eddie Hsiung <eh...@gmail.com>]

Hi

I'm trying to debug a vendor product which uses Apache Tribes as its cluster
communication implementation.  I've identified that each member of the
cluster derives the "master node" instance using the aliveTime field of all
members of the cluster.  The member with the largest aliveTime is elected to
be the master node.

One thing I notice is that local member aliveTime is only updated when
McastService.getLocalMember() is called while (remote) member aliveTime is
updated constantly (by a separate thread?).

Is this observation correct?  If so, does this mean that using aliveTime to
elect a master node might run into race conditions if it wasn't implemented
carefully?

For example, remote member aliveTime is always more up-to-date than the
local member alive time.  Assuming two members of the cluster started almost
at the same time, It's possible that they always think the other member is
alive longer (if the remote aliveTime is updated before local aliveTime)
and, therefore, think the other member is the master node.

Thanks for any clarification on the subject.


eddie

Re: question on tribes member alive time

[Filip Hanik - Dev Lists <de...@hanik.com>]

On 03/11/2010 01:46 AM, Eddie Hsiung wrote:
> Hi
>
> I'm trying to debug a vendor product which uses Apache Tribes as its cluster
> communication implementation.  I've identified that each member of the
> cluster derives the "master node" instance using the aliveTime field of all
> members of the cluster.  The member with the largest aliveTime is elected to
> be the master node.
>    
I would not recommend using aliveTime as the elector for master node.
The reason for that is cause if the network is busy, then multicast 
packets can be delayed or dropped all together.
So you could end up with masters changing constantly.
Instead, Tribes already defines an absolute ordering algorithm
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/AbsoluteOrder.java?view=log
I would suggest using this for the simplest possible master election

> One thing I notice is that local member aliveTime is only updated when
> McastService.getLocalMember() is called while (remote) member aliveTime is
> updated constantly (by a separate thread?).
>
> Is this observation correct?  If so, does this mean that using aliveTime to
> elect a master node might run into race conditions if it wasn't implemented
> carefully?
>
> For example, remote member aliveTime is always more up-to-date than the
> local member alive time.  Assuming two members of the cluster started almost
> at the same time, It's possible that they always think the other member is
> alive longer (if the remote aliveTime is updated before local aliveTime)
> and, therefore, think the other member is the master node.
>
> Thanks for any clarification on the subject.
>
>
> eddie
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org