You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Ted Ross <tr...@redhat.com> on 2016/03/19 00:54:04 UTC
DISPATCH-179 branch has been merged
The large development branch for DISPATCH-179 has been merged onto
master. Please be advised that master will be a little unstable for the
next couple of days as loose ends are picked up. A good number of the
tests still are not passing. There's also one known crash situation
that I have a pending fix for.
This merge constitutes a significant architectural change to the core
routing function within Qpid Dispatch Router. It allows for major
improvements to the routing behavior, particularly with regard to waypoints.
Some highlights:
- The router now provides end-to-end flow control. It will no longer
create large backlogs on the FIFOs of outgoing links.
- The containers for link-routes and waypoints (i.e. brokers) can now
be identified by listener name as well as connector name. They can
also be identified by container-id. This allows for brokers that
initiate the connection inbound to the router network.
- Sender links into the router will not be issued credit until there
is at least one valid consumer to receive the message deliveries.
This means that it no longer matters that the consumer attache
before the producer. Producers will be blocked until there is a
consumer.
- Waypoints have been re-engineered and will work much more reliably.
- Many more...
Some important notes for those who wish to use the merged master:
The following configuration entities have been deprecated:
- fixedAddress - This is still supported with the following exceptions:
- The "/" address will no longer be accepted.
- Addresses with explicit phase values will no longer be accepted.
- linkRoutePattern - Still supported
- waypoint - Not currently supported
If there's an outcry regarding forward compatibility of the "waypoint"
configuration, we will consider providing it (or will accept pull
requests). My guess is that anyone who is struggling with waypoints
will prefer the new configuration style.
Here's a quick example of the new way to configure message routing to
two queues on the same broker (waypoints):
connector {
addr: 127.0.0.1
port: 20000
name: broker
role: route-container
saslMechanisms: ANONYMOUS
}
address {
prefix: queue
waypoint: yes
}
autoLink {
addr: queue.first_queue
connection: broker
dir: in
}
autoLink {
addr: queue.first_queue
connection: broker
dir: out
}
autoLink {
addr: queue.second_queue
connection: broker
dir: in
}
autoLink {
addr: queue.second_queue
connection: broker
dir: out
}
Note that only one address configuration is required to create a set of
waypoints within a prefix-defined address space. Note also that the
ingress and egress to the waypoint is now configured separately.
If single waypoints are used (by far the most common case I believe),
there's no need to interact with the concept of "phase" as was necessary
in the old configuration. Phase is only needed for more advanced setups
like moving messages from one queue to another or having multiple
waypoints along a path.
Regards,
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Fwd: DISPATCH-179 branch has been merged
Posted by Ted Ross <tr...@redhat.com>.
Forwarded from the dev list for broader exposure...
-------- Forwarded Message --------
Subject: DISPATCH-179 branch has been merged
Date: Fri, 18 Mar 2016 19:54:04 -0400
From: Ted Ross <tr...@redhat.com>
Reply-To: dev@qpid.apache.org
To: dev@qpid.apache.org
The large development branch for DISPATCH-179 has been merged onto
master. Please be advised that master will be a little unstable for the
next couple of days as loose ends are picked up. A good number of the
tests still are not passing.
This merge constitutes a significant architectural change to the core
routing function within Qpid Dispatch Router. It allows for major
improvements to the routing behavior, particularly with regard to waypoints.
Some highlights:
- The router now provides end-to-end flow control. It will no longer
create large backlogs on the FIFOs of outgoing links.
- The containers for link-routes and waypoints (i.e. brokers) can now
be identified by listener name as well as connector name. They can
also be identified by container-id. This allows for brokers that
initiate the connection inbound to the router network.
- Sender links into the router will not be issued credit until there
is at least one valid consumer to receive the message deliveries.
This means that it no longer matters that the consumer attache
before the producer. Producers will be blocked until there is a
consumer.
- Waypoints have been re-engineered and will work much more reliably.
- Many more...
Some important notes for those who wish to use the merged master:
The following configuration entities have been deprecated:
- fixedAddress - This is still supported with the following exceptions:
- The "/" address will no longer be accepted.
- Addresses with explicit phase values will no longer be accepted.
- linkRoutePattern - Still supported
- waypoint - Not currently supported
If there's an outcry regarding forward compatibility of the "waypoint"
configuration, we will consider providing it (or will accept pull
requests). My guess is that anyone who is struggling with waypoints
will prefer the new configuration style.
Here's a quick example of the new way to configure message routing to
two queues on the same broker (waypoints):
connector {
addr: 127.0.0.1
port: 20000
name: broker
role: route-container
saslMechanisms: ANONYMOUS
}
address {
prefix: queue
waypoint: yes
}
autoLink {
addr: queue.first_queue
connection: broker
dir: in
}
autoLink {
addr: queue.first_queue
connection: broker
dir: out
}
autoLink {
addr: queue.second_queue
connection: broker
dir: in
}
autoLink {
addr: queue.second_queue
connection: broker
dir: out
}
Note that only one address configuration is required to create a set of
waypoints within a prefix-defined address space. Note also that the
ingress and egress to the waypoint is now configured separately.
If single waypoints are used (by far the most common case I believe),
there's no need to interact with the concept of "phase" as was necessary
in the old configuration. Phase is only needed for more advanced setups
like moving messages from one queue to another or having multiple
waypoints along a path.
Regards,
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org