-
1. Re: Features of JBoss Messaaging Message Bridge present in E
beve Mar 27, 2008 2:53 AM (in response to dsmiley)Hi,
I believe you can get the same fault tolerance by configuring your connection factory, queue and JMSRouter. By configuring the queue as clustered and using a clustered connection factory this should be possible.
Take a look at the configuration options for JMSRouter:JMS Routing Action Processor. Sample Action Configuration: <action class="org.jboss.soa.esb.actions.routing.JMSRouter"> <property name="jndiName" value="queue/A"/> </action> Option properties (default values shown): <property name="unwrap" value="false"/> <property name="jndi-context-factory" value="org.jnp.interfaces.NamingContextFactory"/> <property name="jndi-URL" value="127.0.0.1:1099"/> <property name="jndi-pkg-prefix" value="org.jboss.naming:org.jnp.interfaces"/> <property name="connection-factory" value="ConnectionFactory"/> <property name="persistent" value="true"/> <property name="priority" value="javax.jms.Message.DEFAULT_PRIORITY"/> <property name="time-to-live" value="javax.jms.Message.DEFAULT_TIME_TO_LIVE"/> <property name="message-prop->prop-name<="> value="prop-value<" />
Or if you have other requirements please specify them and we'll take a look.
Regards,
/Daniel -
2. Re: Features of JBoss Messaaging Message Bridge present in E
dsmiley Mar 27, 2008 8:45 AM (in response to dsmiley)In my case, neither end of the queues are a JBoss Messaging implementation but I'm not convinced at all that even in that case, it settles the issue.
What will happen in the ESB if the destination queue is unavailable or the ESB crashes suddently? Obviously some error and/or exception would end up being logged but what would the state of the service & message be? This is where those QoS options for the bridge come in and I don't know which, in-effect, are the case for the ESB. If the ESB acknowledges message from the JMS gateway before any action processing begins, then your are offering QOS_AT_MOST_ONCE semantics. A quick look at JmsEndpoint.java suggests to me that is what is happening but I'd appreciate confirmation on this matter from JBoss. If you don't acknowledge until the service is done, then you are offering QOS_DUPLICATES_OK semantics. That in particular is the level I'd like if I could get it but it appears I'm SOL for now. Finally, if you do the whole thing under JCA then you offer QOS_ONCE_AND_ONLY_ONCE. I see that there are configuration options reflecting that the JMS gateway is transacted, but there appears to be no follow-through in the JMSRouter to get an end-to-end transaction. I'm not an expert on this matter so perhaps it's really there but I just don't know it.
For my needs... I definitely don't want the message being lost.
A related question i have is what if an action produces an exception... what happens then? I'm hoping there's some built-in retry mechanism.
This is something that should be prominently documented because it's an important matter for enterprise middle ware, IMO. -
3. Re: Features of JBoss Messaaging Message Bridge present in E
timfox Mar 27, 2008 11:33 AM (in response to dsmiley)I concur with dmiley.
Depending on the order in which ESB acknowledges the message from source and sends to destination come in, you will get either an "at most once" or "dups_ok" delivery guarantee.
For a "once and only once" delivery guarantee the ack and the send need to be in the same transaction.
If the source and destination are handled by the same resource manager then that transaction can be a simple local jms tx, otherwise it would need to be a JTA tx.
All the above cases are handled by the JBM bridge. I'm not clear they are handled by the ESB router.
I would consider guaranteed delivery (once and only once) to be a very common requirement for bridging. -
4. Re: Features of JBoss Messaaging Message Bridge present in E
timfox Mar 27, 2008 11:35 AM (in response to dsmiley)I'd avoid re-inventing the wheel, and leverage what we already have (bridge) for JMS routing.
-
5. Re: Features of JBoss Messaaging Message Bridge present in E
beve Mar 27, 2008 12:16 PM (in response to dsmiley)Sorry my bad...the JMSRouter cannot be used in such a situation.
The way we are currently doing this is using the jms-jca-provider to have a global transaction for an action pipeline. So the message acknowledgement is handled by the commit of the transaction. If we rollback the transaction the message will be redelivered.
But this only handles the incoming message. Not the part of sending out.
/Daniel -
6. Re: Features of JBoss Messaaging Message Bridge present in E
kconner Mar 27, 2008 12:17 PM (in response to dsmiley)You already have the ability to make this transactional within the ESB so it is not necessary to use the messaging bridge.
There is also no 'reinventing' going on here as we are just using standard JTA and JMS APIs. -
7. Re: Features of JBoss Messaaging Message Bridge present in E
kconner Mar 27, 2008 12:19 PM (in response to dsmiley)"beve" wrote:
But this only handles the incoming message. Not the part of sending out.
This is not true, the outgoing message will also be covered by the transaction.
The original 'transacted' notion has recently been tidied up to look at the current transactional context and not the EPR information. -
8. Re: Features of JBoss Messaaging Message Bridge present in E
beve Mar 27, 2008 12:34 PM (in response to dsmiley)Ah, cool. Is this in the main trunk or in one of the branches?
Thanks,
Daniel -
9. Re: Features of JBoss Messaaging Message Bridge present in E
timfox Mar 27, 2008 12:38 PM (in response to dsmiley)It's up to you.
You'll find the bridge has other nice features like message batching - being able to specify a batch size and a max batch time. I.e. send a batch every 10 seconds and/or every 1000 messages.
It also has reconnect functionality which makes it very useful over an unreliable WAN. We have lots of users/customers currently using it.
Also bear in mind that some JMS providers don't provide an XA resource implementation that can be used outside their app server, so you won't be able use a JTA transaction, in which case having fine grained control over your qos becomes important so users can do stuff like duplicate detection at the end in order to get an effective "once and only once" guarantee. -
10. Re: Features of JBoss Messaaging Message Bridge present in E
kconner Mar 27, 2008 12:47 PM (in response to dsmiley)"beve" wrote:
Ah, cool. Is this in the main trunk or in one of the branches?
It's in both CP and trunk at the moment. There is one more task to be completed by tomorrow though, the SQL integration has to be reverified. -
11. Re: Features of JBoss Messaaging Message Bridge present in E
timfox Mar 27, 2008 12:48 PM (in response to dsmiley)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.
This can often be much faster than using XA and gives the same overall reliability guarantee, but in order to do that you need to know that the bridge always sends the message on before acking it to the source (i.e. dups_ok) so in case of failure you know you will never lose any messages but may get duplicates. So fine grained qos control is useful there.
Then you might have other uses who never want duplicate messages, but don't mind losing a few - this is "at most once" delivery in messaging terminology. -
12. Re: Features of JBoss Messaaging Message Bridge present in E
timfox Mar 27, 2008 12:49 PM (in response to dsmiley)So I guess users have a choice - they can use the esb router if it suits their needs, or just use the bridge if they want more flexible QoS settings, batching and reconnection.
-
13. Re: Features of JBoss Messaaging Message Bridge present in E
kconner Mar 27, 2008 12:52 PM (in response to dsmiley)"timfox" wrote:
It's up to you.
Handling transactional JMS messages is a requirement of ours, this naturally comes out of it."timfox" wrote:
You'll find the bridge has other nice features
It has lots of cool features and it is a different beast from the ESB. The ESB also has other cool features not available in bridging :) -
14. Re: Features of JBoss Messaaging Message Bridge present in E
kconner Mar 27, 2008 12:52 PM (in response to dsmiley)"timfox" wrote:
So I guess users have a choice - they can use the esb router if it suits their needs, or just use the bridge if they want more flexible QoS settings, batching and reconnection.
Not quite how I would put it but I do agree with the choice ;)