On Tue, Dec 13, 2011 at 7:11 PM, Jason Dillon <ja...@planet57.com> wrote: > Is there a better place to ask this question? >
The mailing list is usually a good place. But sometime people is busy, and they may only respond on the easier kind of mails. There is also alternative sites such as forums from commercial vendors support Camel, Stackoverflow, etc. I personally usually keep mails around I haven't had the time to look into, and help out with. This mail was such a mail. I am busy focusing on the Camel 2.9 release, as well preparing for a webinar tomorrow, and working for FuseSource in general, and helping our clients, etc. > --jason > > > On Dec 7, 2011, at 3:11 PM, Jason Dillon wrote: > >> I'm wondering what (if any) is the camel way to cope w/and handle exceptions >> which are internal to and endpoint (not for those which occur while >> processing exchanges with an endpoint). >> >> For example if I setup a JMS component (simple container, w/retry connect >> enabled), when the route is started and the remote is up, then the route >> starts and everything looks happy. But sometime after that the remote >> connection is lost and its not a simple brief/transient network failure >> (lets say the machine exploded, or maybe nicer that the network cable was >> unplugged). The JMS endpoint using the Simple container will attempt to >> recovery, quickly fail, and then end up in limbo. >> >> It doesn't look like this state alters the state of the route and no >> exchanges w/error details are exposed to process. I was able to hook up >> exception listeners and error handlers onto the JMS component configuration >> and they are called. >> >> My question here is really how to generally cope with endpoint failures in >> "the camel way". >> >> In this case, I'm using a route from a JMS broker to consuming messages >> only, so I'd really never know by use of an errorHandler() or onException() >> that anything bad happened at all. I'm guessing that since the route did >> start that the dsl configured error bits might have been invoked if an >> exchange was attempted to send a message though this failed JMS endpoint? >> >> For this specific use of the (stock) JMS component I'm starting the route >> separate from adding it, and I think in this error case I really want to >> stop the route for it, then retry starting it again and/or potentially >> selecting an alternate JMS endpoint configuration for the component. Is the >> best way ASIS to hook up an "exceptionListener" &| "errorHander" to the >> component when configured and the basically initiate restarting/configuring >> the route from there? >> >> Is there a better way to cope with this type of failure in Camel? >> >> Thanks, >> >> --jason > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
