[Spread-users] Novice question about Distributed Queues

[Ryan Caudy]

There have been other discussions of similar messaging needs on this 
list in the past.  One suggestion, if I recall, has clients pick a given 
member of the group to dispatch their requests to, via the private group 
name.  I would suggest a slight modification to the scheme described by 
Ned -- basically, server replies are sent AGREED, and the first one to 
be delivered gets to service the request.  By replying only when some 
resource is available locally, you could even achieve some sort of 
load-balancing.

--Ryan

Ned Konz wrote:

> On Monday 29 March 2004 9:17 am, Ranjan Bagchi wrote:
> 
>>Hi --
>>
>>I've come across Spread and am very impressed with what it offers.  I've
>>spent a lot of time doing pub/sub development (specifically using Tib/RV).
>>
>>One architecture I was able to do in Tib uses what Tib calls Distributed
>>Queues:  where instances of a service were started on different machines,
>>and became members of a "distributed queue" group.  A message sent to this
>>group would be sent to only one member of this group.  Doing this allowed
>>easy scalability, since you could get more capacity by just starting more
>>instances of the service.
>>
>>Is this something which can be done in Spread?  Is there a workaround to
>>get this kind of scalability?
> 
> 
> 
> You could do this (I think):
> 
> * service instances join a request group
> * requests are sent to this group by a client
> * service instances which heard the request respond to the group (unless they 
> also heard that another service instance had been chosen)
> * the client picks one (perhaps the first one) of the service instances that 
> replied to its request
> * and then the client sends an acknowledgement to the group
> * which will keep any service instances that hadn't heard the request yet from 
> responding unnecessarily to the first request (assuming that they get all the 
> pending messages before responding to the incoming requests).
> 
> clientA requests: "I'd like service (my request ID is 123)"
> server1 offers: "I can do it!"
> server2 offers: "I can do it!"
> clientA acknowledges: "I picked server1"
> <server1 goes off and does the service>
> <server3 now checks its messages and finds both the request and the 
> acknowledgement, so does not offer>
> server1: "I'm done with request #123 for clientA"
> 

-- 
Ryan W. Caudy
Center for Networking and Distributed Systems
Department of Computer Science
Johns Hopkins University