-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
how to pass MDC context from calling thread to timer thread in case of hystrix time out fallback #1653
Comments
Can anybody help in this issue ? |
I'm also interested in this, we are having the same problem. Any ideas? |
This can be achieved by overriding HystrixCommandExecutionHook implementation. and pass the MDC context in appropriate methods. more details here - |
Do you have an example of how this can be done? I'm not seeing how this class will work. |
@jjathman Yes you can do something like this:
Sorry for delay in replying. Let me know if this resolve your issue. |
@JagmohanSharma after HystrixRequestContext.initializeContext() was called then shutdown() must also be called or a memory leak will occur. How do you deal with it? |
@the-wang Its complete implementation will be
|
We have also implemented HystrixConcurrencyStrategy to clear MDC.
|
Thanks @JagmohanSharma for providing an approach here. Is there a reason for having both |
Is there an answer to oliver-steinbrecher question? Why do the MDC.clear() in HystrixConcurrencyStrategy instead of the HystrixCommandExecutionHook? |
@oliver-steinbrecher @devinwhalen I had a very similar issue and in my tests I found the following situation when only using HystrixCommandExecutionHook:
On the other hand, HystrixConcurrencyStrategy is executed both in the hystrix-commandGroup-X and HystrixTimer-X threads. With all this premises, the best way I've found to solve this is to only override in HystrixCommandExecutionHook onStart, onThreadStart and onFallbackStart methods, and do the clean-up in HystrixConcurrencyStrategy. I hope this helps and thanks for the discussion! |
Great - thanks for the feedback. I'm wondering why there is no official support for handling this. It feels like being a standard pattern "coping context from parent to child thread" |
I resolved the issue by creation of abstract command and placing there logic to inherit MDC in next way:
And inherited all our hyxtrix command from it. Since each command is created from a thread where we already have MDC we can save it to a variable in the command constructor and use in run method that is triggered from another thread where we need to get this MDC. |
Encountered same problem, for those who are still confused refer to this blog |
@JagmohanSharma |
With reference to #1564 and #1570 issue, as
it will now invoke wrapCallable only when:
putting the Hystrix-wrapped work onto a Hystrix thread (command is thread-isolated)
executing the fallback on a HystrixTimer thread
executing a HystrixCollapser-produced command on a HystrixTimer thread
As this fallback execution is being done on HystrixTimer thread. We are passing MDC context (which contains Logging correlation id ) between calling(parent) and callee(child) threads but as in this case child thread will be HystrixTimer which is not getting parent MDC so does not has Logging correaltion id. We are not getting any correlation id in our log statements inside fallback methods in case of hystrix time out.
}
In recent changes done in hystrix library currently we are capturing HystrixRequestContext upfront so that we can use it in the timeout thread later
But initialising the HystrixContextRunnable in child thread "TimerListener" context so it does not have any calling thread information:
@mattrjacobs @spencergibb please let me know how to achieve this with respect to recent changes done in hystrix?
The text was updated successfully, but these errors were encountered: