-
Notifications
You must be signed in to change notification settings - Fork 68
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
DefaultRawMemcacheClient logs error but does now throw #67
Comments
(Ping) |
@jvaleo Looks like all outstanding request futures will be failed when the channel is closed on timeout: Are you seeing futures not failing on timeout? |
@danielnorberg So the issue is that an error is logged every time the client times out, but it's difficult to take an action on those timeouts (vs another exception) because all client exceptions cause outstanding futures to throw the same exception type (with a different message). We want to monitor or take a specific action on a timeout and its not ideal to have to catch the MemcacheClosedException and check for the string "Timeout". Ideally, the exception thrown by the future would extend TimeoutException (or the future itself could timeout) so that we could manage them cleanly. |
@jvaleo Right, that sounds useful. |
@danielnorberg Is that something we can just PR? |
@jvaleo Feel free to push a PR and we'll happily review it |
Something I was interested too...so I took a crack at it, here you go: #71 |
this change is related to spotify#67 the motivation for this change is that some users may have external retriers around clients, like this Memcached one. the library ideally should throw an exception on timeout and let users deal with it however they see fit - it may be logging, retrying or falling back to another solution. when the library logs an error in this case, this makes logging noisy, which may distort operational metrics in a typical prod environment.
Whenever there is a timeout an error is logged but there is not exception thrown. This means that the caller can't catch anything and do something else. The use case for us is to catch a timeout exception, throw a custom timeout exception our framework provides which ticks metrics, logs, et cetera. This is what we do for all clients we use (Cassandra, RPC, et cetera).
If you're OK with this change, we can submit a patch for this behavior.
https://github.com/spotify/folsom/blob/master/src/main/java/com/spotify/folsom/client/DefaultRawMemcacheClient.java#L285
The text was updated successfully, but these errors were encountered: