cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "mck (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests
Date Tue, 26 Apr 2016 11:14:12 GMT

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

mck edited comment on CASSANDRA-11381 at 4/26/16 11:13 AM:
-----------------------------------------------------------

{quote} - Is there a reason that we only setup auth in StorageService.initServer if the saved
tokens aren't empty? This doesn't handle the case when a node starts with join_ring false
on its first boot (a coordinator-only node). This can be reproduced with a small variant of
your dtest in which we do not start node3 in the initial preparation. Some experimentation
on my end suggests this would be fine.{quote}

Good point. Will fix. There's a similar fault in the trunk patch in regards to {{isSurveyMode}}.

{quote} - On a similar note, is there a reason we can't just move auth setup slightly earlier
in StorageService.initServer()? If we moved it before the check of the join_ring property,
we could do without the idempotency parts of the patches. Again, this looks workable in my
experimentation.{quote}

That did seem like the cleaner solution. But my understanding on the auth model and setup
isn't solid, so my intention here was to offer the less-risk patch. I still suspect this (less-risk
approach) is the smart approach (for a patch from me) against the non-trunk patches.

I'll take a look at moving the auth setup to an earlier place in just the trunk patch, ok?
It seems to make sense to move the call in {{prepareToJoin()}}.

{quote} - Was there any method by which you arrived at the 300 second timeouts for the cql
connection on the dtests? This really drags the test on in failing cases, and I was able to
reduce it to 30 seconds without any false negatives.{quote}

No. Just playing it safe for my dual-core thinkpad. (I did have to bump it up once).

{quote} - Tests handling the coordinator-only case and using JMX to join the node to the ring
would be great. I think a minimal parameterized test could handle these all these permutations.{quote}

I'll take a look.


was (Author: michaelsembwever):
{quote} - Is there a reason that we only setup auth in StorageService.initServer if the saved
tokens aren't empty? This doesn't handle the case when a node starts with join_ring false
on its first boot (a coordinator-only node). This can be reproduced with a small variant of
your dtest in which we do not start node3 in the initial preparation. Some experimentation
on my end suggests this would be fine.{quote}

Good point. Will fix. There's a similar fault in the trunk patch in regards to {{isSurveyMode}}.

{quote} - On a similar note, is there a reason we can't just move auth setup slightly earlier
in StorageService.initServer()? If we moved it before the check of the join_ring property,
we could do without the idempotency parts of the patches. Again, this looks workable in my
experimentation.{quote}

That did seem like the cleaner solution. But my understanding on the auth model and setup
isn't solid, so my intention here was to offer the less-risk patch. I still suspect this is
smart approach against the non-trunk patches.

I'll take a look at moving the auth setup to an earlier place in just the trunk patch, ok?
It seems to make sense to move the call in {{prepareToJoin()}}.

{quote} - Was there any method by which you arrived at the 300 second timeouts for the cql
connection on the dtests? This really drags the test on in failing cases, and I was able to
reduce it to 30 seconds without any false negatives.{quote}

No. Just playing it safe for my dual-core thinkpad. (I did have to bump it up once).

{quote} - Tests handling the coordinator-only case and using JMX to join the node to the ring
would be great. I think a minimal parameterized test could handle these all these permutations.{quote}

I'll take a look.

> Node running with join_ring=false and authentication can not serve requests
> ---------------------------------------------------------------------------
>
>                 Key: CASSANDRA-11381
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: mck
>            Assignee: mck
>             Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>         Attachments: 11381-2.0.txt, 11381-2.1.txt, 11381-2.2.txt, 11381-3.0.txt, 11381-trunk.txt,
dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has authentication
configured, eg PasswordAuthenticator, won't be able to serve requests. This is because {{Auth.setup()}}
never gets called during the startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients connecting
to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
>         at org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
>         at org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
>         at org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
>         at org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
>         at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
>         at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
>         at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
>         at com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
>         at com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
>         at com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
>         at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = authenticateStatement.execute(QueryState.forInternalCalls(),
new QueryOptions(consistencyForUser(username),
>                                                                                     
Lists.newArrayList(ByteBufferUtil.bytes(username))));
> {code}



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

Mime
View raw message