servicemix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique De Vito (JIRA)" <>
Subject [jira] Commented: (SM-910) better handling of unavailable external http services
Date Fri, 06 Apr 2007 09:29:34 GMT


Dominique De Vito commented on SM-910:

It looks like ServiceMix is doing fine, without error, but not like I was expecting.

At the end, after a number of retries, ServiceMix (or ActiveMQ) puts the msg into a DLQ (Dead
Letter Queue). The pb is: I can't see this JMS DLQ queue through jconsole and I can't find
how to define myself the dlq destination. 

I want to be able to define myself the instruction flow in case of error. I see the following

(1) extend the JMS component to be able to define a "erroneousTargetService" attribute like


In case of error, the JMS consumer would try first (a) to follow the "erroneousTargetService"
way, and if this way fails too, it will (b) rollback at the end, just as today.

(2) let's define a try-catch component. In case of ERROR, this component would go to the "catch"
path for continuing the execution.

(3) let's see into internal ActiveMQ (or ServiceMix) configuration to know how to parametrize
as I want the DLQ.

Which solution do you think is more in spirit of ServiceMix ?

Have you got any advice about the best solution among the three above I may implement ?


> better handling of unavailable external http services
> -----------------------------------------------------
>                 Key: SM-910
>                 URL:
>             Project: ServiceMix
>          Issue Type: Improvement
>          Components: servicemix-http
>    Affects Versions: 3.1
>            Reporter: Dominique De Vito
>             Fix For: 3.1.1
>         Attachments: patchfile.txt
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
> The org.apache.servicemix.http.processors.ProviderProcessor calls an external http service.
> When calling an unavailable external http service, the following stack trace appears
after an exception rise:
> Connection refused: connect
>         at Method)
>         at
>         at
>         at
>         at
>         at
>         at
>         at<init>(
>         at<init>(
>         at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(
>         at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(
>         at
>         at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$
>         at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(
>         at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(
>         at org.apache.commons.httpclient.HttpClient.executeMethod(
>         at org.apache.commons.httpclient.HttpClient.executeMethod(
>         at org.apache.servicemix.http.processors.ProviderProcessor.process(
>         at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(
>         at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(
>         at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(
>         at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(
>         at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(
>         at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(
>         at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$
>         at$Worker.runTask(
>         at$
>         at
> I think handling could be improved in case of (exchange instanceof InOnly == false),
so that a response could be returned. 
> See the attached patch.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message