U.S. Tech Blog ...

It has been a while since i blogged :)...In this article i thought of explaining how to configure WSO2 ESB to enable simple message redelivery.  Way we do that is through ESB endpoints more specifically through a  failover endpoint. Reason i thought of coming up with this topic was the simple fact that, there are several mechanisms to do this kind of thing and enforce different levels of reliability through WSO2 ESB. And many a times users would go for advanced options not knowing that there are simpler ways to achieve what is relevant for their setup or the environment.

Let's define the following simple configuration in the ESB with a failover endpoint .Please note we are connecting to a sample Axis2 Server as the backend service. This is shipped with WSO2 ESB by default. please refer to (http://wso2.org/project/esb/java/4.0.0/docs/samples_setup_guide.html#Starting) for more information on how to set that up.

<proxy name="StockQuoteProxy" transports="https http" startOnLoad="true" trace="disable">
        <target endpoint="RetryEndpoint">
            <inSequence>
                   <log level="full"/>
            </inSequence>
            <outSequence>
                <send/>
            </outSequence>
        </target>
           <publishWSDL uri="file:repository/samples/resources/proxy/sample_proxy_1.wsdl"/>
    </proxy>
    <endpoint name="RetryEndpoint">
        <failover>
            <endpoint name="StockQuote">
                   <address uri="http://localhost:9000/services/SimpleStockQuoteService">
                    <suspendOnFailure>
                           <errorCodes>-1</errorCodes>
                        <progressionFactor>1.0</progressionFactor>
                    </suspendOnFailure>
                </address>
               </endpoint>
        </failover>
    </endpoint>

Try sending the message to StockQuoteProxy. You can use our default axis2 Client (http://wso2.org/project/esb/java/4.0.0/docs/samples_setup_guide.html#Using) to do that...

ant stockquote -Daddurl=http://localhost:8280/services/StockQuoteProxy

You'll get a response back as usual..Now let's make the back-end service(ie:- http://localhost:9000/services/SimpleStockQuoteService)   temporarily unavailable and try to send the message again.

This time you'll notice through the console , that ESB is trying to re-attempt the message delivery . So now if you were able to make the endpoint available again you would see the response coming back to the client (of course if the client does NOT time out).. This way we can enable a simple retry-re-delivery mechanism through failover endpoints.

Failover endpoints usually fallback to the endpoint that is not in a suspended state. However since we have NOT specified multiple endpoints to fail-over , trick is making the child endpoint active at all times. We do that by specifying errorCodes -1 == > make endpoint suspend to NO error code
ie:-

<suspendOnFailure>
  <errorCodes>-1</errorCodes>
  <progressionFactor>1.0</progressionFactor>
</suspendOnFailure> 

However this may not be desirable for some scenarios. There may be some critical errors (ie:- connection errors which may last for some time such as  i/o or network errors) that you know you would not want ESB to waste time and resources , on redelivery. In that case you can define an error code/s that endpoint would really get suspended on and actually suspend for a time window, until the endpoint could probably recover..

<suspendOnFailure>
  <!-suspend for an I/O failure->
  <errorCodes>101000</errorCodes>
  <progressionFactor>1.0</progressionFactor>
  <!-here suspend for 100 sec->
  <initialDuration>100000</initialDuration>
</suspendOnFailure> 

So here is the gist of what i have been trying to convey, -> If you encounter a scenario where you want to have simple redelivery on , you can opt for a failover endpoint setup though ESB. These are cases such as back end services may be unavailable for a very short period of time or you don't really want to configure transactional flows that will complicate the existing configurations,etc. For other scenarios again , ESB has many useful components that will ensure reliable delivery, transactions and QoS. JMS based transactions, Message stores and processors and dead letter channels , WS-RM through ESB are to name a few....

Lot of Application servers or containers deploy different mechanisms for runtime loading of classes and libraries...Understanding these mechanics is really important for resolving conflicts in Enterprise Applications and Runtime environments (ie:-J2EE envs , OSGi containers running on top of App servers ,etc)...Most of the modern Application containers deploy a method called "Bootstrapping" to isolate container specific and application specific runtime dependencies..What "Bootstrapping" effectively does is provide an "unpolluted" classpath for application modules so that they can work independently from container classpath , avoiding any conflicts which other wise would have occurred..(conflicts in the sense unresolved Classes, Class Cast exceptions ,unexpected initialization of code ie:- static initializers , etc )...This means that with "Bootsrapping" an application module can run a different version of a dependent library/class from a version that container depends on without affecting each other...To understand "Bootsrapping" one needs to have a good overall view on java class loading mechanisms..I came across the following article that nicely explains these concepts with several practical runtime deployment perspectives.. http://www.theserverside.com/news/1364680/Understanding-J2EE-Application-Server-ClassLoading-Architectures .. hope this would be useful for those who are interested.....

i found it very annoying to use a touchpad in Ubuntu specially when typing...To add to the trouble my laptop does not have a manual turnoff switch for touchpads.....i came across the following post which describes how to disable Synaptic touchpad with a GUI interface..

If you are too lazy to remember and run 'gpointing-device-settings' in terminal , add command into the Applications submenu by --> (right click) Applications --> Edit Menus --> New Item


Update :------------------------------------------------------------------------------------ although at first 'gpointing-device-settings' looked great , it had certain limitations(ie:- timeouts can't be set,configuration issues)..therefore i had to go for a more crude method..
use 'xinput' to find device id for your touch pad..
$xinput list
mine was 13 (ie:-AlpsPS/2 ALPS GlidePoint id=13 [slave pointer (2)). I used this id to disable touchpad using
$xinput set-prop 13 --type=int --format=8 "Device Enabled" 0

Use System --> Preferences --> Startup Applications to add a startup script if you want to disable your touchpad from start :)