[Spread-users] Spread message queueing questions

[Rob Butler]

Clark thanks for the answers.

A few more questions.

>Although, a very _neat_ feature to add to spread library would
>be a "peer" process which plays the role of "recorder" and
>is only an observer in a given room keeping the message history.
>This recorder could then be queried by a peer who has been
>disconnected for all of the messages that they missed.  I'd like
>such a "recorder process", but it shouldn't be that hard to write.
>The hard part (the synconization and low level messaging stuff)
>is already done... a recorder shouldn't be the show stopper, no?

The recorder process is a very neat idea.  It is along the lines of an idea 
I had, but making the recorder process completely separate from my 
application would give it wider use / re-use.

>This would also be a good role for a recorder, although since the
>recorder may die you may need some way to implement "shifts" so
>that when a recorder's shift ends another recorder takes over... ;)
...
>The hardest part about making a recorder would be getting
>the fail-over mechanism to work so that if the recorder
>died every peer knew to stop talking till the recorder is
>replaced.

This would be easier if you built another "message queue" application on top 
of spread.  You could have that application take note of the recorder 
process dying, and all "message queue" servers would not send data until the 
recorder was restarted.

>Nice.  How about contributing?  Why not learn spread and write
>the recorder component?  You seem to have a very good idea as
>to what would be required!  ;)

Maybe.  Although would there be any benefit to developing a solution on top 
of spread VS developing a solution that would allow non-java programs to 
take advantage of JMS services?  I.E. does JMS allow total order message 
queing?  Or, if it doesn't, then using spread and another package on top of 
it we could make total order queued messages a possibility.  If anyone has 
any idea's of what the advantages of developing message queueing on top of 
spread would be VS using JMS I'd love to hear them.

Using JNI to develop c++ or perl interfaces to a JMS system wouldn't be too 
tough.  Building native c++, or c interfaces (without using JNI) would be 
much more difficult (But I think much more useful too).

I'm going to look into JMS more and see what is possible using it.

Thanks everyone.


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com