cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Alves (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3564) flush before shutdown so restart is faster
Date Fri, 22 Jun 2012 03:14:43 GMT


David Alves commented on CASSANDRA-3564:

bq. Sure, but this is where is gets a little more complicated, since after receiving the error
the init script needs to check that the pid is really gone, and if not get more forceful.

was about to implement this when a problem came to mind. There's no time limit on how long
a flush will take and shutdown hooks can take as long as needed to finish up so we have no
idea when to "get more forceful".

There's two ways we could deal with this IMO:
- we poll-check on the pid, nodetool side, and give it an umbrella grace period to do everything,
after that we SIGKILL it
- we simply inform that it might take a while.
> flush before shutdown so restart is faster
> ------------------------------------------
>                 Key: CASSANDRA-3564
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Packaging
>            Reporter: Jonathan Ellis
>            Assignee: David Alves
>            Priority: Minor
>             Fix For: 1.2
>         Attachments: 3564.patch
> Cassandra handles flush in its shutdown hook for durable_writes=false CFs (otherwise
we're *guaranteed* to lose data) but leaves it up to the operator otherwise.  I'd rather leave
it that way to offer these semantics:
> - cassandra stop = shutdown nicely [explicit flush, then kill -int]
> - kill -INT = shutdown faster but don't lose any updates [current behavior]
> - kill -KILL = lose most recent writes unless durable_writes=true and batch commits are
on [also current behavior]
> But if it's not reasonable to use nodetool from the init script then I guess we can just
make the shutdown hook flush everything.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message