Enterprise Integration Zone is brought to you in partnership with:

Heath Kesler is an open source software evangelist, developer and architect; he has created Java architectures for large scalable, high transaction load systems for such companies as Health Language, LeapFrog Enterprises, Verizon, GE-Energy, Comcast, and IBM. Heath has been a team lead in many project recovery implementations, helping to rescue systems on the verge of collapse. He has been involved with the architecture and implementation of large-scale enterprise systems throughout the world. He conducts trainings on how to use open source frameworks to integrate messaging and services. Heath is a DZone MVB and is not an employee of DZone and has posted 2 posts at DZone. You can read more from them at their website. View Full User Profile

Handling ActiveMQ disconnects in Camel CXF Routes: Part 2

06.08.2012
| 4447 views |
  • submit to reddit
So previously I showed you how to setup error handling when working with Activemq from a CXF endpoint.  So that is fine, but what if you need ActiveMQ to be asynchronous?  CXF will define the route as synchronous, meaning ExchangePattern = InOut.  This will force the route to be synchronous, and therefore wait on a reply from the queue..... much like I spelled out in part 1.

But what if we need ActiveMQ to be asynchronous?  Seems easy, just change the exchange pattern to be InOnly for the ActiveMQ call like so:
.inOnly("activemq:queue.test")
So now your route returns much faster since it is not waiting on a reply from the ActiveMQ endpoint.  Cue the angels.......  but wait, what happens when we still need the error handling to catch the JMSException and return a predefined response if..... lets say.... ActiveMQ is down? 

With the ExchangePattern set to InOnly, you will see in SOAPUI that you just get an empty soap message.  So what happened to the predefined response?  If you have logging in you processor or bean that loads the response, you will see that it is still hitting your code, but it is not return the response for some reason.

THE REASON:
The reason is you have an ExchangePattern of InOnly set when you run the onException code, this is causing the camel route to return before your processor is finished processing.  So your exception processing does not effect the return to the CXF endpoint.

THE SOLUTION: you need to specify the onException portion of your route to be InOut using the following:
.onException(Exception.class).handle(true).setExchangePattern(ExchangePattern.InOut).processRef(myProcessor)
Now you should see your processor defined response from the onException getting passed back to the endpoint.
Published at DZone with permission of Heath Kesler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Fahmeed Nawaz replied on Tue, 2012/06/12 - 10:37am

>Note: The Mongo object instance actually represents a pool of connections to the database; you will only need one object of class Mongo even with multiple 
>threads. See the concurrency doc page for more information.

Does this apply to the DB class also ? Collection objects? Can I keep one instantiated db object and use from all my threads ?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.