[
https://issues.apache.org/activemq/browse/SM-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48589#action_48589
]
Guillaume Nodet commented on SM-1667:
-------------------------------------
ServiceMix 4 allows to use transactions with asynchronous sends to allow better
scalability. This is not the case in ServiceMix 3, and it did make things a
lot more complicated, because the transactions semantics were different if you
were using send or sendSync. Also, components may use sendSync even if the
exchange is not transacted (this was the case for the file poller until
recently and also for cxf bc).
So I really don't think what you suggest is the right approach.
Each component should be able to use either send or sendSync without knowing if
the previous or next component also use send or sendSync, which means the
behavior has to be the same in both cases, else components would quickly become
unable to work together.
I think your use case shows up because you want to "intercept" the error and
retry the exchange, but I do think that in such cases, you really need to
intercept the exchange and not let it be propagated back to the consumer
endpoint. If the consumer has anything to do when the exchange comes back, it
will be totally screwed up, because this processing will actually occur before
the remaining of the flow is fully processed. Also, if I reuse the file poller
example, your retry strategy may only retry for a limited number of times, and
if it still fails, propagate the error back to the consumer.
I guess the problem you hit is that ServiceMix 3 exchange listeners do not
really allow to "pause" the exchange and not deliver it to the consumer
immediately. However, this could be done using a custom flow wrapping one of
the existing flow.
In your example using a bpel process, i don't really see the point. If the
bpel process sends an InOnly exchange, using your retry strategy, the bpel
process would always receive a DONE status and no error could be thrown inside
the process, so no compensation at all. Components have to be able to make the
difference between a sucess and a failure for a given exchange.
Anyway, I'm a bit lost in what you are suggesting ? Are you suggesting that
when using an InOnly mep sent asychronously, there should be no DONE nor ERROR
status at all ? This would really be against the spec and would lead to the
impossibility of using streams to transfer large amounts of data for example.
> TransformBeanSupport does not correctly report errors for in-only exchanges
> ---------------------------------------------------------------------------
>
> Key: SM-1667
> URL: https://issues.apache.org/activemq/browse/SM-1667
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-bean
> Affects Versions: servicemix-bean-2008.01
> Reporter: Ron Gavlin
> Assignee: Guillaume Nodet
> Priority: Critical
> Fix For: servicemix-bean-2008.02, 3.2.4
>
> Attachments: sm-1667-inout-regression.patch
>
>
> The smx-bean TransformBeanSupport class does not correctly report errors for
> in-only exchanges. If the target exchange status is ERROR, the source
> exchange status is still returned as DONE. This should be fixed for both sync
> and async use cases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
