3

My service is DService and I am fourth link in the chain of services i.e. the call flow is Online User -> AService -> BService -> CService -> DService -> EService.

When I invoke EService from DService, it can throw retriable exception like HttpTimeoutException. I typically retry 2-3 three times and throw back an exception if it fails even after 2-3 retries.

My question is, the exception which I am throwing to CService, should that be retriable or non-retriable? Please find below my evaluation of Pros & Cons of both options

Cons of Throwing Retriable exception from DService - If DService throws a retriable exception, following the same convention CService also might retry DService 2-3 times and in each call of C-D, D will again try 2-3 times onto E service call. Likewise the calls ultimately to EService will increase exponentially as we go up the call chain. So If EService network was indeed down for long time, we are talking about long number of un-necessary calls. This can be mitigated by having timeouts for each call in the chain, still not sure if that's a enough mitigation against un-necessary number of calls.

Pros of Throwing Retriable exception from DService - CService will retry after sometime as in the subsequent retries we might get correct value (within the time limits) - Especially if the clients are some backend jobs, then they can exponentially retry for long time before giving up. Throwing Un-Retriable exception would weed out this option

Please provide your views and suggestions on this

Thanks, Harish

Harish
  • 7,589
  • 10
  • 36
  • 47

4 Answers4

3

Without knowing what the services do, whether or not DService should retry or CService should, I cannot say for sure. However my philosophy is that the service being called should not be the one to retry, ever. In this case, EService would throw an exception stupidly and without any handling whatsoever. The reason behind this is because the end of the chain should be stateless and should not make decisions on behalf of the caller.

The caller can dictate to a certain extent within the confines of what is acceptable and what isn't on whether the error should be reattempted or not. In other words, if EService attempts to perform a connection to a database and DService is performing a lookup service, then it may be in the scope of DService to say, if a certain information isn't found in a certain table, to check in another table instead. However, failure to connect to the database by EService flies over the head of DService, whose scope is simply to return information requested by CService.

CService, having made the call to retrieve certain information, depending on what it does, may then receive the database connection and attempt to retry a number of times after a delay because it is performing a batch work on that data and will continue to retry until the database is back online. Or, if it is retrieving information to show to the user on a webpage, must fail fast and deal with the database connection error by presenting a nice error message to the user instead.

It entirely depends on what your services do and where their responsibilities lie. Likewise, whether an exception is retriable or not should again depend on the caller's necessity, not the service itself. It is perfectly viable to present a retriable exception to the caller that is only attempted once.

Hope that helps!

Neil
  • 5,762
  • 24
  • 36
  • Thanks. That certainly helps. Here what if EService could recognize that Database exception was one off intermittent stale connection exception and retries that. Generally it gets sucessfull and but let's say even if it fails after 2-3 attempts by EService.. In such case should EService throw an exception which signifies client if required can retry or should it throw an exception which says there is no need to retry – Harish Mar 12 '16 at 03:20
2

I think throwing retriable exceptions is a viable approach if you define exponentially increasing retry-periods up on the chain.

riskop
  • 1,693
  • 1
  • 16
  • 34
1

I'd say you shouldn't retry in DService in the first place, because, as you say, if each service did that you could be facing trouble. Hence, let the exception bubble up the call stack and let it be handled at the outer most service possible; could even be the user.

Rationale: Why would it be on DService to decide if CService, BService or AService would want to retry or not?

However, I think it also depends on the frequency of the exception and the success rate of retries. If the exception occurs frequently but the call usually succeeds upon the first or second retry it's another thing than an exception which happens once a day and/or retrying is futile most of the time.

JimmyB
  • 12,101
  • 2
  • 28
  • 44
1

What you throw at your invokers, and whether what you throw at them will also carry a suggestion "but you could retry this", should be determined by the intended semantics of your service exclusively.

(Besides, I have never heard of java Exception objects formally carrying any such property, but that might be because I'm lagging behind a bit.)

EDIT.

Whether you "retry" an operation that failed, is for you (and you alone) to decide. However, if you do decide to retry, it is also your responsibility to decide after how many failures you are going to stop retrying and call it a day, and at that point it is most certainly unwise to throw an exception to your caller that suggests he can "retry" as well.

Erwin Smout
  • 18,113
  • 4
  • 33
  • 52