You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Alan Conway (JIRA)" <ji...@apache.org> on 2014/05/14 16:33:14 UTC

[jira] [Created] (DISPATCH-52) Distributed work-queue using dispatch to federate brokers.

Alan Conway created DISPATCH-52:
-----------------------------------

             Summary: Distributed work-queue using dispatch to federate brokers.
                 Key: DISPATCH-52
                 URL: https://issues.apache.org/jira/browse/DISPATCH-52
             Project: Qpid Dispatch
          Issue Type: Task
          Components: Router Node
            Reporter: Alan Conway
            Assignee: Alan Conway


Create a demonstration of a distributed work queue consisting of multiple brokers with the following requirements:
- Producers send to a single address, consumers subscribe to a single address.
- Each message is delivered to exactly one of the consumers (not fault tolerant/transactional)
- Consumers may connect and disconnect during the exercise without message loss.
- Messages are roughly balanced over consumers.
- All messages are delivered even if all but one consumer disconnects.
  - In particular, messages do not get "stuck" on one broker because the consumer is only receiving from another brokers.

Goals: 

1. Discover what changes to dispatch are needed to achieve this demonstration, enhance dispatch in a flexible way to support this and other possible "orchestration" tasks.

2. Once basic functionality is in place, explore further issues such as
   - Performance: what overhead does dispatch add in throughput and latency vs. direct broker access?
   - Scalability: can we scale total throughput linearly by adding brokers (and perhaps dispatch routers)?
Are there limits/bottlenecks in dispatch that need to be addressed in order to scale?
   - HA: If we use fault tolerant broker clusters can we get reliable at-least-once delivery? What changes to dispatch are needed to handle fail-over?

3. Build a similar demo of a distributed topic (TODO specify in more detail), to see if the extensions to dispatch are sufficient to support a different type of orchestration.

4. Push improvements into dispatch as they become mature/usable in a general context.





--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org