[
https://issues.apache.org/jira/browse/DISPATCH-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997605#comment-13997605
]
ASF subversion and git services commented on DISPATCH-52:
---------------------------------------------------------
Commit 1594588 from [~aconway] in branch 'dispatch/trunk'
[ https://svn.apache.org/r1594588 ]
QPID-DISPATCH-52: Automated system test of dispatch sending messages through a
broker queue.
Using waypoints, the test sends a message into dispatch, out to a broker queue,
back to dispatch fromt the queue and delivers to a dispatch subscriber.
Gotchas:
- broker and broker queue must be set up before starting dispatch.
- must wait for dispatch to connect to the broker before sending message.
Improvements:
- system_tests.TestCase.get_port: check if port is used before returning it.
- Qdrouter.is_connected: test if router has a connection using management info.
- additional logging in waypoint.c
- fixed test/config_build.sh env to find qdstat
> 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: [email protected]
For additional commands, e-mail: [email protected]
