PS: I'll be writing and using JMH benchmarks to drive these changes. I'll also create new unit tests for each of these classes that don't currently have unit tests.
On Thu, Mar 30, 2017 at 10:58 AM, Kirk Lund <kl...@apache.org> wrote: > The client Commands now check with SecurityService even when security is > not configured. This has introduced a negative performance impact. > > The best way to fix something like this is to tell the Command instance > when it's being constructed that is does or does not need to perform > security checks. > > Unfortunately, Commands are all implemented as singletons which are very > eagerly instantiated during class loading of CommandInitializer (who > thought that was a good idea?!). > > In order to fix this performance problem, I would need to get rid of these > problematic static initializer blocks that so eagerly construct the > Commands so that I can put off constructing them until AFTER the Cache is > initializing and specifically AFTER the Cache has determined if it is using > security or not. > > This means I'm going to have to do some refactoring of CommandInitializer, > the Command classes, ServerConnection, AcceptorImpl, etc. > > Any other approach is going to have such minimal impact on performance > that I'm not even interested in doing less than this. > > From a very high level, I would change the code so that the Cache owns the > Server which owns the Command instances. In this way, the configuring of > use of security can trickle down from Cache to each Command. I would > primarily be altering static singletons, static initializers and adding > constructors. > > Does anyone have a problem with me changing the above classes and > especially getting rid of the static initializers and singleton instances? > >
