-
15. Re: Features of JBoss Messaaging Message Bridge present in E
So, if I'm understanding this correctly, JBoss ESB supports QOS_ONCE_AND_ONLY_ONCE but only if both sides are XAConnectionFactory? If so that's nice... I may be able to work with that. How is this configured (enabled/disabled)?
I'd prefer QOS_DUPLICATES_OK for reasons Tim Fox got into. I don't think this should be hard; just wait until the service is done and THEN acknowledge the JMS message from the gateway.
I don't need batching... but Tim gave reasons why that's good too. -
16. Re: Features of JBoss Messaaging Message Bridge present in E
"timfox" wrote:
Another common situation is that users find using XA too slow to bridge each message from one provider to another, so instead opt for "DUPS_OK" quality of service mode, and then just detect duplicates in their own code at the end.
You know XA (and transactions in general) are much more than this, right ;-)?! -
17. Re: Features of JBoss Messaaging Message Bridge present in E
"Kevin.Conner@jboss.com" wrote:
The ESB also has other cool features not available in bridging :)
If you think I'm trying to compare the bridge to the whole ESB then that's certainly not what I was doing - apologies if that is the impression you have got. That would certainly be an apples-oranges comparison.
We were simply bringing to attention a component from JBM which seems to do similar things to a particular component in ESB (the jms router thingy). We've had to deal with a lot of the issues that you probably will have to do deal with, w.r.t reliability guarantees etc, and just thought you might be interested.
Let's avoid a pointless "my component is better than your component" discussion.
The user can decide what they want to use based on their requirements and the components functionality :) -
18. Re: Features of JBoss Messaaging Message Bridge present in E
"dsmiley" wrote:
So, if I'm understanding this correctly, JBoss ESB supports QOS_ONCE_AND_ONLY_ONCE but only if both sides are XAConnectionFactory? If so that's nice... I may be able to work with that. How is this configured (enabled/disabled)?
It is handled automatically if running within the context of a transaction and it references the XAConnectionFactory.
The JCA adapter already provides this (for JMS) but it is also possible for the scheduled listener/gateway to control the transaction and, from tomorrow, the message aware listeners will support it once again."dsmiley" wrote:
I'd prefer QOS_DUPLICATES_OK for reasons Tim Fox got into. I don't think this should be hard; just wait until the service is done and THEN acknowledge the JMS message from the gateway.
It should already be possible to configure the acknowledge mode. I believe Daniel added this functionality so perhaps he can add a comment to this."dsmiley" wrote:
I don't need batching... but Tim gave reasons why that's good too. -
19. Re: Features of JBoss Messaaging Message Bridge present in E
"timfox" wrote:
Let's avoid a pointless "my component is better than your component" discussion.
The user can decide what they want to use based on their requirements and the components functionality :)
I agree 100% :), the technologies solve different problems and work well together. -
20. Re: Features of JBoss Messaaging Message Bridge present in E
"mark.little@jboss.com" wrote:
"timfox" wrote:
Another common situation is that users find using XA too slow to bridge each message from one provider to another, so instead opt for "DUPS_OK" quality of service mode, and then just detect duplicates in their own code at the end.
You know XA (and transactions in general) are much more than this, right ;-)?!
I'm describing a very common pattern where users want an end to end "once and only once" delivery guarantee, but don't want to use XA to accomplish this because of performance issues.
E.g. you have a set of queues potentially each one living on a different system. Messages are consumed from one queue, the message is processed then the same or another message is passed to another queue for the next stage of the workflow.
If the system crashes at any point we don't ever want to be in a situation where the workflow stops mid way through, i.e. lose messages.
The "obvious" way to do this is after processing the message, to acknowledge it from the current queue and send it on to the next queue in a single transaction.
If the two queues are on different resource managers this would involve XA.
Alternatively you can send the message on to the next queue and acknowledge it from the current queue in separate transactions, but make sure that you send it on *before* you ack it.
In case of failure you may end up with the message sent, but not acked. So on recovery the same message might get processed again (i.e. you have duplicates), but you'll never end up losing a message.
Then, at the application level, you implement your own duplicate detection. E.g. you discard any messages whose id you have seen before. You can keep a cache of ids of the message you have seen. This of course needs to be persisted.
So the end result is a "once and only once" guarantee but without XA. (Assuming an infinite cache - but it's a trade off)
Anyway, don't know why you asked the question Mark, you know all this already :) -
21. Re: Features of JBoss Messaaging Message Bridge present in E
In other words make everything idempotent.
-
22. Re: Features of JBoss Messaaging Message Bridge present in E
Calm down guys, the original question has now been answered from both perspectives.
-
23. Re: Features of JBoss Messaaging Message Bridge present in E
This is very educational :-)
For dups... it's be neat if the JMS implementation of the receiving queue had the dup detection built-in so that the app didn't have to concern itself with this. Sounds pretty easy, too. Is it known if any do this? -
24. Re: Features of JBoss Messaaging Message Bridge present in E
"dsmiley" wrote:
This is very educational :-)
For dups... it's be neat if the JMS implementation of the receiving queue had the dup detection built-in so that the app didn't have to concern itself with this. Sounds pretty easy, too. Is it known if any do this?
That is a very good question. We plan to implement this for JBM 2.0 :) -
25. Re: Features of JBoss Messaaging Message Bridge present in E
About the acknowledgement mode, this can be set on the jms-message-filter element:
<jms-message-filter dest-type="QUEUE" dest-name="queue/Test" acknowledge-mode="AUTO_ACKNOWLEDGE"/>
Can be one of:
AUTO_ACKNOWLEDGE (default)
CLIENT_ACKNOWLEDGE
DUPS_OK_ACKNOWLEDGE.
/Daniel -
26. Re: Features of JBoss Messaaging Message Bridge present in E
Kevin, Dan, setting the ACK mode on the JMS session for a particular endpoint (producer and/or consumer) is not the same thing as implementing a QoS level across the service as a whole, which is what the message bridge supports and that the ESB currently does not.
http://jira.jboss.org/jira/browse/JBESB-1629
I should probably create another issue for batching support. -
27. Re: Features of JBoss Messaaging Message Bridge present in E
Yep, I agree that this is not a QoS setting and is purely the JMS acknowledge mode. I obviously misunderstood the question as I thought that was what you were asking for, apologies for this. :)
We have been holding a face 2 face this week in Newcastle (UK) and have the development team and other parties involved. Part of this meeting has focussed on a new transport architecture which will centralise all of these aspects, providing the ability for us to enforce policies (such as QoS) in a more generic manner. This development stream will occur in parallel with the current trunk and will be a big leap forward in the capabilities of the ESB.
At present we may not be quite there to satisfy your requirements but I can promise you that it is coming down the pipeline. Any input you wish to make into this process would be greatly appreciated.
Kev