[Spread-users] Re: Question about unexpected spread behaviour

[Yair Amir]

Hi,

I'll add that Spread provides detailed information in the membership
messages. If you have real group members (as opposed to the printout
of the daemon) and you are careful to analyze the membership events,
the who-came-with-whom components included in them, and the transitional signals,
it will give you the complete picture.

Cheers,

	:) Yair.

John Schultz wrote:
> This behavior can happen.  The token is being lost in your network for 
> some reason.  This causes the 2nd daemon to try and form its own 
> membership, which it succeeds in doing.  The 1st daemon has not yet 
> finished forming its own membership when it gets probed or it probes the 
> other daemon and they rejoin together.
> 
> The very fact that the first daemon had to install another membership 
> indicates that the second daemon parititoned away and then came back to 
> it (quickly).
> 
> Cheers!
> 
> ---
> John Schultz
> Spread Concepts
> Phn: 443 838 2200
> 
> On Thu, 23 Aug 2007, Uma Chingunde wrote:
> 
>> I am sorry about the spam if this email has been seen multiple times.
>> Resending without the log files.
>>
>> On 8/22/07, Uma Chingunde <umac at jhu.edu> wrote:
>>>
>>> Hi,
>>>
>>> I have a Spread configuration between 2 hosts and I am seeing some weird
>>> behavior between them.
>>> Since the network does not support broadcast I have configured both 
>>> hosts
>>> as separate sites.
>>>
>>> My spread.conf looks like this:
>>> --------
>>> Spread_Segment  x.x.x.255:4899 {
>>>
>>>         uma-vm-1                x.x.x.105
>>> }
>>> Spread_Segment  x.x.x.255:4899 {
>>>
>>>         uma-vm-2                x.x.x.106
>>> }
>>> ---------------------
>>>
>>> I have a test application that communicates using spread.
>>> However at certain intervals the second daemon seems to partition 
>>> away and
>>> then re-merge when no network change has occurred.
>>> I initially thought that the application was sending a wrong message to
>>> spread that was causing the problem. However it doesn't seem to be 
>>> the case.
>>>
>>>
>>> The first daemon's log file (spread1.log) shows both daemons as always
>>> being in the same partition.
>>> The log files for the partitioned daemon (spread2.log) shows the 
>>> segments
>>> occasionally in different partitions.
>>>
>>> The relevant snippets are below and the log files are attached.
>>> Does anyone have an idea about why I am seeing such behavior?
>>> I can't figure out why one daemon would see a network partition
>>> differently from the other, if such a partition was occurring which I am
>>> pretty sure in this case is not.
>>> Is there a configuration issue that I am missing somewhere?
>>>
>>> Any help would be appreciated.
>>> Thanks,
>>> Uma
>>>
>>> Log file snippet for first daemon
>>> ------------------------------------------
>>> Conf_load_conf_file: My name: uma-vm-1, id: x.x.x.105, port: 4899
>>> Membership id is ( 168918633, 1187811520)
>>> --------------------
>>> Configuration at uma-vm-1 is:
>>> Num Segments 2
>>>     1    x.x.x.255     4899
>>>         uma-vm-1                x.x.x.105
>>>     1    x.x.x.255     4899
>>>         uma-vm-2                x.x.x.106
>>> ====================
>>> Membership id is ( 168918633, 1187811620)
>>> --------------------
>>> Configuration at uma-vm-1 is:
>>> Num Segments 2
>>>     1    x.x.x.255     4899
>>>         uma-vm-1                x.x.x.105
>>>     1    x.x.x.255     4899
>>>         uma-vm-2                x.x.x.106
>>> ====================
>>> Membership id is ( 168918633, 1187811682)
>>> --------------------
>>> Configuration at uma-vm-1 is:
>>> Num Segments 2
>>>     1    x.x.x.255     4899
>>>         uma-vm-1                x.x.x.105
>>>     1    x.x.x.255     4899
>>>         uma-vm-2                x.x.x.106
>>> ====================
>>> Membership id is ( 168918633, 1187811800)
>>> --------------------
>>>
>>> Log file snippet for second daemon
>>> ---------------------------------------
>>> Membership id is ( 168918633, 1187811520)
>>> --------------------
>>> Configuration at uma-vm-2 is:
>>> Num Segments 2
>>>     1    x.x.x.255     4899
>>>         uma-vm-1                x.x.x.105
>>>     1    x.x.x.255      4899
>>>         uma-vm-2                x.x.x.106
>>> ====================
>>> Membership id is ( 168918633, 1187811620)
>>> --------------------
>>> Configuration at uma-vm-2 is:
>>> Num Segments 2
>>>     1    x.x.x.255      4899
>>>         uma-vm-1                x.x.x.105
>>>     1    x.x.x.255     4899
>>>         uma-vm-2                x.x.x.106
>>> ====================
>>> Membership id is ( 168918634, 1187811665)
>>> --------------------
>>> Configuration at uma-vm-2 is:
>>> Num Segments 2
>>>     0    x.x.x.255     4899
>>>     1    x.x.x.255     4899
>>>         uma-vm-2                x.x.x.106
>>> ====================
>>> Membership id is ( 168918633, 1187811682)
>>> --------------------
>>> Configuration at uma-vm-2 is:
>>> Num Segments 2
>>>     1    x.x.x.255     4899
>>>         uma-vm-1                x.x.x.105
>>>     1    x.x.x.255     4899
>>>         uma-vm-2                x.x.x.106
>>> ====================
>>>
>>>
>>
> 
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
> 
>