I have a default catch exception strategy for my entire flow/subflows. However, I'd like to be able to tell what component/endpoint threw an exception so I can try to restart the flow at that point (I have yet to figure out how to do that as well.)
Is there any easy way to tell what component/endpoint threw the exception, and be able to tell if it was in a foreach, and at what point (by looking at the "counter" variable.)
Thanks!
You can set a variable at the start of flow like this:
<set-variable variableName="flowName" value="Your_flow_name"/>
And the get the flow name like #[flowName] in your exception strategy.
EDIT:
To trigger a flow, create a java component implementing Callable interface, from the context get the MuleClient and use send or dispatch method to send payload to flow. Send causes MuleClient to wait for response while dispatch doesn't.
More info here: http://www.mulesoft.org/documentation/display/current/Using+the+Mule+Client
Related
We're using Dropwizard as a platform for our REST service and make use of its exception mappers to deal with any exceptions thrown during the user journey. We're using google guice for dependency injection.
In one of our use cases, when an exception is thrown, we need to attach some extra information to the response that is not available at the point where exception is thrown.
The following flow diagram highlights the use case.
Object A -> Object b -> Object C
Object A has the main input available which has the extra information and Object C is where the exception is thrown. Also, Object C is an adapter that talks to an external system and at the moment we don't have the option to carry our input from Object A through C.
When exception is thrown, the thread goes into an exception mapper from where the Response is returned.
Is there a way to make the input available in the exception mapper via some dropwizard/jersey/guice annotation magic ?
I've been able to do this by defining a RequestScoped (#RequestScoped) bean that can hold intermediary result and then injecting it into the dropwizard exception mapper using #Inject. Google Guice magic.
How does the exception strategy works in mulesoft when we have a flow having its own exception strategy calling another flow with its exception strategy. What will happen if an exception occurs in the called flow.
The called flow will throw the exception and the exception strategy of the called flow will be executed.
the calling flow wont throw an exception until its expecting something from the called flow and the called flow is not returning that.
Refer to this link Mule_Exception for further detailed information.
If the exception occurs in the called flow,The exception strategy of the called flow will get execute and control pass to calling flow to execute next message processor.
Regards,
Purnachandra
I am currently using doTry/doCatch blocks in my routes due to which I cannot use a global onException block.
However, I want to perform some business logic if camel route ever breaks (because of bad code or unexpected/untested scenarios). This will hopefully never happen, but I still want to handle for worse case.
I cannot have a java.lang.Exception in global onException block, also, I don't want to put an addition catch on every route.
Is there a specific method Camel calls before throwing uncaught exceptions and breaking route.
I see following log for Uncaught Exceptions:
2015-04-20 15:11:35,279 [Camel (fulfillmentOrderProcessor) thread #5 - seda://FulfillmentSedaQueue] WARN o.a.c.component.aws.sqs.SqsConsumer [, ID-ip-10-180-252-213-54360-1429566855015-0-144]: Exchange failed, so rolling back message status: Exchange[Message: {... }]
java.lang.IllegalArgumentException: Unable to parse string argument null
I looked at UnitOfWork.afterprocess. But this will not help as exchange will have exception even if I have handled it in camel route.
by default, Camel will propagate the exception back to the caller, so you can catch the exception in whatever client code invokes the seda://FulfillmentSedaQueue route...
otherwise, the options on the server side (as you mentioned) are to use a global onException clause or route specific doTry/doCatch statements
I am currently using Esper within a Storm topology and I am aware that there is a method callback called update() that is called when Esper produces a result.
I have been wondering what would happen if there is an error within the Esper engine itself.
Is there an error callback that I can override and catch the Exception?
Or is my best bet to simply wrap the sendEvent() call in a try-catch and then deal with the Exception accordingly?
After further reading I can see that Esper has the notion of Exception Handling:
http://esper.codehaus.org/esper-4.2.0/doc/reference/en/html/configuration.html#config-engine-exceptionhandling
This should satisfy my use case and catch any internal Esper exceptions.
Yes, Esper provides a way for Exception Handling.
You may register one or more exception handlers for the engine to invoke in the case it encounters an exception processing a continuously-executing statement
You can register ExceptionHandlerFactory like below.
Configuration config = new Configuration();
config.getEngineDefaults().getExceptionHandling().addClass(MyCEPEngineExceptionHandlerFactory.class);
You should give the full-qualified class name of each class that implements the com.espertech.esper.client.hook.ExceptionHandlerFactory interface in the engine defaults configuration.
For more details, please read the documentation.
.
in my application (using spring),
i try to call a method from view using spring exposingBean. and when i try to invoke a method from view, it throw error. i try to catch with HandlerExceptionResolver, but no luck, i think it cannot handled by HandlerExceptionResolver because exception wasn't thrown to controller.
so i try another way to redirect the request when exception thrown. and i think aspect has possibility to do it. is it possible to redirected request when exception thrown from aspect?
As you rightly say, HandlerExceptionResolver will not be invoked when an exception is thrown from inside the view. These resolvers are very specifically targetted at controller exceptions.
Your best options here are to use either a HandlerInterceptor and override the afterCompletion method, which will contain the exception thrown by the view. You may be able to send a redirect from here, dependning on whether or not the response has already been committed by the view.
I don't see how aspects would help you here, either. Not the tool for this job.
However, my advice to you is to stop using exposed bean in your JSP. I realise that it's temptingly convenient, but this is the sort of trouble you get from using it. I advise that your controller assemble all the data required by the view, stick it in the model, and send it to the view. That way, there's less danger of the view triggering an exception, since it already has everything it needs.
Also, if you need to send a redirect, as you do, then you really need to do this before the view starts executing. Otherwise, the view layer may start writing out the HTTP response headers before the exception is thrown. If this happens, then you won't then be able to send a redirect instead - the response is "committed".