[ https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845235#comment-16845235 ]
Justin Ross commented on DISPATCH-1337: --------------------------------------- After we talked about this today, the terminology that really helped me understand the feature was "fallback links". This is not about fallback *addresses*. Rather, an address can have 0..n fallback links that consume deliveries only if no other (primary, non-fallback) consuming link is present. The fallback-ness is associated with the link, not the address. The *enablement* of fallback behavior *is* associated with an address prefix. I think this does introduce a bit of confusion. But it's not the main thing conceptually. The stuff in the paragraph above is the important part. > Alternate Destination for Unreachable Addresses > ----------------------------------------------- > > Key: DISPATCH-1337 > URL: https://issues.apache.org/jira/browse/DISPATCH-1337 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node > Reporter: Ted Ross > Assignee: Ted Ross > Priority: Major > Fix For: 1.8.0 > > > This feature allows addresses to be configured such that an alternate > destination can be used to receive messages that are not deliverable to any > normal consumers on the address. > Typically, this feature will be used to allow a message broker to store > messages that are not routable directly to consumers. When one or more > consumers are attached in the router network, messages shall be delivered > directly to the consumers. Where there are no reachable consumers, > deliveries shall then be diverted to the alternate destination. Once > consumers re-connect to the network, messages shall again be delivered > directly. > When a consumer comes online after messages have been stored in a broker, it > shall receive the stored messages interleaved with new messages from > producers. No attempt shall be made by the router network to preserve the > original delivery order of the messages. > This feature can be configured by adding the attribute > {noformat} > alternate: yes > {noformat} > to an address configuration. This attribute tells the router that any address > matching the configuration that appears shall support the alternate > destination capability. > There are two ways to create an alternate destination for an address: > Using auto-links: > An auto-link (or a pair of auto-links) can be configured to create an > alternate waypoint for an address. For example, assume that there is a > route-container connector or listener for a broker called "alternate-broker". > {noformat} > address { > prefix: position_update > alternate: yes > } > autoLink { > address: position_update.338 > direction: in > connection: alternate-broker > alternate: yes > } > autoLink { > address: position_update.338 > direction: out > connection: alternate-broker > alternate: yes > } > {noformat} > The above configuration will use a queue on the broker called > "position_update.338" as the alternate destination for direct consumers. > Furthermore, since there are both _in_ and _out_ auto-links, the router(s) > shall send queued messages to newly attached direct consumers. > Using terminus capabilities: > As an alternative to using auto-links, the broker (or any other process) can > attach sending and receiving links to the address with terminus-capability > "qd.alternate". This will create the same behavior as the above example. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org