cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bulat Shakirzyanov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-7951) Add a Keep Alive operation to the Native Protocol
Date Tue, 04 Nov 2014 18:58:36 GMT

    [ 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)

Mime
View raw message