I have an Apache Camel route which handles messages from a queue. To better understand what is happening at runtime I also keep the execution state in a database (number of retries, last execution state,...). I would like to use the redelivery mechanism from the exception handler but which performs some processing on every failure to update my database record.
from("jms:myinputqueue")
.onException(RetriableException.class)
.maximumRedeliveries(5)
.maximumRedeliveryDelay(10000)
.useOriginalMessage()
.to("log:store error information in database about each attempt") // (1)
.end() // onException
.to("log:apply business logic here which can throw exceptions")
;
The part (1) is only executed after all retries are exhausted, so only once.
I've read Apache Camel- Message Redelivery happens before onexception block executes but the suggested solution ''onRedelivery'' is executed before the beginning of a new retry. I need to store the result on each failure so I can save the last state (error message) in the database.
Any suggestions ?
There is an onExceptionOccurred processor you can use that is called when the exception happened.
Its included in Camel 2.17 onwards: https://issues.apache.org/jira/browse/CAMEL-9069
Related
What does 'segment' and 'progress' mean in that kind of exception
2) xlang/s engine event log entry: Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'MainEventProcess.MainEvent(5b530a24-7336-4695-78ee-1d4ffdd9f210)'.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: cf584087-a9d3-4be7-8da7-eae49fd4a108
Shape name: SendDeviationOut
ShapeId: dc5c3484-7955-4d75-b1f9-7e0ca8ecbc1e
Exception thrown from: segment 4, progress 8
Inner exception: Exception occurred when persisting state to the database.
Full details hereon MSDN:
Exception during execution of Orchestration
Can it be helpful in searching errors in code?
First, it's nothing you need to worry about and is not related to your app/code/implementation.
The two items you need to act on are SendDeviationOut and Exception occurred when persisting state to the database. You are most likely publishing a message and there are no Subscribers. This is the "no Subscribers found" error from the Orchestration engine.
Now, to answer your specific question, those are markers to blocks of C# code that XLang compiler generated from your Orchestration. Basically, every statement is organized into a group, segment, and each is executed and tracked individually, progress. If you open the File0.cs, you will see this in action.
I have a problem with the design of mysql client library.
MySQL requires that each thread that uses the MySQL API first call mysql_thread_init()
and at the end call
mysql_thread_end().
If the thread fails to call
mysql_thread_end(),
then MySQL will block the main thread at program termination and wait for this threads to call
mysql_thread_end().
If that doesn't happen, then it prints an error message to STDERR. Not a very user-friendly behavior.
now the problem is that i m inside an ISAPI dll, it's not me who create the thread (nor destructing it), it's IIS that manage it.
How can i be warned then the thread will end to call mysql_thread_end ?
I am wondering how I can tell camel to redeliver my message based on business logic.
My route is calling a soap endpoint and, depending on the message returned by the server I need to schedule a retry in a few seconds.
Basically, I have this kind of error handling configured :
onException(Throwable.class)
.handled(true)
.processRef("exceptionHandler")
.redeliveryDelay(5000)
.maximumRedeliveries(1)
.to("file://
My exceptionHandler check if the exception is a SOAP Fault, unmarshal it and depending on the content I need to schedule the retry.
Is there anyway of doing that within camel ?
Well, in the end, here is my solution :
from("...")
.doTry()
.to("...")
.doCatch(Exception.class)
.beanRef("handleException")
.end()
.beanRef("handleRegularResponse");
The processor handleException handles the exception, try to understand the issue and then throw a more precise exception. In my case, it can throw 2 types of exception : FunctionalException that do not need to redeliver, and a TechnicalException that I will try to redeliver in a few minutes.
I just have then to declare an error handler for this specific exception :
onException(TechnicalException.class)
.handled(true)
.redeliveryPolicyRef("...")
.useOriginalMessage();
HIH
I have a windows service, in which I want a top level try-catch that catches any otherwise unhandled (or bubbled) exception, logs it to the Event Log and then swallows it so the service keeps running. However, I can't find any overload to System.Diagnostics.EventLog.WriteEntry that takes an exception as a parameter - is there no way to just give the event log the exception and let it parse out the message on its own?
Unfortunately there is no standard way of just passing the Exception to the Eventlog, built in to the .NET framework.
To have an exception written to the EventLog with the smallest development effort, you would need to write something like:
EventLog myLog = new EventLog();
myLog.Source = "Your Source";
myLog.WriteEntry(exception.ToString(), EventLogEntryType.Error);
But normally you would try to do some formatting of your exception.
Does throwing an exception in a windows service crash the service?
i.e. it will have to be restarted manually
Note:
I am throwing the exception from within the catch clause.
Not strictly so -- it'd only cause problems if the exception is unhandled.
If the exception is uncaught and bubbles back up to the OnStart() method it will crash the service. You will typically see a message in the Windows Event Log similar to the following:
"The MyServiceName Service service terminated unexpectedly. It has done this x time(s).
If you're throwing the exception in Catch, and there's nothing above it to recatch it, then that will cause your service to stop. The OnStart() method needs a try/catch. If you don't want to stop the service when an Exception occurs, then you need to handle it (log it and move on, or whatever).
My preference woudld be to handle expected exceptions, and to have unexpected exceptions either cause the service to stop, or at least stop/restart automatically. If something unexpected happens your service will be running in an unknown state, and who knows what it will do.
We ran into the problem of an untrapped exception on a child thread causing the service to stop without providing any information about what was causing the exception. We used this method to find out the source of the exception.
You can put a Handler to the service to catch all unhandled exceptions (including all sub threads of the service). In VB.NET, you will need to add a handler for AppDomain.CurrentDomain.UnhandledException. It is likely similar in C#. It will then catch anything that does bubble up past your onStart. You can choose to consume it there or allow it to crash the service from there.