jms-jca-provider retries and guranteed delivery

[joe_boy12]

hello ESB gurus

I need your help/opinion here - I am working on a big integration project and we are using JBoss SOA 5.1 stack. I have following functional req.

1. Listen for a JMS XML message (Queue) - Gateway in main entry to JBoss SOA - OneWay

2. Need to send this event to 3 (service A, B and C) different WSDL based services - each one has its own XML request structure - I use static router here to fork the event.

3. Based on certain elements and attributes - fetch the different data from other web services/DBand enrich it. (RequestResponse MEP)

3. Transform enriched data to the target XML (Smooks/XSLT)

4. Call WSDL based WS - if Fault is received - move the original message to a fault Queue - else DONE.

So far this works fine in happy path scenarios - I have a doubt whether it will work when things start go wrong e.g. DB call fails or the intermediate web services (deployed on other hosts) which I use to fetch more data are unavailable or network errors etc. The requirement is 5 retries to send it to point # 4 else move it to designated DLQ for that service (lets say for C goes to C_DLQ). so that I dont lose the original message. I am using jms-jca-provider for gateway in and have mix-n-match transports internally before sending to WS.

Has anybody developed such things before (I am sure many of you must have)? any suggestions on how things can be better?

Thanks

Joe

[cammette]

you cound try these:

1、defined an topic，your three services have an jms-jca-provide gateway ref to the topic queue

2、defined three queue,and redefined their DQL using your fault queue:

  <mbean code="org.jboss.jms.server.destination.QueueService"

    ...

    <attribute name="DLQ">fault queue name</attribute>

  ..

  </mbean>

   hree services  ref to these queue using jms-jca-provide not-gateway transports

[joe_boy12]

that works fine only catch is I need to throw RuntimeException to roll the trx back and which I can do only from my custom action. What I found is "JcaMessageAwareListener" doesnt rollback by default on pipeline faults but "MessageAwareListener" does. so what I had to do is add a catch all Action at the very top - override the processException method and mark the trx rollback only if there is a pipeline fault which moves it to a specified DLQ in activation config. but Activation config has only 5 max resent - so I had to bump it up to whatever number I need - another glitch is if you have maxDelieveryAttempt sepcified in jbm-queue-service.xml on a queue - lesser no wins.