Thursday, September 27, 2012

Lets talk JavaOne

Well, I really have not been keeping up my end of the bargain here.  The only posts I have make this year are to announce conferences I am speaking at.  So in order to not break tradition.... Lets Talk JavaOne :-)



So this year, I have the opportunity to speak on something dear to my heart:  Advanced Enterprise Architectures using Open Source.  Specifically Apache products.  I am speaking on Wednesday, Oct 3rd at 3pm.  Hope to see you all there.

Monday, May 14, 2012

Lets Talk Uberconf

Hi all, back again to pimp myself out.  I will be speak at the ultra-cool, massively hip, new hotness, that is pure awesomeness...... UberConf 2012


I will be speaking on SOA architectures.  Explaining how to take Servicemix, ActiveMQ, Camel and CXF and make them into a high speed, low drag enterprise system.   If you are going to be there, make sure you stop in, I am handing out example code that demos a high available system that you can deploy on a local instance of Servicemix using ActiveMQ as the HA solution!

You will not want to miss this presentation!  Many men have died for this information!

Friday, February 24, 2012

Lets Talk ConFoo

I have the great honor of speaking at:
I am speaking at ConFoo Web Techno Conference. February 29th to March 2nd, 2012. Montreal
I will be speaking on tips and tricks of building a full enterprise solution using open source technologies. In this session attendees will learn about the different levels of concern within SOA and where to implement different frameworks within enterprise architectures. Tips and tricks that can only be learn through the school of hard knocks are presented here to give the attendee a big leap ahead in architected their systems. It will also point out commons trouble spots often encountered in large-scale systems. These are advanced system integration concepts with a focus on high availability using open source frameworks in a service-orientated architecture. It will cover best practice tips for implementing/architecting ESB, mediation router, and messaging in infrastructures needing large scale, high transaction capabilities.

Wednesday, February 1, 2012

Handling ActiveMQ disconnects in Camel CXF Routes Part 2

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.

Thursday, January 5, 2012

Handling ActiveMQ disconnects in Camel CXF Routes

If ActiveMQ is setup with default connection handling using the failover protocol in the camel config xml:

failover:(nio://0.0.0.0:61616,nio://0.0.0.0:61617)

With the normal functionality, this will continue retrying the connection to a point that will probably cause your route to timeout.  So in a Request/Reply scenario (MEP = InOut), you would send an exchange to an activemq endpoint and wait for a reply for the default 20 seconds:

from("cxf:bean:myService").to("activemq:queue:myQueue")

Now if there is no active ActiveMQ instance running and you hit your endpoint with SOAPUI, you will see in the log an ExchangeTimedOutException:

ERROR DefaultErrorHandler:232 - Failed delivery for exchangeId: ID-StoneCold-iMac-local-xxxxxxxx-0-1. Exhausted after delivery attempt: 1 caught: org.apache.camel.ExchangeTimedOutException: The OUT message was not received within: 20000 millis. Exchange[Message: [com.my.request@4f39ec5c]]
org.apache.camel.ExchangeTimedOutException: The OUT message was not received within: 20000 millis. Exchange[Message: [com.my.request@4f39ec5c]]

Now it maybe expected that in Highly Available systems that there is always a passive instance of ActiveMQ waiting to take over and the timeout is set high enough that this error should (theoretically) not happen.  But many people are confused when AMQ is not running and the route still appears to be working without a JMSException being thrown for Connection Refused when ActiveMQ is not available.

But what if you want to handle the connection issue after X number of retries and let the client know there is a problem?

The first thing is to set the parameters on the connection URL so that the URL will define how camel will handle disconnects:

failover:(nio://0.0.0.0:61616,nio://0.0.0.0:61617)?maxReconnectAttempts=3

So above we are telling Camel to try to reconnect 3 times before failing, other parameters can be found here under Transport Options.  So this will allow you to define how camel handles the disconnect when ActiveMQ shutsdown.

Now if you run the route you will see that you get a SOAP Fault returned with a JMSException.

Still not what you are looking for?  So you want to handle the failure with a nice response object with a nice response code instead of an exception?  In order to handle that you need to do exception handling in your route.  There are a couple of different ways to handle exceptions, we will look at the route specific one.  Other info on Exception handling in Camel can be found here.

from("cxf:bean:myService")
    .onException(JMSException.class)
         .maximumRedeliveries(2)
         .process(new Processor() {
                  public void process(Exchange exchange) throws Exception {  
                      MyResponse myResponse = new MyResponse();
                      myResponse.setMyError = "Crap, it didn't work"
                      exchange.getIn().setBody(myResponse);
                    }
               })
   .end()
.to("activemq:queue:myQueue");

Now that you have the exception in place hit the cxf endpoint with SOAPUI and you will see that you still get the JMSException...... WTF!

The reason is the exception is not a handled exception so the exception is passed up the stack and is still getting processed by the service endpoint and sending a SOAP Fault.  So the final exception needs to look like this:

from("cxf:bean:myService")
    .onException(JMSException.class)
         .maximumRedeliveries(2)
         .handled(true)
         .process(new Processor() {
                  public void process(Exchange exchange) throws Exception {  
                      MyResponse myResponse = new MyResponse();
                      myResponse.setMyError = "Crap, it didn't work, but here is a nice message for you"
                      exchange.getIn().setBody(myResponse);
                    }
               })
   .end()
.to("activemq:queue:myQueue");

Notice the onException now has "handled = true" set.  This will pass back whatever you set in your onException route, in this case I am just using a process to create a MyResponse object and set the error message.  Now the client will receive the MyResponse object instead of a soap fault when the connection to ActiveMQ disconnects. 


Wednesday, January 4, 2012

Lets get together

Heath Kesler is proud to announce the official partnership between OpenTek Solutions and Savoirtech.  OpenTek is a services provider for enterprise architectures based on Apache frameworks like:
  • Camel
  • ActiveMQ
  • Servicemix
  • CXF
  • Blueprint
As well as working in other frameworks like:
  • GWT
  • Spring
Heath Kesler is the principal architect at OpenTek and has been involved in enterprise system architectures for many fortune 500 companies. 

The partnership solidifies Savoirtech as a primary service provider for Apache frameworks.