[ https://issues.apache.org/jira/browse/CASSANDRA-9761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-9761: ---------------------------------------- Assignee: Sam Tunnicliffe > Delay auth setup until peers are upgraded > ----------------------------------------- > > Key: CASSANDRA-9761 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9761 > Project: Cassandra > Issue Type: Improvement > Reporter: Sam Tunnicliffe > Assignee: Sam Tunnicliffe > Fix For: 3.0.0 rc1, 2.2.2 > > > The built in auth classes {{CassandraRoleManager}} and > {{CassandraAuthorizer}} both attempt to do some setup and data conversion > when a node is upgraded to version 2.2 or higher. At the moment, each node > attempts the operations with the expectation that this will fail until enough > of the cluster has been upgraded for it to succeed (i.e. enough nodes have > the latest schema with the requisite new tables). These expected failures are > largely harmless, but they are annoying because they cause the receiving node > (the non-upgraded node) to close the connection with the upgraded node, which > then has to be restablished. Although this is the normal behaviour on schema > disagreement (see CASSANDRA-9136 for further discussion), it may be possible > to avoid in this specific circumstance. Given that we expect the operations > to fail until enough nodes are upgraded, we could defer them until we're sure > they can succeed by checking the messaging service version of peers. > Right now these are a one shot thing, each node only makes one attempt at the > conversion (until it is restarted). Without investigating further, I don't > know if we'd need to add in retries in case it takes a little time for each > peer's MS version to be updated as they're upgraded. The setup & conversion > operations are idempotent, so there shouldn't be a great issue if several > nodes attempt them at the same time anyway. -- This message was sent by Atlassian JIRA (v6.3.4#6332)