Answers in-lined.<br><br>Cheers,<br>Ryan<br><br><div><span class="gmail_quote">On 2/27/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;">apologies in advance for a few questions that are no doubt answsered
<br>somewhere in the archives, etc, but here goes:<br><br>I'm thinking to use spread for an app that logically might have a *vast*<br>number of groups, but only a reasonably small number active at any one<br>time; i.e
. the naming for a spread group is essentially a 4D cube,<br>according to "x_y_z_t" , i.e. groups consist of who is "nearby" in<br>quantized space and time. I'm wondering:<br><br>a) Will internal queues of unread messages eventually get cleaned up, if
<br>they aren't drained, and the listener that joined the various groups<br>dropped its connection?</blockquote><div><br><br>Spread doesn't implement persistent messages. 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. 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.
<br><br>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. Once a client disconnects, its queue is eliminated by the daemon it was connected to.
<br><br>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.
<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;">b) How long do spread groups remain "alive" on a server if nobody is
<br>sending or receiving?</blockquote><div><br><br>They don't. When the last member is removed (see the above discussion of ordering), they disappear.<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;">
c) what should I be asking that I'm not?</blockquote><div><br><br>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, if this is a potential scenario for you application. I recommend that you use the very latest version of Spread, as it has a lot of enhancements to this code, although it's been further improved since I took performance measurements. Maybe one of the Spread Concepts guys could help with this, if you need details.
<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;">thanks in advance!<br><br>Chris<br><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>