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.
-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/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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
