Responses in-lined, again.<br><br>Cheers,<br>Ryan<br><br><div><span class="gmail_quote">On 3/1/07, <b class="gmail_sendername"><a href="mailto:cgnicholas@alamedanet.net">cgnicholas@alamedanet.net</a></b> <<a href="mailto:cgnicholas@alamedanet.net">
cgnicholas@alamedanet.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>> Spread doesn't implement persistent messages.
<br><br>Fair enough; certain systems are optimized for performance and<br>scalability; i.e. the game of basketball doesn't really worry about<br>players visiting their lockers during a 'pick', nor the game of football
<br>during a screen, etc. play<br><br>> Basically, each daemon holds one global in-memory queue of messages that<br>can't yet be delivered due to sequence number gaps or some other<br>condition that prevents guarantees from
<br>> being met.<br><br>*one* global queue? at what granularity are the locks?</blockquote><div><br>Global, in the sense I meant it, is per-daemon. This implements total ordering and "safety" across all groups.
<br>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.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Additionally, each daemon holds a queue for each of its local clients of<br>messages that have been "delivered," but that haven't yet been written<br>to the mailbox (socket) for that client.<br><br>(I guess not a single global, but multiple, etc locks...?) We are looking
<br>at an http/poll case, where things might queue (and build up...) for a<br>while, and never get drained... At some point the spread connection (from<br>the client side) will get torn down</blockquote><div> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> The per-client queues have a maximum size limit, after which the client<br>> will be cut off... Spread requires that applications implement their own<br>flow<br>> control.<br><br>Again, within an http case, things might accumulate for a while, and then
<br>the connection gets dropped.</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Once a client disconnects, its queue is eliminated by the daemon<br>> it was connected to.
<br><br>good/excellent/necessary<br><br><br>> Note that leaving a group doesn't immediately clear the queue of messages<br>> delivered to that client because of that group... receipt of a<br>> "self-leave"
<br>> message tells the client when it has cleared the remaining messages and<br>> officially been removed from the group with respect to the ordering<br>> guarantees. If I recall, join and leave events are treated as AGREED
<br>> messages.<br>><br><br>hmmm - are these nuances exposed via the Java interface?</blockquote><div><br>I'm sure they are. The "self-leave" is simply a lightweight (caused by leave) membership message.
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>>b) How long do spread groups remain "alive" on a server if nobody is
<br>>> sending or receiving?<br><br>> They don't. When the last member is removed (see the above discussion of<br>> ordering), they disappear.<br><br>good/excellent<br>><br>><br>>> c) what should I be asking that I'm not?
<br><br>> Good question. Lots of people ask about their particular network<br>> configuration (how many daemons, overall scalability issues). You might<br>> want to ask about the performance implications of having huge numbers of
<br>> groups active at once,<br><br>actually, it's a 'sparse' matrix: conceptually lots of groups (i.e. we<br>recompiled for a groupname of 32-64 characters) but practically a much<br>smaller subset at any one time
</blockquote><div><br>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. </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> I recommend that you use the very latest version of Spread<br><br>will do!<br><br>>> thanks in advance!<br><br>and thanks again!!!<br><br> Chris<br><br><br><br>_______________________________________________<br>
Spread-users mailing list<br><a href="mailto:Spread-users@lists.spread.org">Spread-users@lists.spread.org</a><br><a href="http://lists.spread.org/mailman/listinfo/spread-users">http://lists.spread.org/mailman/listinfo/spread-users
</a><br></blockquote></div><br>