[Spread-users] Bug in spread - message counter

[John Lane Schultz]

Clients on the one daemon that you partition away will miss whatever
traffic is sent by clients on the other daemons during the partition.
Clients on the daemons that stay together will miss whatever traffic
is sent by clients on the daemon that is partitioned away during the
partition.

If you don't want your applications to miss any traffic during the
partition, then simply don't make any client connections to the one
daemon that you intend to partition in and out of the system.  In
other words, reserve one daemon solely for the purpose of
partitioning it into and out of the system and don't let clients
connect to it.  If you do this, then your clients will not miss any
traffic due to the artificial partition you create.

In fact, if you do it this way, then the applications will not even realize
that a partition ever even occurred as membership messages will not
be generated in any of the client groups because their memberships
are unaffected by the daemon level membership change.  The only thing
the applications may notice are short pauses in message
injection+delivery as the daemons handle the connectivity changes.

Cheers!
John

---
John Lane Schultz
Spread Concepts LLC
Phn: 443 838 2200 
Fax: 301 560 8875

Tuesday, April 8, 2008, 11:30:47 AM, you wrote:

> Tuesday 08 April 2008 17:28:18 napisałeś(-łaś):
>> For Spread 4.0, first, in your configuration file you must uncomment
>> and set the parameter:
>>
>> DangerousMonitor = true
>>
>> Then, run spmonitor on one of the machines running Spread, making
>> sure it uses the same configuration file as the Spread instantiation
>> in question.
>>
>> Inside spmonitor, use option 1 to define a partition by assigning
>> each of the daemons to an arbitrary partition number.  If all of your
>> daemons are up and connected, then you can simply assign one of them
>> to partition 1 and the rest to partition 2.
>>
>> Then use option 2 to send the partition to the daemons.  Wait until
>> the daemons have finished handling the partition and have installed a
>> new daemon membership.  You can see this either by watching the
>> output of a daemon, or you can use spmonitor to query the daemons and
>> note when their membership ID changes.  Alternatively, if you wait
>> for 60 seconds or so (at the longest) they should have handled the
>> partition by then.
>>
>> Finally, use option 4 to remove the artificial partition.  If user
>> traffic is being sent, then the daemons will discover one another
>> again quickly, reconnect and install a new membership.  If the
>> network is quiet, then they may take several minutes to discover that
>> the partition is gone.
> Does that results in messages being lost during these transitions?