On Fri, 2015-12-04 at 15:19 -0500, Ted Ross wrote: > Olivier, > > Please be advised that the Messenger API in proton is not getting a > lot > of developer attention. The development effort has shifted to the > reactive APIs and it's likely that the reactive interfaces are what > are > going to be best supported in the future. > > The Messenger API is quite abstract (hides the concepts of > connection, > session, and link) and is therefore appealing for simple use cases. > In > practice, however, it's been found to be difficult to integrate into > real environments.
It also has some significant limits in its error reporting and handling. Those could be addressed eventually, but as Ted says, the focus has shifted to the reactive APIs. They offer more of a a "sliding scale" in terms of ease-of-use vs. flexiblity: It is still pretty easy to do simple things, but there is an open path to learning more and digging deep into the protocol details if/when you need to. > > -Ted > > On 12/04/2015 02:11 PM, Olivier Mallassi wrote: > > Thanks Ted. > > > > I have found this > > https://github.com/apache/qpid-proton/blob/master/docs/markdown/mes > > senger/addressing-and-routing.md > > may be useful. > > > > On Thu, Dec 3, 2015 at 9:13 PM, Ted Ross <tr...@redhat.com> 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 <tr...@redhat.com> > > > > 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" <tr...@redhat.com> 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: users-unsubscr...@qpid.apache.org > > > > > > > For additional commands, e-mail: > > > > > > > users-h...@qpid.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > ---------- > > > > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > > > > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > ---------- > > > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > > > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > > > ---- > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
