[Spread-users] Spread message queueing questions
rob_butler at hotmail.com
Tue Apr 9 15:54:26 EDT 2002
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
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.
Chat with friends online, try MSN Messenger: http://messenger.msn.com
More information about the Spread-users