[Spread-users] newbie question(s)

Ryan Caudy rcaudy at gmail.com
Thu Mar 1 07:21:34 EST 2007


Responses in-lined, again.

Cheers,
Ryan

On 3/1/07, cgnicholas at alamedanet.net <cgnicholas at alamedanet.net> wrote:
>
>
> > Spread doesn't implement persistent messages.
>
> Fair enough; certain systems are optimized for performance and
> scalability; i.e. the game of basketball doesn't really worry about
> players visiting their lockers during a 'pick', nor the game of football
> during a screen, etc. play
>
> > Basically, each daemon holds one global in-memory queue of messages that
> can't yet be delivered due to sequence number gaps or some other
> condition that prevents guarantees from
> > being met.
>
> *one* global queue?  at what granularity are the locks?


Global, in the sense I meant it, is per-daemon.  This implements total
ordering and "safety" across all groups.
Locking isn't really relevant... the Spread daemon is programmed in an
event-driven model... data structures are left in a consistent state before
returning to the event-handling loop.

> Additionally, each daemon holds a queue for each of its local clients of
> messages that have been "delivered," but that haven't yet been written
> to the mailbox (socket) for that client.
>
> (I guess not a single global, but multiple, etc locks...?) We are looking
> at an http/poll case, where things might queue (and build up...) for a
> while, and never get drained... At some point the spread connection (from
> the client side) will get torn down



> The per-client queues have a maximum size limit, after which the client
> > will be cut off... Spread requires that applications implement their own
> flow
> > control.
>
> Again, within an http case, things might accumulate for a while, and then
> the connection gets  dropped.


Spread may tear down the connection on the daemon side if the client fails
to receive messages and allows enough to accumulate.  It sounds to me like
your application will be able to handle this... subsequent receive calls
will identify this problem.

> Once a client disconnects, its queue is eliminated by the daemon
> > it was connected to.
>
> good/excellent/necessary
>
>
> > Note that leaving a group doesn't immediately clear the queue of
> messages
> > delivered to that client because of that group... receipt of a
> > "self-leave"
> > message tells the client when it has cleared the remaining messages and
> > officially been removed from the group with respect to the ordering
> > guarantees.  If I recall, join and leave events are treated as AGREED
> > messages.
> >
>
> hmmm - are these nuances exposed via the Java interface?


I'm sure they are.  The "self-leave" is simply a lightweight (caused by
leave) membership message.

>>b) How long do spread groups remain "alive" on a server if nobody is
> >> sending or receiving?
>
> > They don't.  When the last member is removed (see the above discussion
> of
> > ordering), they disappear.
>
> good/excellent
> >
> >
> >> c) what should I be asking that I'm not?
>
> > Good question.  Lots of people ask about their particular network
> > configuration (how many daemons, overall scalability issues).  You might
> > want to ask about the performance implications of having huge numbers of
> > groups active at once,
>
> actually, it's a 'sparse' matrix: conceptually lots of groups (i.e. we
> recompiled for a groupname of 32-64 characters) but practically a much
> smaller subset at any one time


The "sparse" matrix was my understanding, but your description stills
suggests the potential for a large number of groups, depending on how small
the active subset is.

> I recommend that you use the very latest version of Spread
>
> will do!
>
> >> thanks in advance!
>
> and thanks again!!!
>
> Chris
>
>
>
> _______________________________________________
> 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/20070301/01afe9a9/attachment.html 


More information about the Spread-users mailing list