RxNetty and Hystrix Request Caching

[dfjones]

I'm curious if anyone has any experience/advice with the combination of RxNetty and Hystrix request caching.

The default Concurrency Strategy for Hystrix seems a bit at odds with the concurrency model of RxNetty (or anything async). I've noticed some hooks in Hystrix to try and populate context to child threads, but the issue I'm seeing is a pollution of these contexts on the Netty IO threads. Hystrix's AbstractCommand has this hooks in this method to carry the context forward:

 private static void setRequestContextIfNeeded(final HystrixRequestContext currentRequestContext) {
        if (!HystrixRequestContext.isCurrentThreadInitialized()) {
            // even if the user Observable doesn't have context we want it set for chained operators
            HystrixRequestContext.setContextOnCurrentThread(currentRequestContext);
        }
    }

However, there doesn't appear to be anything to reset the context before the Netty thread is returned to the pool.

For short lived caching that could be shared across requests, this might be ok, however, if we want to use this context for data that should only be available on a single request, it seems like this behavior would potentially contaminate other requests.

So, what do RxNetty and Hystrix users do to get around this?

[NiteshKant]

@dfjones is this for 0.4.x or 0.5.x branch?

[dfjones]

@NiteshKant 0.4.x branch

[NiteshKant]

@dfjones have you looked at the rxnetty-contexts module for 0.4.x? It can be used for request specific caching.

[dfjones]

@NiteshKant No! I wasn't aware of that module. I'll give it a shot, thanks!