[
https://issues.apache.org/activemq/browse/SM-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48597#action_48597
]
Guillaume Nodet commented on SM-1667:
-------------------------------------
I now clearly see your point. But imho, you are mixing the MEP with the sync /
sendSync, which is also related to mixing faults with errors.
Let's clearly state again: using sendSync or send should not change the
semantic of the exchange. The semantic of the exchange is defined by its MEP.
So now, back to your example. Let's say we have an external client which sends
a request on some protocol and does not expect a fault to come back. This does
not necesseraly mean it won't have any error status reported back: I don't know
any protocol that can not fail at some point: an HTTP server can be down, a JMS
broker can be down, a database can be down a hard drive can be full or with
incorrect permissions. So even if we were not using an ESB, the underlying
protocol can still fail at some point.
Anyway, if the client does not expect any response, this means the BC will
create an InOnly exchange. It's up to the BC to inform the client that the
request has been accepted or not (if it makes sense at all, for example if we
were using HTTP). If the client expects a response, an InOut exchange will be
created.
Now, when the InOnly request is received by the BC, it has the choice of using
sendSync or send to send the JBI exchange. I guess if you say the client can
be blocked, you're kinda implying HTTP, because file, jms or email are pure
asynchonous protocols. The BC does not necesseraly have to wait for the
exchange to come back to send the HTTP status back to the consumer. It could
even just read the request, send the HTTP response, and only send the JBI
exchange after that, though this is now has the servicemix-http component is
implemented. In both cases, it could use either send or sendSync and the
behavior should be the same.
So I don't really think this is a matter of using send / sendSync in the NMR,
it's more a problem of the BC and its protocol.
I already have the need to implement an InOnly http request, where the exchange
needs to be reliably processed. The best way atm is to put a pair of JMS
endpoints (provider / consumer) just after the HTTP endpoint. When an HTTP
request is received, an InOnly exchange is created and sent to the jms
provider. As soon as the JMS provider has sent the JMS message, the DONE /
ERROR status is sent back to the HTTP consumer which sends a 202 / 500 http
status code. The client knows if the request has been accepted very soon
without waiting for the request to be fully processed. However, it also knows
if the request has been rejected for some reason. At a later time, the JMS
consumer will consume the JMS message and the request will be processed. At
this point, the JMS layer will also provide redelivery if the processing failed.
Now, let's say we are already inside the bus. An endpoint receives an InOnly
exchange, creates a new InOnly exchange, maybe doing some small transformation
of the message and send it. If it does not want to want the DONE/ERROR status
to come back before sending the DONE status for the exchange it received, it is
free to do so. However, it needs to make sure that the message does not
contain any stream which could be closed by the endpoint that has send that
exchange, before the next endpoint has processed the stream (if you use
servicemix-http, you may have noticed that the http request input stream is
directly set as the content of the exchange). Anyway, the endpoint is free to
send a DONE status before the new exchange has been processed. This would lead
to the error being completely lost if you don't have any enhanced retry
strategy somewhere.
For example, the eip static recipient list supports both modes. It receives an
InOnly exchange and will send a copy of it to several recipients. In
asynchronous mode (which is the case unless the exchange is transacted, so
forget about transaction), it will send all copies asynchronously then send a
DONE status. If the reportErrors flag is set, it will wait for all exchanges
to come back to report any error on those or send the DONE status.
So, I think your suggestion would be a real pain in the case there is no retry
strategy: all errors would quickly be lost and noone would have any way to know
what really happens. If I may also use your BPEL compensation example,
compensations can be quite difficult to write and won't always be handled by a
simple retry strategy.
Let's say you have to complex processes. The first one does some action, call
the second process, and may need to compensate any problem if the second
process failed. The second process may also involve several steps. With the
retry strategy, you may want to retry a few times, and then ? if you never
propagate an error back, how would the process compensate the error ? I think
the retry strategy should act as an interceptor, retry a few times, and then
send back the error. The problem you stated with the client is kinda specific
to servicemix-http, not to an error handling mechanism imho (and it should be
possible to add a flag to change this behavior on the BC so that it would just
read the request, send a 200 http response, then generate the exchange and sent
it).
Not reporting back errors makes sense in the context of Spagic, where all
exchanges are stored in a DB for audit, along with the retry strategy. For
plain servicemix, it would just mean that you loose all informations when an
error occurs.
> 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.
