[jira] [Comment Edited] (CASSANDRA-7951) Add a Keep Alive operation to the Native Protocol

["Bulat Shakirzyanov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196590#comment-14196590 ] 

Bulat Shakirzyanov edited comment on CASSANDRA-7951 at 11/4/14 6:58 PM:
------------------------------------------------------------------------

All we're really trying to establish with heartbeats is that the phone cable that client and server use for communication hasn't been cut by
someone else without either side noticing so we're forcing the client to periodically say to the server "hey, are you still there?" and have
the server respond with "I'm right here, listening".

I don't really like the select from system.local approach. We will discard if the server responds with overloaded or some other error anyway.
I don't think the driver should, for example, close connections and mark node down in this case, as we'll retry such errors on other hosts
and as the node could have recovered by the time the application finally decides to execute a query. The only case where the connection
can be closed is if the server violates the protocol by responding with an unexpected response. But this would be true of the OPTIONS
request, where we expect the server to respond with SUPPORTED.

It would be great to have a PING/PONG request/response pair for this purpose but OPTIONS/SUPPORTED should suffice as well.

Let me know if I missed something.


was (Author: avalanche123):
All we're really trying to establish with heartbeats is that the phone cable that client and server use for communication hasn't been cut by
someone else without either side noticing so we're forcing the client to periodically say to the server "hey, are you still there?" and have
the server respond with "I'm right here, listening".

I don't really like the select from system.local approach. We will discard if the server respond with overloaded or some other error anyway.
I don't think the driver should, for example, close connections and mark node down in this case, as we'll retry such errors on other hosts
and as the node could have recovered by the time the application finally decides to execute a query. The only case where the connection
can be closed is if the server violates the protocol by responding with an unexpected response. But this would be true of the OPTIONS
request, where we expect the server to respond with SUPPORTED.

I would be great to have a PING/PONG request/response pair for this purpose but OPTIONS/SUPPORTED should suffice as well.

Let me know if I missed something.

> Add a Keep Alive operation to the Native Protocol
> -------------------------------------------------
>
>                 Key: CASSANDRA-7951
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7951
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Michaël Figuière
>            Priority: Minor
>              Labels: protocolv4
>
> Socket level keep-alive option doesn't seem to bring a strong enough guarantee that the connection won't be dropped as some OS or Firewall level settings might force some different behavior.
> To simplify things and bring the strong guarantee on this point that users expect, it would be interesting to add a {{NOOP}} or {{KEEPALIVE}}.
> Note that we could also turn it into a {{HEARTBEAT}} operation that would expect a response from the server to allow client to regularly probe for Cassandra node health in situation where the queries traffic is too low to bring this probing implicitly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)