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/
