[
https://issues.apache.org/activemq/browse/SM-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38950
]
Dominique De Vito commented on SM-910:
--------------------------------------
I have done a simple test using a seda flow with a JCA consumer.
<sm:flows>
<sm:sedaFlow />
<sm:jcaFlow connectionManager="#connectionManager"
jmsURL="${activemq.url}" />
</sm:flows>
...
<sm:activationSpec componentName="inputReceiver_2">
<sm:component>
<jms:component>
<jms:endpoints>
<jms:endpoint
role="consumer"
endpoint="jmsbeginningpoint_2"
service="foo:myJmsReceiver_2"
connectionFactory="#jmsFactory"
targetService="foo:ws_2"
synchronous="true"
rollbackOnError="true"
defaultMep="http://www.w3.org/2004/08/wsdl/in-only";
processorName="jca"
bootstrapContext="#bootstrapContext"
resourceAdapter="#activemqRA">
<jms:activationSpec>
<amqra:activationSpec destination="queue_2"
destinationType="javax.jms.Queue" />
</jms:activationSpec>
</jms:endpoint>
</jms:endpoints>
</jms:component>
</sm:component>
</sm:activationSpec>
<sm:activationSpec componentName="ws_2">
<sm:component>
<http:component>
<http:endpoints>
<http:endpoint service="foo:ws_2"
endpoint="myProvider"
role="provider"
locationURI="http://localhost:8090/WsListener/index.do";
defaultMep="http://www.w3.org/2004/08/wsdl/in-only";
/>
</http:endpoints>
</http:component>
</sm:component>
</sm:activationSpec>
The test scenario was the following:
(a) using another pipeline, I have pushed a message into the queue_2
(b) I have run the pipeline defined above WITHOUT running the external web
service provider, than I have got plenty of "java.net.ConnectException:
Connection refused: connect".
The traces are full of rollback, no single one commit.
(c) While there was no commit into the traces, and due to
rollbackOnError="true", I was expecting still the message to be into the queue
(called queue_2).
I have re-started ServiceMix and my external web service provider too. I was
expecting ServiceMix to get this message to give it to the external web service
provider now running. But ServiceMix has not treated any message.
I have tested this under servicemix-3.1-incubating et
servicemix-3.2-incubating-20070308.121113-12
While traces include no commit, only rollbacks, I expect the message to be stil
into the queue and ServiceMix to treat it again while restarting. This is not
the case, i.e. when adding synchronous="true" rollbackOnError="true", the
message is rollbacked, but after a few number of attempts, it disappears
somewhere.
Can you tell me what happens ?
Where this message goes ?
Why ServiceMix does not treat it again when restarted ?
Did the message go some component DLQ ?
I have found these traces after the last rollback:
DEBUG - AbstractRegion - Adding destination:
queue://ActiveMQ.DLQ
DEBUG - JournalPersistenceAdapter - Waking for checkpoint to complete.
DEBUG - JournalPersistenceAdapter - Checkpoint started.
DEBUG - JournalPersistenceAdapter - Checkpoint done.
DEBUG - JournalMessageStore - Journalled message add for:
ID:p-105825-1398-1175602237242-3:35:1:1:1, at: 0:10457
DEBUG - DLQ - No subscriptions registered, will not
dispatch message at this time.
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.
