The original link: https://www.dubby.cn/detail.html?id=9100

CommandKey cache problem

Consider a scenario, the new first a Command (commandKey = “commandA”), his isolation strategy is the signal isolation (ExecutionIsolationStrategy. SEMAPHORE), New again after a Command (commandKey = “commandA”), but its isolation strategy is THREAD isolation (ExecutionIsolationStrategy. THREAD), so the question comes, what on earth is this new Command isolation strategy?

Semaphore isolation again, because Hystrix has a cache for commandKey.

When nenw a new stage of the command parameter Settings (namely AbstractCommand. InitCommandProperties method), will first check to see if in the cache commandKey already exists, if there is a direct returns.

[image upload failed…(image-43d75F-1539487185510)]

2, Semaphore-Isolated timeout processing

This allows Hystrix to shed load without using thread pools but it does not allow for timing out and Walking away. “. Semaphore isolation does not support timeout, but does not support immediate return after timeout.

Since semaphore isolation does not use a thread pool, there is no way to interrupt the caller thread, even if it is extremely unsafe to do so because it might interrupt the application thread.

So, if semaphore isolation is used and a timeout of 1s is configured, what happens if the timeout is 5s?

This command will still execute 5s before returning, but it will return the result returned by getFallback.

[image upload failed…(image-8f6FA0-1539487185510)]

Related: ExecutionIsolationStrategy. SEMAPHORE and interrupt – on – a timeout

In which thread is getFallback executed under thread isolation

These are not actually the pictures that I want to show you, but they can be used to show you, so let me summarize.

  • If it is a normal execution, throwing an exception, then getFallback is executed in the thread pool we defined.
  • If the timeout is interrupted, the getFallback is executed in the Timer’s thread pool (Hystrix’s own thread pool, which runs timed tasks for timing purposes).
  • If the thread is already fusing, the getFallback is executed in the thread where the caller resides.
  • If command exceeds the queue limit, then getFallback is executed in the thread where the caller resides.

4. Hystrix execution fails but cannot enter fallback

If the throwable thrown by the command execution method is:

  • StackOverflowError
  • VirtualMachineError
  • ThreadDeath
  • LinkageError

Hystrix will not enter the fallback method and will throw HystrixRuntimeException directly because these errors are considered unrecoverable.

AbstractCommand.java:

5, HystrixRuntimeException: Command fallback execution Rejected.

The full text of the exception is:

com.netflix.hystrix.exception.HystrixRuntimeException: TestCommand fallback execution rejected.
Copy the code

The fallback method was rejected when it should have been executed.

In this case, the general is the command has been fusing, all requests into the fallback, because the fallback default is a concurrent processing biggest limit, fallback. Isolation. Semaphore. MaxConcurrentRequests, The default value is 10. This method is very simple and fast, but if the QPS is very high, it is still easy to reach the threshold of 10, resulting in subsequent rejection.

The solution is simple:

  • Fallback should be as simple as possible, with no time-consuming operations. If you use an HTTP interface to degrade another HTTP interface, you must consider whether that HTTP interface will fail as well.
  • Can increase the fallback appropriately. The isolation. The semaphore. MaxConcurrentRequests

If concerned with specific processing logic, you can see the AbstractCommand. GetFallbackOrThrowException