[
https://issues.apache.org/jira/browse/CASSANDRA-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15208945#comment-15208945
]
Sam Tunnicliffe commented on CASSANDRA-10091:
---------------------------------------------
[~tjake], after some spelunking in the RMI implementation, it seems the
warning you saw was caused by the overzealous assert that I removed in
[4f28d1e|https://github.com/beobal/cassandra/commit/4f28d1e4c7d18e47d9edb0908507666b639a39f7].
When an idle connection times (by default after 120000ms), the server tries to
unexport it, but because the custom exporter barfed on the assert, it never was
exported in the first place. I experimented with lowering the timeout & adding
back the assert & can confirm the warn re-appeared, so removing that assert is
the solution.
Regarding the extra dtests I mentioned, it's actually a bit trickier than I
first thought. The reason being that the way dtests interact with JMX is by
attaching the custom Jolokia agent to the running ccm node, which provides its
own JMX connector server and so bypasses all the built in auth stuff. Jolokia
can run in proxy mode, whereby it binds to the JMX connector provided by the
server, but that requires a servlet container to host the HTTP endpoint. As an
alternative, I've added some more functional tests in
{{o.a.c.auth.jmx.JMXAuthTest}}, while not covering everything they do exercise
a real RMI connection so are probably at least somewhat useful.
I've also removed the duplication in {{CassandraLoginModule}} and updated
NEWS.txt.
dtest pull request [here|https://github.com/riptano/cassandra-dtest/pull/887]
> Integrated JMX authn & authz
> ----------------------------
>
> Key: CASSANDRA-10091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10091
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jan Karlsson
> Assignee: Sam Tunnicliffe
> Priority: Minor
> Fix For: 3.x
>
>
> It would be useful to authenticate with JMX through Cassandra's internal
> authentication. This would reduce the overhead of keeping passwords in files
> on the machine and would consolidate passwords to one location. It would also
> allow the possibility to handle JMX permissions in Cassandra.
> It could be done by creating our own JMX server and setting custom classes
> for the authenticator and authorizer. We could then add some parameters where
> the user could specify what authenticator and authorizer to use in case they
> want to make their own.
> This could also be done by creating a premain method which creates a jmx
> server. This would give us the feature without changing the Cassandra code
> itself. However I believe this would be a good feature to have in Cassandra.
> I am currently working on a solution which creates a JMX server and uses a
> custom authenticator and authorizer. It is currently build as a premain,
> however it would be great if we could put this in Cassandra instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
