Hi Ryan I agree with Paul. It is quit hard to troubleshoot those complicated routes. It would be easier if you can break them into smaller and more independent routes which can be tested easier.
I would also enable this class which is the AuditEventNotifier which will give more detailed information about each step that is being executed. http://camel.apache.org/eventnotifier-to-log-details-about-all-sent-exchanges.html Essentially I think a call to MongoDB or some other third party system is taking more than the allowed timeout value. Either increase the timeout and see if the problem goes away or perhaps it could be worth run some sort of a load test using JMeter to trigger those timeouts and then see exactly which record is causing this happen. Best Souciance <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virusfritt. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Thu, Apr 27, 2017 at 8:23 PM, Paul Gale [via Camel] < [email protected]> wrote: > 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 <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5798429&i=0>> 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. > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://camel.465427.n5.nabble.com/Help-diagnosing-camel- > exception-tp5796669p5798429.html > To start a new topic under Camel - Users, email ml+s465427n465428h31@n5. > nabble.com > To unsubscribe from Camel - Users, click here > <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=465428&code=c291Y2lhbmNlLmVxZGFtLnJhc2h0aUBnbWFpbC5jb218NDY1NDI4fDE1MzI5MTE2NTY=> > . > NAML > <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://camel.465427.n5.nabble.com/Help-diagnosing-camel-exception-tp5796669p5798436.html Sent from the Camel - Users mailing list archive at Nabble.com.
