Skip to content
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

Open
jvaleo opened this issue Mar 14, 2017 · 7 comments
Open

DefaultRawMemcacheClient logs error but does now throw #67

jvaleo opened this issue Mar 14, 2017 · 7 comments

Comments

@jvaleo
Copy link

jvaleo commented Mar 14, 2017

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

@jvaleo
Copy link
Author

jvaleo commented Mar 27, 2017

(Ping)

@danielnorberg
Copy link
Contributor

@jvaleo Looks like all outstanding request futures will be failed when the channel is closed on timeout:

https://github.com/spotify/folsom/blob/master/src/main/java/com/spotify/folsom/client/DefaultRawMemcacheClient.java#L319

Are you seeing futures not failing on timeout?

@jvaleo
Copy link
Author

jvaleo commented Apr 13, 2017

@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.

@danielnorberg
Copy link
Contributor

@jvaleo Right, that sounds useful.

@jvaleo
Copy link
Author

jvaleo commented Apr 24, 2017

@danielnorberg Is that something we can just PR?

@protocol7
Copy link
Contributor

@jvaleo Feel free to push a PR and we'll happily review it

@mniebla
Copy link

mniebla commented May 3, 2017

Something I was interested too...so I took a crack at it, here you go: #71

alexeyOnGitHub pushed a commit to alexeyOnGitHub/folsom that referenced this issue May 21, 2019
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants