[
https://issues.apache.org/activemq/browse/SM-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38938
]
Dominique De Vito commented on SM-910:
--------------------------------------
OK, thanks, it's clearer.
I was thinking about a pipeline like this one: JMS queue reader (BC
endpoint)=>WS (BC endpoint). If I am using seda flow + transaction, I want that
if the second component fails, the first one should set the transaction to
rollback.
So, I have made a simple test while not running the external WS.
The second component, WS BC endpoint fails to connect to the external WS, but
unfortunately, the initial JMS msg is consumed. I was expecting the initial JMS
msg not to be consumed.
I have imagined the reasons were the following 2 reasons:
(a) the WC BC endpoint does not return any fault
(b) the JMS BC endpoint is not listening any fault (the single Mep authorized
is "in-only").
While coding the patch here attached, I was thinking about tackling (a).
Have you got any idea how and where into the current ServiceMix code I should
take a look to improve it and achieve (a) ?
Thanks.
> better handling of unavailable external http services
> -----------------------------------------------------
>
> Key: SM-910
> URL: https://issues.apache.org/activemq/browse/SM-910
> 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:
> java.net.ConnectException: Connection refused: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:516)
> at java.net.Socket.connect(Socket.java:466)
> at java.net.Socket.<init>(Socket.java:366)
> at java.net.Socket.<init>(Socket.java:239)
> at
> org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:79)
> at
> org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:121)
> at
> org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:706)
> at
> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1321)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
> at
> org.apache.servicemix.http.processors.ProviderProcessor.process(ProviderProcessor.java:168)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:489)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:441)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:593)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> 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.
