[Spread-users] 1225

Tue Mar 5 12:56:34 EST 2002

George,

YOU'RE RIGHT! In fact if I do anything else apart from
receiving messages I become too slow a client
for spread & very likely to get shut down.
These are the scenarios:

THIS ONE RECEIVES ALL MESSAGES.

while (1)
     {
     if (!msg.Receive(...))
          exit in error
     }

BUT THIS ONE GETS SHUT DOWN - because of the test.

while (1)
     {
     if (!msg.Receive(...))
          exit in error

     if (msg.GetNumRecvd() == 100000)) // any variations of this test makes
client to slow
               print num messages received
     }

GetNumRecvd is a static inline method that just returns num msgs processed
(c++).
Hmmm,... interesting! Guess the problem is that messages are accumulating
in spread too fast. This is a good thing BUT is this feature (of kicking
off
humble, slow clients) something that can be prevented or altered
through configuring spread?

Regards, Koorosh

                    George Schlossnagle                                                                                                 
                    <george at omniti.com>              To:     koorosh.alahiari at ids.allianz.com                                           
                    Sent by:                         cc:     guido at python.org, spread-users at lists.spread.org,                           
                    spread-users-admin at lists.        spread-users-admin at lists.spread.org                                                
                    spread.org                       Subject:     Re: [Spread-users] 1225                                               

                    05/03/02 17:31                                                                                                      

It may be due to the delay writing to your tty.  Try a client like
spreadlogd (http://www.lethargy.org/mod_log_spread/spreadlogd.tar.gz)
that writes to disk instead (or try one that just joins, reads and
counts.)

On Tuesday, March 5, 2002, at 11:15 AM, koorosh.alahiari at ids.allianz.com
wrote:

>
> George,
>
> My client (and spuser) & Server are all on the same machine.
> My undestanding is that TCP/IP is clever enough to detect that
> and not let the packet leave the machine (I could very well be WRONG
> here)!
> And the machine I am trying things on is a 4 processor Sun E10000
> running
> Solaris 7.
>
> I will try things out with a kind of client that you are suggesting and
> let
> you know!
>
> Thanks & Best Regards - Koorosh
>
>
>
>
>                     George
>                     Schlossnagle         To:
> koorosh.alahiari at ids.allianz.com
>                     <george at omnit        cc:     guido at python.org,
> spread-users at lists.spread.org,
>                     i.com>               spread-users-
> admin at lists.spread.org
>                                          Subject:     Re:
> [Spread-users] 1225
>                     05/03/02
>                     17:07
>
>
>
>
>
> Ok.... so now spuser isn't processing fast enough.   Is there a high
> degree of latency or packet-loss on your network?  Have you tried a
> client which does not update the screen for every message?
>
>
> On Tuesday, March 5, 2002, at 10:58 AM, koorosh.alahiari at ids.allianz.com
> wrote:
>
>>
>> Not joining the group got me a bit further (up to 7419 see below).
>> After that spuser was kicked off! BUT my client thinks it has delivered
>> all 100,000 messages.
>>
>> User>
>> ============================
>> received RELIABLE message from #XXXXXXXX, of type 0, (endian 0) to 1
>> groups
>> (17 bytes): Test message 7419
>>
>> User>
>> ============================
>> SP_error: (-8) Connection closed by spread
>>
>> ============================
>>
>> Bye.
>>
>>
>>
>>
>>                     George Schlossnagle
>>                     <george at omniti.com>              To:     Guido van
>> Rossum <guido at python.org>
>>                     Sent by:                         cc:
>> koorosh.alahiari at ids.allianz.com, spread-users at lists.spread.org
>>                     spread-users-admin at lists.        Subject:     Re:
>> [Spread-users] 1225
>>                     spread.org
>>
>>
>>                     05/03/02 16:44
>>
>>
>>
>>
>>
>> To elaborate (perhaps superfluously).  Your sender need not sp_join()
>> the group it is sp_multicast()'ing to.  In fact, unless you have it
>> setup to read messages at well, you do not want ti to join the group,
>> otherwise you will get the behavior you are seeing here.
>>
>> George
>>
>> On Tuesday, March 5, 2002, at 10:41 AM, Guido van Rossum wrote:
>>
>>>> I have a client that generates the messages and I run spuser as
>>>> another
>>>> client
>>>> that joins the group my program sends the messages to.
>>>> spuser printsout all the messages (up to 1225) BUT my program
>>>> does not try the to receive the messages that it is
>>>> sending itself.
>>>> Looks like things are happening too fast
>>>> for spread to handle correctly!
>>>
>>> Is the sender a member of the group to which it sends the messages?
>>> Then you're running into the 1000-message limit -- I bet the sender
>>> isn't set up to receive its own messages, but the Spread semantics
>>> make this happen.
>>>
>>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>>>
>>>
>>> _______________________________________________
>>> Spread-users mailing list
>>> Spread-users at lists.spread.org
>>> http://lists.spread.org/mailman/listinfo/spread-users
>>>
>>>
>> // George Schlossnagle
>> // Principal Consultant
>> // OmniTI, Inc                      http://www.omniti.com
>> // (c) 301.343.6422   (e) george at omniti.com
>> // 1024D/1100A5A0  1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0
>>
>>
>>
>> _______________________________________________
>> Spread-users mailing list
>> Spread-users at lists.spread.org
>> http://lists.spread.org/mailman/listinfo/spread-users
>>
>>
>>
>>
>>
>>
>>
> // George Schlossnagle
> // Principal Consultant
> // OmniTI, Inc                      http://www.omniti.com
> // (c) 301.343.6422   (e) george at omniti.com
> // 1024D/1100A5A0  1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0
>
>
>
>
>
>
>
// George Schlossnagle
// Principal Consultant
// OmniTI, Inc                      http://www.omniti.com
// (c) 301.343.6422   (e) george at omniti.com
// 1024D/1100A5A0  1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0

_______________________________________________
Spread-users mailing list
Spread-users at lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users