[Spread-users] Re: Question about unexpected spread behaviour
Uma Chingunde
umac at jhu.edu
Thu Aug 23 18:21:46 EDT 2007
>
> Thanks for the information.
> > I tried a few more things and I think the reason I was seeing the
> > unexpected behaviour could be that the machines were seeing a pretty high
> > load could have led to the token passing taking more time than expected.
> > Could this be the cause of the frequent partitions and then the
> > re-merges?
> > I also saw that the Spread guide recommends running Spread with a higher
> > priority so I'll be trying that to see if it solves the problem.
> >
> > Thanks,
> > Uma
> >
> >
> > On 8/23/07, Yair Amir < yairamir at jhu.edu> wrote:
> > >
> > > 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
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > Spread-users mailing list
> > > Spread-users at lists.spread.org
> > > http://lists.spread.org/mailman/listinfo/spread-users
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.spread.org/pipermail/spread-users/attachments/20070823/73504450/attachment.html
More information about the Spread-users
mailing list