[Spread-users] Sending messages to a fixed set of servers

[Christian Schnell]

Ryan Caudy wrote:

> This service seems like a kind of persistent messaging service. 
> Services like this have been discussed on the list before, and there 
> may be some sort of similar service implemented in the JMS4Spread 
> project, but I don't know.  I don't see that it would be at all 
> unreasonable to use Spread as the lower layer in such an architecture, 
> though it would still be non-trivial.
>
> --Ryan
>
> Christian Schnell wrote:
>
>> Hello,
>>
>> I came only recently across GCS in general and spread specifically, 
>> and I'm really impressed by your substantiated and so valueable work, 
>> really great.
>>
>> I'm posting here because I'm looking for a specific extension to 
>> spread, here my sketchy requirements: A broadcast to a fixed set of 
>> servers, hiding the fact that any subset may not be reachable at the 
>> moment.
>>
>> What I have in mind is a service that delivers a message not only to 
>> the servers of a configuration (like spread) but eventually also to 
>> all remaining servers of a fixed superset (it is assumed that later 
>> configurations provide the missing network routes). That service 
>> should hide the details of storing, tracking, exchanging and removing 
>> the postponed messages (messages can be removed from the local 
>> storage as soon as it can be concluded that they have been delivered 
>> globally).
>>
>> Under the hood, the service provides some sort of lazy replication to 
>> synchronize the persistent message buffers of servers, all messages 
>> are delivered in consistent order to applications:
>> a) messages are delivered in the agreed order of their configuration,
>> b) successive configurations are processed in their sequential order and
>> c) non-sequential configurations in arbitrary order.
>>
>> I would imagine this service to inform the application twice about 
>> each message: once on arrival of a message and once right before it 
>> is discarded (when it is clear that it has been delivered to all 
>> servers), that should perhaps be configurable with each single 
>> message. It might also be usefull if the service would tag messages 
>> as being either 'live' or 'replay' when delivering to the application.
>>
>> Now my questions regarding all this:
>> - Do these requirements make sense to you? Has this been discussed 
>> here before?
>> - What would be the appropriate name for such a service?
>> - Any objections to implementing this as a layer on top of spread?
>> - Has this already been done with spread? Or with any other GCS?
>> - Does it make sense to start such an effort with spread or are there 
>> better ways to achive this?
>> - Anything else to learn from?
>>
>> Thanks,
>> Christian
>>
>> _______________________________________________
>> Spread-users mailing list
>> Spread-users at lists.spread.org
>> http://lists.spread.org/mailman/listinfo/spread-users
>>
>
Thanks Ryan.

I found out that in JMS it's correctly called "persistent delivery 
mode", but the current on-line documentation of JMS4Spread states that 
"The PERSISTANT Delivery Mode is currently not supported" (interface 
jms4spread.DeliveryMode). There are open JMS provider that support 
persistency (like for example "Mule JMS Provider" at 
http://www.muleumo.org/providers/jms/), but I'd like to avoid java in 
this case (don't get me worng, I'm a big Java fan, it just doesn't fit 
my current requirements).

I wish I could find some good readings on that... the best articles on 
the web that I could find are "Time, Clocks, and the Ordering of Events 
in a Distributed System" and "Epidemic Algorithms for Replicated 
Databases", various others, mostly about database replication in 
distributed environments but they usually present a solution without 
true support for network partitions (no update-anywhere-anytime, but 
that is of course implied by the databases ACID requirements). Anyone 
happen to know something worth reading for my problem?

Thanks,
Christian.