Hi Ryan, It seems to be that you'd be better off breaking up some of those routes; they seem very large and monolithic. Prefer composed routes instead, each with discrete error handlers. Currently you're looking for a fault through a large slice of functionality. The use of the doCatch clauses is alluding to the fact that these routes need to be broken up. With a larger number of smaller composed routes it will bring greater focus to your error detection/handling. Same concept behind keeping regular method sizes small.
Can you explain why some of the individual processor nodes in each route have processing times in the order of an hour or more!? Also, give each node in the processing chain of a route a discrete ID. Makes it a lot easier to map, rather than figuring out what 'choice43' is! How are you testing these routes? What unit tests do you have for these routes? Thanks, Paul On Thu, Apr 27, 2017 at 1:59 PM, Ryan T <[email protected]> wrote: > That would be ideal, but I it is really hard to reproduce. Out of say > 60000 > records processed. I "sometimes" get the timeout. Everytime I run it in > my > local dev environment it seems to succeed. When it does fail in my dev > environment, I usually have to add more logging as I learn more. I'm > basically trying to prove that it is a network or connectivity issue and > eliminate the code as the problem, but if I cannot pin point the exact node > there is the doubt that it could be happening in the serializer or a > database call to mongo or in the cxf code that does the rest call. My gut > says that it is a connectivity issue, but how do you explain to management > that the problem is between Amazon, and Verizon, Kore(T-Mobile), or ATT. > They are more inclined to say it is the code base. Because of this being > more reproducible in a production environment, it makes it really hard to > just start removing node to find the problem. It is however an interesting > thought and I will look into maybe making a pseudo route that can mimic > pieces in the route, specifically the places I think it might be happening. > > On a side note: I forgot to give you the actual exception in the log as > part of the log post message to this board. Included below: > > > > > > -- > View this message in context: http://camel.465427.n5.nabble. > com/Help-diagnosing-camel-exception-tp5796669p5798428.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
