Re: What exactly happens, if a service call to an external resource fails

[Gert Vanthienen <ge...@gmail.com>]

Stefan,

These kind of problems will usually lead to a MessageExchange that
ends in Error of with a Fault.  In your case, the eip:content-enricher
will send an InOut MessageExchange to the HTTP enricher service.  It
that fails, the error message will go back to the content-enricher
that will send it back to whatever endpoint it received its exchange
from.  At that point, it all depends on the sending endpoint.  As an
example: the file:poller endpoint should not delete the file if the
MessageExchange has ended in error, so it will just be picked up from
the same location in the next run of the poller.  The problem you are
facing is that the quartz endpoint probably doesn't support this kind
of behavior (yet).

One solution could be to add an intermediate JMS queue with a
<jms:producer>/<jms:consumer> pair.  This way, every quartz message
will be send to the queue and it will only be removed from the queue
if the call to the target service succeeds.  If you want a more
fine-grained control over this error handling, I suggest you take a
look at servicemix-camel.  Camel isn't just a replacement for
servicemix-eip, it also has more extensive support for declaring error
handling strategies (cfr.
http://camel.apache.org/error-handling-in-camel.html): you could e.g.
use a deadletter channel, specify retry counts or specify specific
error handling mechanisms based on the Exception you're seeing.

Regards,

Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



2009/1/31 Stefan Zoerner <st...@labeo.de>:
> Hi all,
>
> let me first say that I really like ServiceMix. I was able to deploy a flow
> which contains file input, mail output, transformation etc. quickly.
>
> Now I am digging a little deeper and try to find out what happens, if a
> resource (for instance a Web service) is not temporarily available for
> ServiceMix.
>
> My example enriches a message created by quartz with the help of
> eip:content-enricher (exchange-target is a REST call against an HTTP
> server). Works fine.
>
> If the REST Servive is not available, the messages will not be proceed
> (makes sense). Is the message still stored in any queue?
>
> If I make the HTTP Service available again, my example runs, but the old
> messages seem to be lost.
>
> Would do I have to do to make the example more reliant. I thought about
> adding a queue explicitly in the flow which stores the messages in the
> meantime ...
>
> Thanks in advance for some hints,
>    Stefan
>
>

Re: What exactly happens, if a service call to an external resource fails

[Stefan Zoerner <st...@labeo.de>]

Hello Gert,

thank you for taking the time and explaining it informative and in such 
detail. Things are much clearer now, and I even have ideas where to go next!

Greetings from Hamburg,
     Stefan

Gert Vanthienen wrote:
> These kind of problems will usually lead to a MessageExchange that
> ends in Error of with a Fault.  In your case, the eip:content-enricher
> will send an InOut MessageExchange to the HTTP enricher service.  It
> that fails, the error message will go back to the content-enricher
> that will send it back to whatever endpoint it received its exchange
> from.  At that point, it all depends on the sending endpoint.  As an
> example: the file:poller endpoint should not delete the file if the
> MessageExchange has ended in error, so it will just be picked up from
> the same location in the next run of the poller.  The problem you are
> facing is that the quartz endpoint probably doesn't support this kind
> of behavior (yet).
> 
> One solution could be to add an intermediate JMS queue with a
> <jms:producer>/<jms:consumer> pair.  This way, every quartz message
> will be send to the queue and it will only be removed from the queue
> if the call to the target service succeeds.  If you want a more
> fine-grained control over this error handling, I suggest you take a
> look at servicemix-camel.  Camel isn't just a replacement for
> servicemix-eip, it also has more extensive support for declaring error
> handling strategies (cfr.
> http://camel.apache.org/error-handling-in-camel.html): you could e.g.
> use a deadletter channel, specify retry counts or specify specific
> error handling mechanisms based on the Exception you're seeing.
> 
> Regards,
> 
> Gert Vanthienen
> ------------------------
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>