Hi Alexey, Thank you for helping me.
validity seconds works like a charm! But I found that 'n' is missing, so that "--auth*n*_token_validity_seconds" is valid. Thanks! 2017-06-15 3:37 GMT+09:00 Alexey Serbin <aser...@cloudera.com>: > Hi Jason, > > It seems your Java Kudu client hit the authn token expiration issue. As > you mentioned, that's a well known issue and it is described in the docs. > Just FYI, the Kudu C++ client starting 1.4.0 automatically re-acquires > authn token when needed, and I hope the Java client will do so as well in > next release. If you are interested in details, the issue is tracked by > https://issues.apache.org/jira/browse/KUDU-2013 and is being actively > worked on (there is a WIP patch for that). > > As for a temporary workaround, you could try one the following: > > * Set authn token expiration time to some huge value, i.e. run the Kudu > masters with custom value for the --auth_token_validity_seconds flag. The > default is 7 days (604800 seconds); you could try to set it to, say, 300 > days: '--auth_token_validity_seconds=25920000'. That would be a good > option if your use-case requires a secure Kudu cluster with > authentication. For this workaround, once Kudu masters are restarted with > new flags, you also need to restart your Java clients to acquire a new > token with longer TTL if you don't want them to hit the issue in one week. > > * Disable RPC authentication and encryption, i.e. run both Kudu masters > and tablet servers with '--rpc_authentication=disabled > --rpc_encryption=disabled' flags (you need to disable both authn and > encryption). That would be an option if your use-case does not require a > secure Kudu cluster. In this case you don't need to restart your Java > clients once you restarted Kudu server-side components. > > Hope this helps. > > > Kind regards, > > Alexey > > > > On 6/14/17 2:44 AM, Jason Heo wrote: > >> Hi. >> >> I'm using Apache Kudu 1.4.0. >> >> And I have a long running Java Daemon which is a kudu client at the same >> time. >> >> Today (7 days has been past since the Java Daemon has been started) I >> suddenly got an following error. >> >> >> W0614 15:29:11.934401 62459 negotiation.cc:310] Unauthorized connection >> attempt: Server connection negotiation failed: server connection from >> ip_addr:56604: authentication token expired >> >> W0614 15:29:11.956845 62459 negotiation.cc:310] Unauthorized connection >> attempt: Server connection negotiation failed: server connection from >> ip_addr:56606: authentication token expired >> >> ... >> >> ... >> >> ... >> >> W0614 17:47:18.347970 74099 negotiation.cc:310] Unauthorized connection >> attempt: Server connection negotiation failed: server connection from >> ip_addr:56172: authentication token expired >> >> W0614 17:47:20.488306 74100 negotiation.cc:310] Unauthorized connection >> attempt: Server connection negotiation failed: server connection from >> ip_addr:56180: authentication token expired >> >> >> >> Kudu is started with this options >> >> --unlock_experimental_flags=true >> >> ... >> >> --superuser_acl=user1,user2 >> >> >> The Java Daemon is started with user2 account. >> >> How can I prevent from happening this error again. >> >> I've read this manual. https://kudu.apache.org/docs/s >> ecurity.html#known-limitations >> >> It says that "so long-lived clients in secure clusters are not supported" >> Then Should I set `--rpc-authentication=disable`? >> >> Thanks. >> >> Regards, >> >> Jason >> > >
