From the understanding, Hystrix fallback logic is triggered when certain conditions occurred such as Request timeout, thread-pool running at a capacity of 100% or dependency throws exception. Beside these 3 factors can I add more conditions that are also considered as failures such as any specific HTTP Error code like 413 (payload too large)?
The fallback method of Hystrix will be called under the following condition
circuit open
semaphore/thread pool rejection
execution fail (any exception thrown by your method excluding HystrixBadRequestException)
timeout of your method (hystrix timeout)
Only part that is directly related to the user code is execution fail.
In this case, fallback will be triggered by any exception thrown by run() method. It is same for pure Hystrix via HystrixCommand and Hystrix Javanica via annotation.
Only one exception that doesn't trigger HystrixBadRequestException
Therefore, if you want to trigger your fallback also for HTTP 413 status code, all you have to is just throwing any exception inside your method.
If you're using any library that has built-in Hystrix support like Spring Cloud Feign, you need to implement something that library requires. In case of Spring Cloud Feign, you can implement your own ErrorDecoder. The default error decoder will trigger fallback for all 4XX,5XX errors. If you don't want to trigger any fallback 4XX errors except 413, you can throw HystrixBadRequestException inside it.
Related
Trying to understand the exact sequence of events in terms of flow in case of Linux:
User application program makes a call to a system call.
This results in execution of code which results in triggering of a software exception (which code is this? It's understandable if I called a glibc API, but what if my program is calling a system call directly). Is there some piece of code that regular system calls have which triggers this exception?
Once the exception is triggered -- user application processes context needs to be preserved and user application I presume will be in pend state(assuming its a waited system call that was invoked).
Exception handler then runs and picks suitable handler based on system call invoked(how is this system call number passed to exception handler from this exception triggering code?)
An exception handler runs(let's say a read call for example and has to return read data to use a process which triggered its invocation - this I assume would mean the exception triggering code has also passed a pointer to buffer to which read data needs to be copied over to)
Once the exception handler is done, the control now has to return to the application which would now be pending system call.
Does this flow look alright > Is there some sample code for each of these steps beyond user application?
Version 1.0
Let's say in the punctuate method of lowlevel processor, creation of a dummy file fails with an exception. How to stop the stream application when an exception is encountered?
I was wondering if there is a way to throw an exception, but could not add throw clause on the init method. The following requires to be surrounded by a try-catch OR an exception to be thrown and can't use either one. Please suggest.
Files.createFile(Paths.get(dummyFile));
you could wrap IOException into any unchecked exception like RuntimeException, or would be better to create your own that will extend from RuntimeException, and throw it. if your method throw exception for any incoming message, stream will be in a dead state, so stop consuming messages until you restart application
I have a batchjob and need to run it up the application. He makes the call for the job, but the job does not reach the method.
BatchRuntime.getJobOperator().start(JOB_NAME, new Properties());
Throws no errors. So it seems that he is looking for the resource that indicates which class Implementing this job, but not yet loaded. Any idea?
The start() method is asynch so the caller isn't going to always see exceptions on failure.
Is the XML corresponding to JOB_NAME found? Any errors in the logs?
I have a set of RIA domain services that use an overriden OnError operation to throw DomainExceptions. This works perfectly and allows the silverlight client to identify the base exception types via the embedded error code. However my RIA service operations are attributed to include a number of implementaions of IOperationInvoker to inject pre-invoke and post-invoke behaviour.
If an exception is thrown by any of the code in these IOperationInvoker operations the silverlight client gets a DomainOperationException containing a FaultException. Even though the thrown exception is a FaultException the received fault appears be be devoid of any the original detail only containing the textual message.
I have tried catching the exception in the IOperationInvoker and converting it to a DomainException but this does not change what is visible in Silverlight.
Is there any way I can throw an Exception from the IOperationInvoker so that it is surfaced in the Silverlight client as a DomainException i.e. including the error code as if it had come from the DomainService operation that is wrapped by the IOperationInvoker?
I want to implement a solution in my workflows that will do the following :
In the workflow level I want to implement a Fault Handler that will suspend the workflow for any exception.
Then at sometime the instance will get a Resume() command .
What I want to implement that when the Resume() command received , the instance will execute again the activity that failed earlier ( and caused the exception ) and then continue to execute whatever he has to do .
What is my problem :
When suspended and then resumed inside the Fault Handler , the instance is just completes. The resume of course doesn't make the instance to return back to the execution,
since that in the Fault Handler , after the Suspend activity - I have nothing. So
obviously the execution of the workflow ends there.
I DO want to implement the Fault Handler in the workflow level and not to use a While+Sequence activity to wrap each activity in the workflow ( like described here:
Error Handling In Workflows ) since with my pretty heavy workflows - this will look like a hell.
It should be kinda generic handling..
Do you have any ideas ??
Thanks .
If you're working on State Machine Workflows, my technique for dealing with errors that require human intervention to fix is creating an additional 'stateactivity' node that indicates an 'error' state, something like STATE_FAULTED. Then every state has a faulthandler that catches any exception, logs the exception and changes state to STATE_FAULTED, passing information like current activity, type of exception raised and any other context info you might need.
In the STATE_FAULTED initialization you can listen for an external command (your Resume() command, or whatever suits your needs), and when everything is OK you can just switch to the previous state and resume execution.
I am afraid that isn't going to work. Error handling in a workflow is similar to a Try/Catch block and the only way to retry is to wrap everything is a loop and just execute the loop again if something was wrong.
Depending on the sort of error you are trying to deal with you might be able to achieve your goal by creating custom activities that wrap their own execution logic in a Try/Catch and contain the required retry logic.