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 2015/11/04 21:21:27 UTC
[jira] [Resolved] (DISPATCH-52) Distributed work-queue using
dispatch to federate brokers.
[ https://issues.apache.org/jira/browse/DISPATCH-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway resolved DISPATCH-52.
---------------------------------
Resolution: Fixed
> 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.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: [jira] [Resolved] (DISPATCH-52) Distributed work-queue using
dispatch to federate brokers.
Posted by "Gibson, Jack" <ja...@paypal.com.INVALID>.
Alan -
Can you point us to the example & tests? We can¹t get this to
consistently work for us hence the open JIRA bug for this.
Jack
On 11/4/15, 2:21 PM, "Alan Conway (JIRA)" <ji...@apache.org> wrote:
>
> [
>https://issues.apache.org/jira/browse/DISPATCH-52?page=com.atlassian.jira.
>plugin.system.issuetabpanels:all-tabpanel ]
>
>Alan Conway resolved DISPATCH-52.
>---------------------------------
> Resolution: Fixed
>
>> 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.3.4#6332)
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org