[Spread-users] Spread message queueing questions

[Joshua Goodall]

On Mon, Apr 08, 2002 at 03:14:42PM +0000, Rob Butler wrote:
> Hello all,
> 
> Does spread perform any "message queueing" for reliable messages similar to 
> MQ series?
>
> I.E. if a client goes down, will the server still hold onto messages for 
> that client and deliver them when the client comes back up?

No. Spread makes no attempt at persistence. (That is not its function).

> If the server should go down, are messages stored to disk so they are 
> available when the server is restarted?

No.

> How many messages can the server hold for the client, before it will start 
> dropping messages for the client?  Does it drop old or new messages?

Spread should never intentionally drop a message; instead, it
disconnects the client when it gets more than MAX_SESSION_MESSAGES
behind. That compile-time knob defaults to 1000.
> 
> How many clients can a spread server reasonably support?

There is a hard, compiled-in limit of 997, which you can raise by
increasing MAX_FD_EVENTS.

~/src/spread/daemon$ grep MAX_FD_EVENTS *.h
sp_events.h:#define             MAX_FD_EVENTS            2000
spread_params.h:#define         MAX_SESSIONS            ( ( MAX_FD_EVENTS-5 ) / 2 ) /* reserves 2 for each connection */

Spread uses select(2) and is therefore potentially limited by FD_SETSIZE,
often 1024, although again this could be raised (platform-dependent) at
compile time.

As for "reasonably support"; that depends how fast your machine and
network is, how much traffic you're doing, of what size (and what
Spread type), how many other daemons there are in the segment, how
loaded they are, etc. So you need to run some speed trials.

( example: one spread daemon, 100 spflooder readers, 1 spflooder writer,
all through localhost: 10000 messages of 1000 bytes each, reliably sent
and received by all readers in 102 seconds on a Duron 900.

That's 765kbit/sec written, and 74mbit/sec of received traffic.
Or say 98 msgs/sec written, and 9800 msgs/sec received.

Turn it around with 10 writers and one reader, and it completes in
24.351sec.  That's 31mbit of sustained traffic, about 4106 messages/sec.

spflooder is not a real-world workload.


> If spread is unable to do these things now, will it have these capabilities 
> soon? When?

I doubt that spread would gain facilities itself at that layer.
Instead it would be used as the communication library underlying a
package with such capabilities.

I have been thinking about this for a while and imagine going the
whole hog, hanging an OODB off a group and use tuple-spaces (a la
Linda, or Javaspaces) for a persistent abstraction of publish/subscribe.
That would be fun :)

Joshua