0

My googling suggests that the answer to this is a simple 'no' but I have to ask anyway.

I'm trying to add in some logging/metrics emitting to a service's retry strategy so that we can get an idea of what our actual real world retrying and timeout profile looks like. I wrote a wrapper/decorator to sit on top of the underlying strategy object, but the issue is of course that we're currently just injecting a generic RetryStrategy object and I want my specific behavior to be aware of some context; minimally the name of the requester, so that I can emit a metric saying that such-and-such client timed out after n millis on its kth retry.

Is something like this possible in Guice, either out of the box or with relatively light modification?

That is, I'd like something along these lines in my module file: 

@Provides
RetryStrategy getNewDefaultRetryStrategy() {
    RetryStrategy baseStrategy = getOldRetryStrategy();
    String clientName = NAME_OF_THING_WE_ARE_INJECTING_INTO; // this is the magic I want
    return new WrappedStrategy(baseStrategy, clientName);
}
a p
  • 3,098
  • 2
  • 24
  • 46
  • 1
    Not sure I understood correctly, but what about using the method that does the actual retry to find out who's the caller? https://stackoverflow.com/q/421280/4890123 – Guy Grin Aug 21 '18 at 22:50
  • I considered this actually, despite how ugly it is, but figured that at the scale I'm considering, creating these exceptions and reflecting on the stack could be prohibitively expensive. – a p Aug 21 '18 at 23:47
  • Is there some other injectable context object you can inject into the provider? If not, could you modify your backend clients to each inject a different `RetryStrategy` (with a suitable qualifier annotation)? If you want the thing you inject to be different in different contexts, the normal approach is to make Guice aware that there are different contexts. – Daniel Pryden Aug 21 '18 at 23:59
  • @DanielPryden not really - my goal is to sort of drop this in 'in-place' for a time to harvest metrics and then remove it, with minimal refactoring. We have hundreds of endpoints that use these clients which all use the same retry strategy, so adding even a small change to each so that it requests with an identifier would be fairly cumbersome. As to making guice aware of the context, I was sort of hoping there was a 'free' context that could be taken advantage of here. – a p Aug 22 '18 at 00:09
  • It seems somewhat wrong to me that you would have hundreds of clients that all share a retry strategy today. What if one of them needed a different strategy? Possibly you should bite the bullet and refactor sooner rather than later. Guice does provide some ability to introspect the dependency graph, but it's cumbersome at best and not really designed for this kind of thing. (As an aside: if the framework you're working with is the one I suspect it is, you would probably get some better help by talking to the frameworks team directly.) – Daniel Pryden Aug 22 '18 at 00:56
  • 2
    It's [one of the first requests that one ever opened to Guice](https://github.com/google/guice/issues/27), and it's been rejected numerous times. – Olivier Grégoire Aug 22 '18 at 07:19

0 Answers0