geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kirk Lund (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-2632) Integrated Security performance improvements
Date Fri, 09 Jun 2017 21:44:18 GMT

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

Kirk Lund commented on GEODE-2632:
----------------------------------

I reverted the change on release/1.2.0 but kept it on develop. We have lots of changes merging
to develop that require my changes. I'm going to file new Jira tickets for both #1 and #2
as described below. I'm currently working on #1 below which is a temporary fix. 

>From dev@geode.apache.org:

The new changes for SecurityService don't work with Cluster Config. We only had one test that
would've failed but it was annotated with @Ignore.

The problem is this:

The security-manager is a gemfire property and is now used by the InternalDistributedSystem
because membership needs SecurityService to handle peer-to-peer authentication. So with my
changes, the InternalDistributedSystem now creates SecurityService and passes it into the
constructor of GemFireCacheImpl.

Next, GemFireCacheImpl#initialize requests Cluster Config. If this is a new Server with no
gemfire properties, it will have already joined the Cluster (before and after my changes).
It then gets Cluster Config that has gemfire.properties including security-manager. But it's
too late, the immutable SecurityService has already been created by InternalDistributedSystem.

In theory, Cluster Config should be requested before the creation of InternalDistributedSystem
so that other gemfire.properties in Cluster Config can be applied (such as member-timeout).
In fact most of the gemfire.properties control aspects of InternalDistributedSystem. Presently,
all gemfire.properties that would configure InternalDistributedSystem are ignored because
Cluster Config is loaded after InternalDistributedSystem was created and the member has joined
the cluster.

We would need to make one of these changes:

1) GemFireCacheImpl creates its own SecurityService which is different from the one used by
membership. Locators are the only members that really need membership to have a fully configured
SecurityService (and I think we already have a bug in which 2nd Locators need to be manually
configured rather than use Cluster Config).

2) Move Cluster Config request from GemFireCacheImpl to InternalDistributedSystem. This is
actually more correct, since Cluster Config is potentially going to contain a lot of InternalDistributedSystem
configuration options that are currently ignored (in both Geode 1.x and current develop).

Unfortunately #2 is a fairly big refactoring change.

We should probably revert my changes from develop and 1.2 until #1 or #2 can be completed.
Or we have to file a bug that says Cluster Config and Security don't play nice together until
we can complete one of these options. I think the latter is probably not acceptable.

> Integrated Security performance improvements
> --------------------------------------------
>
>                 Key: GEODE-2632
>                 URL: https://issues.apache.org/jira/browse/GEODE-2632
>             Project: Geode
>          Issue Type: Improvement
>          Components: security
>            Reporter: Jinmei Liao
>            Assignee: Kirk Lund
>              Labels: performance
>             Fix For: 1.2.0
>
>
> There is a security check in Put65.cmdExecute() that, if removed, improved the performance.
> The expense of this security call needs to be reduced in order to get the performance
back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message