You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2012/07/05 15:25:35 UTC
[jira] [Created] (CASSANDRA-4414) Ship the exact cause for timeout
and unavailable exception back to the client
Sylvain Lebresne created CASSANDRA-4414:
-------------------------------------------
Summary: Ship the exact cause for timeout and unavailable exception back to the client
Key: CASSANDRA-4414
URL: https://issues.apache.org/jira/browse/CASSANDRA-4414
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Fix For: 1.2
Currently when a client gets a timeout exception, it doesn't know what happened. But sever side we usually know a little more than that. For example, for 99% of the timeouts at CL > ONE, we will have some replica that have acknowlege. I think it could be useful to send that information to the client with the exception. That could help with monitoring, "post-mortem" analysis and debugging.
Unavailable exceptions could also ship which nodes were alive and which ones where not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4414) Ship the exact cause for
timeout and unavailable exception back to the client
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413620#comment-13413620 ]
Sylvain Lebresne commented on CASSANDRA-4414:
---------------------------------------------
The patch doesn't compile due to missing TimeoutException -> TimedOutException renaming in HintedHandoffManager.
Otherwise the patch lgtm.
nit: Maybe in WriteResponseHandler, we could keep the blockFor value as a field instead of the table, which would avoid having to care about null checks
> Ship the exact cause for timeout and unavailable exception back to the client
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-4414
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4414
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Jonathan Ellis
> Fix For: 1.2
>
>
> Currently when a client gets a timeout exception, it doesn't know what happened. But sever side we usually know a little more than that. For example, for 99% of the timeouts at CL > ONE, we will have some replica that have acknowlege. I think it could be useful to send that information to the client with the exception. That could help with monitoring, "post-mortem" analysis and debugging.
> Unavailable exceptions could also ship which nodes were alive and which ones where not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4414) Ship the exact cause for
timeout and unavailable exception back to the client
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407209#comment-13407209 ]
Jeremy Hanna commented on CASSANDRA-4414:
-----------------------------------------
Would be great to have more information in TimedOutException to the client. Since the hadoop support is a 'client', having more detail there is invaluable.
> Ship the exact cause for timeout and unavailable exception back to the client
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-4414
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4414
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Fix For: 1.2
>
>
> Currently when a client gets a timeout exception, it doesn't know what happened. But sever side we usually know a little more than that. For example, for 99% of the timeouts at CL > ONE, we will have some replica that have acknowlege. I think it could be useful to send that information to the client with the exception. That could help with monitoring, "post-mortem" analysis and debugging.
> Unavailable exceptions could also ship which nodes were alive and which ones where not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4414) Ship the exact cause for
timeout and unavailable exception back to the client
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13412278#comment-13412278 ]
Jonathan Ellis commented on CASSANDRA-4414:
-------------------------------------------
bq. I do think we should break this apart into a separate exception
I still would like to do this in an ideal world but I think our hands might be tied by the client community... unless we're willing to break everyone who doesn't add IPE, the optional field is a better approach.
> Ship the exact cause for timeout and unavailable exception back to the client
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-4414
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4414
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Fix For: 1.2
>
>
> Currently when a client gets a timeout exception, it doesn't know what happened. But sever side we usually know a little more than that. For example, for 99% of the timeouts at CL > ONE, we will have some replica that have acknowlege. I think it could be useful to send that information to the client with the exception. That could help with monitoring, "post-mortem" analysis and debugging.
> Unavailable exceptions could also ship which nodes were alive and which ones where not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4414) Ship the exact cause for
timeout and unavailable exception back to the client
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407224#comment-13407224 ]
Brandon Williams commented on CASSANDRA-4414:
---------------------------------------------
The thing is, if we keep the exception returning the same type you'd have to do string parsing on it (which I've done a lot of with IRE, and agree it sucks.) If we change the return type, checked exceptions screw java clients.
> Ship the exact cause for timeout and unavailable exception back to the client
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-4414
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4414
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Fix For: 1.2
>
>
> Currently when a client gets a timeout exception, it doesn't know what happened. But sever side we usually know a little more than that. For example, for 99% of the timeouts at CL > ONE, we will have some replica that have acknowlege. I think it could be useful to send that information to the client with the exception. That could help with monitoring, "post-mortem" analysis and debugging.
> Unavailable exceptions could also ship which nodes were alive and which ones where not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4414) Ship the exact cause for
timeout and unavailable exception back to the client
Posted by "Jeremy Hanna (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407211#comment-13407211 ]
Jeremy Hanna commented on CASSANDRA-4414:
-----------------------------------------
Any reason this has to be targeted at 1.2 rather than 1.1.x or even 1.0.x? Seems like it would be a pretty applicable patch.
> Ship the exact cause for timeout and unavailable exception back to the client
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-4414
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4414
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Fix For: 1.2
>
>
> Currently when a client gets a timeout exception, it doesn't know what happened. But sever side we usually know a little more than that. For example, for 99% of the timeouts at CL > ONE, we will have some replica that have acknowlege. I think it could be useful to send that information to the client with the exception. That could help with monitoring, "post-mortem" analysis and debugging.
> Unavailable exceptions could also ship which nodes were alive and which ones where not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4414) Ship the exact cause for
timeout and unavailable exception back to the client
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407251#comment-13407251 ]
Sylvain Lebresne commented on CASSANDRA-4414:
---------------------------------------------
I haven't checked but maybe thrift will gentle enough to allow adding optional fields to the exceptions, which would be my preferred option. But yes, that is one of the reason why I've targeted to 1.2, but don't take it at face value, it's not definitive.
> Ship the exact cause for timeout and unavailable exception back to the client
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-4414
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4414
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Fix For: 1.2
>
>
> Currently when a client gets a timeout exception, it doesn't know what happened. But sever side we usually know a little more than that. For example, for 99% of the timeouts at CL > ONE, we will have some replica that have acknowlege. I think it could be useful to send that information to the client with the exception. That could help with monitoring, "post-mortem" analysis and debugging.
> Unavailable exceptions could also ship which nodes were alive and which ones where not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira