[ https://issues.apache.org/jira/browse/CASSANDRA-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625896#comment-13625896 ]
Vijay edited comment on CASSANDRA-3533 at 4/8/13 10:05 PM: ----------------------------------------------------------- {quote} where would the null EchoMessage come from? Even the v1 serialize does not return null. {quote} in o.a.c.n.MessageIn {code} if (payloadSize == 0 || serializer == null) return create(from, null, parameters, verb, version); T2 payload = serializer.deserialize(in, version); {code} if the payload is 0 then we wont deserialize, thats where it comes from :) I will remove the assertion if thats all we need to do from the original patch. was (Author: vijay2...@yahoo.com): {quote} where would the null EchoMessage come from? Even the v1 serialize does not return null. {quote} {code} if (payloadSize == 0 || serializer == null) return create(from, null, parameters, verb, version); T2 payload = serializer.deserialize(in, version); {code} if the payload is 0 then we wont deserialize, thats where it comes from :) I will remove the assertion if thats all we need to do from the original patch. > TimeoutException when there is a firewall issue. > ------------------------------------------------ > > Key: CASSANDRA-3533 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3533 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: Vijay > Assignee: Vijay > Priority: Minor > Fix For: 2.0 > > Attachments: 0001-3533-v2.patch, 0001-CASSANDRA-3533.patch, 3533.txt > > > When one node in the cluster is not able to talk to the other DC/RAC due to > firewall or network related issue (StorageProxy calls fail), and the nodes > are NOT marked down because at least one node in the cluster can talk to the > other DC/RAC, we get timeoutException instead of throwing a > unavailableException. > The problem with this: > 1) It is hard to monitor/identify these errors. > 2) It is hard to diffrentiate from the client if the node being bad vs a bad > query. > 3) when this issue happens we have to wait for at-least the RPC timeout time > to know that the query wont succeed. > Possible Solution: when marking a node down we might want to check if the > node is actually alive by trying to communicate to it? So we can be sure that > the node is actually alive. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira