Thanks Ted. I have found this https://github.com/apache/qpid-proton/blob/master/docs/markdown/messenger/addressing-and-routing.md may be useful.
On Thu, Dec 3, 2015 at 9:13 PM, Ted Ross <[email protected]> wrote: > > On 12/03/2015 09:20 AM, Olivier Mallassi wrote: > >> gentlemen, thank you for your answers. >> >> @Ted: I am currently trying to use the router and so I am moving to AMQP >> 1.0 (which by itself is a topic). So, I would say yes. Were you thinking >> about any limitations / recommendations regarding the linkRoutePattern? >> > > No, I think link-routes are what you need to best serve your use case. > > >> @Jack, Ted: I will look at the settlement & disposition knowing I cannot >> afford to loose a message (Financial Services). >> >> The overall idea would be to create that chain: publisher (Java/qpid-JMS >> or C++/Qpid Messaging) --> routers --> brokers (prefered option java, if >> not C++ is fine) --> routers --> consumers (Java / qpid-JMS) >> >> For sure this will not be straight forward but it seems doable? no? >> > > Yes, this is doable. It is one of the intended use cases for Dispatch > Router. > > With regard to the link-protocol/message-settlement: The router(s) don't > ever assume ownership of transiting messages. In other words, the routers > will not acknowledge or settle messages that pass through them. That is > left to the endpoints. So any messages that are lost due to router failure > or connection failure will remain in-doubt between the publisher/consumer > and the broker and will therefore be re-sent once the loss of connectivity > is fixed. > > > >> oliv/ >> >> On Wed, Dec 2, 2015 at 5:18 PM, Ted Ross <[email protected]> wrote: >> >> Dispatch does support the full AMQP link protocol (settlement and >>> disposition). >>> >>> -Ted >>> >>> >>> On 12/02/2015 11:15 AM, Gibson, Jack wrote: >>> >>> You could possibly just use settlements and acknowledgements not sure of >>>> the support with dispatch for that. At least you could manage some level >>>> of delivery guarantees. >>>> >>>> Jack Gibson >>>> Chief Architect >>>> Core Payments Platforms/PayPal >>>> >>>> >>>> >>>> On 12/2/15, 7:22 AM, "Ted Ross" <[email protected]> wrote: >>>> >>>> As Jack correctly pointed out, this is currently a missing feature in >>>> >>>>> Dispatch Router. There is a Jira >>>>> (https://issues.apache.org/jira/browse/DISPATCH-195) open to track the >>>>> issue. >>>>> >>>>> In your use case, are you using routed links (i.e. with >>>>> linkRoutePattern >>>>> in your router configuration)? >>>>> >>>>> Also, since your use case involves a database, are you expecting >>>>> support >>>>> for XA or distributed transactions? We plan to add local transactions >>>>> (client-to-broker, or endpoint-to-endpoint) in the near future but >>>>> distributed transactions will take longer. >>>>> >>>>> -Ted >>>>> >>>>> On 12/01/2015 06:52 PM, Olivier Mallassi wrote: >>>>> >>>>> hello all >>>>>> >>>>>> I was wondering if qpid dispatch was supporting trnasaction. in fact >>>>>> the >>>>>> pattern I would need to implement is the following (a classic one) >>>>>> >>>>>> Publisher (java/c++) >>>>>> beginTransaction > insert rdbms > publish msg > commit >>>>>> >>>>>> the amqp infra would be dispatch + java qpid broker. >>>>>> >>>>>> I assume it works. Can someone confirm please? >>>>>> >>>>>> Thx for your help >>>>>> >>>>>> olivier. >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
