You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Found this during investigation of #509. I will create an independent PR for this issue.
The gist of it is that a user may invoke HystrixCommand.queue() to produce a Future. If the user calls .get() on the Future, then the timeout mechanism works properly. If the user does other work on the calling thread and lets the command complete naturally, the timeout never fires.
From a cursory code review, that seems possible, as all of the timeout setup occurs on the path in which .get() or ```.get(int, TimeUnit) is invoked
The text was updated successfully, but these errors were encountered:
I've got a local branch that removes the blocking timeout and performBlockingGetWithTimeout path. It uses the HystrixTimer nonblocking timeout approach for all timeouts. This addresses the issue above, but I still need to performance test it.
Found this during investigation of #509. I will create an independent PR for this issue.
The gist of it is that a user may invoke
HystrixCommand.queue()
to produce aFuture
. If the user calls.get()
on theFuture
, then the timeout mechanism works properly. If the user does other work on the calling thread and lets the command complete naturally, the timeout never fires.From a cursory code review, that seems possible, as all of the timeout setup occurs on the path in which
.get()
or ```.get(int, TimeUnit) is invokedThe text was updated successfully, but these errors were encountered: