[Spread-users] Spread for large message sizes

Doug.Palmer at csiro.au Doug.Palmer at csiro.au
Tue Mar 4 19:03:24 EST 2003


> There is a Java wrapper to Spread that handles disassembly and
> re-assembly while maintaining semantics for most 
> applications.  Refer to
> the links below for full discussion on which environments it 
> make sense
> to use it and in which it doesn't.
> 
> Refer to the discussion here
> http://www.spread.org/pipermail/spread-users/2002-June/000815.html.
> 
> Refer to the code here
> http://lists.spread.org/pipermail/spread-users/2002-May/000784.html.

Thanks for the code. I've had to finangle with it a bit to get it to support
listeners (basically changing receive() to internal_receive() and guarding
for nulls in the info.getLeft()/info.getDisconnected() calls). But it all
seems pretty happy, otherwise.

A couple of questions that I can't figure out from examining the code and
mailing list:

* If I have two producers (A and B) multicasting to the same group using
large messages, is it possible for the fragmented messages to arrive in
mixed order? Say A_1, B_1, B_2, A_2, B_3. Is this handled? I think
enqueueMsg does this, but I've got a bit lost.

* What are the effects on the message safety semantics? If the messages are
queued, as I think they are, they should appear at the client in the same
order that the initial headers arrived, this should take case of FIFO,
Causal and Total Order semantics. I don't suppose that Safe can be
guaranteed?

This pretty much deals with my original motivation. So thankyou. I would
like to reiterate my original questions, however:

> >>Is the message size a hard limit?
> >>Can I change it by settings in spread.conf or somewhere?
> >>Is it tied to some fundamental design limit, or could I recompile
> spread
> >>with different settings? (And if so, how?).

This is simply because the limit seems a little arbitrary -- unless there's
some subtle fundamental limitation that drives things. Arbitrary limits are
usually configurable somewhere, so I'd be interested to know if there is a
way of configuring Spread to get large messages.




More information about the Spread-users mailing list