[
https://issues.apache.org/jira/browse/CASSANDRA-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14508166#comment-14508166
]
Aleksey Yeschenko commented on CASSANDRA-8049:
----------------------------------------------
- initializing JMX arguably shouldn't be part of a startup check. Errors and
warnings should be, if we don't mind some logic duplication of the port
checking for nulls (I don't)
- the {{info}} logging in {{inspectJvmOptions}} for heap size and "JVM
vendor/version" should probably also remain in {{CassandraDaemon}}, and the
32bit VM logger.info should really be a {{warn}}.
- {{checkJnaInitialization}} shouldn't be calling {{CLibrary.tryMlockall()}}.
Catching {{LastErrorException}} there is also kinda pointless -
{{CLibrary.tryMlockall()}} never ever rethrows it (and provides more than
sufficient logging itself)
- {{initSigarLibrary}} if/else logic is redundant (and I know it's a
pre-existing condition). A single-line {{new
SigarLibrary().warnIfRunningInDegradedMode()}} should be sufficient, b/c the
method itself has an else branch on {{initialized}} that logs 'failed to
initialize' if so.
- {{checkCacheServiceInitialization}} can go away entirely. I don't see a way
it could happen, it's basically dead code (and has been so forevah)
- snapshotting system keyspace on upgrades should be done, but probably not as
part of {{checkSystemKeyspaceState}} or the startup check framework. Can we
make it a separate method in {{CassandraDaemon}} or, better,
{{SystemKeyspace}}, instead?
Nits:
- {{StartupCheck}} javadocs are incorrect, not reflecting the fact that we only
throw the exception now and not return any values
- {{StartupException}} should probably be a checked one here, given that it can
only be caught in one place and *is* being caught there
Most of the issues here are ones in the pre-existing code, but this ticket is
an opportunity to fix them anyway, since they are related. Everything else LGTM.
> Explicitly examine current C* state on startup to detect incompatibilities
> before upgrade
> -----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-8049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8049
> Project: Cassandra
> Issue Type: Bug
> Reporter: Aleksey Yeschenko
> Assignee: Sam Tunnicliffe
> Fix For: 3.0
>
> Attachments: 8049-v2.txt, 8049.txt
>
>
> Unfortunately, we cannot rely on users reading, and following, NEWS.txt
> before upgrading. People don't read, or ignore it, and sometimes have issues
> as the result (see CASSANDRA-8047, for example, and I know of several cases
> like that one).
> We should add an explicit compatibility check on startup, before we modify
> anything, or write out sstables with the new format. We should fail and
> complain loudly if we detect a skipped upgrade step.
> We should also snapshot the schema tables before attempting any conversions
> (since it's not uncommon to make schema modifications as part of the upgrade).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
