flyweight permissions in server

[mtbc]

What this PR does

Introduces a cache for the Boolean arrays associated with permissions restrictions. Then, the server should not hold on for long to many different arrays that represent the same permissions.

Testing this PR

There should be no CI regressions. Watch for differences in server speed, e.g., running time of integration tests. With #5586 reports from each thread's BooleanArrayCache every fifty minutes can be seen on eel in /opt/hudson/workspace/OMERO-DEV-merge-{deploy,integration}/src/dist/var/log/Blitz-0.log.

Related reading

https://trello.com/c/SXxKgAC3/8-flyweight-permissions-in-server

[mtbc]

Since I opened this PR integration test runtimes may be slightly improved, not much difference really.

[mtbc]

BasicACLVoter.postProcess may warrant investigation regarding http://trac.openmicroscopy.org/ome/ticket/9505#comment:16.

[mtbc]

#309 and #369 add integration testing that I think helps prevent regressions due to my adjustment of copyRestrictions.

[joshmoore]

Having suggested the change, I have no particular issue with having this done, but I do wonder if we have any evidence for or against the performance improvement (time or space) of this change.

[mtbc]

I've not been able to discern any difference outside the error bars of noise, though it might be interesting to have the PR in partly for that it does throw when it detects that the array has been mutated since it last saw it.

[joshmoore]

Have you watched the behavior for a running server? What size is typical for cacheRef? How much churn is there (hits/misses)?

[mtbc]

I have a bit but since forgot I'm afraid! There are certainly some hits. 😃 Want me to open an additional temporary PR that adds some monitoring for those?

[joshmoore]

Could we perhaps get some numbers in a logging statement, perhaps at INFO initially but then can move back to DEBUG?

[mtbc]

When to log? Every many-minutes or something? Maybe we don't have to introduce another config property.

[joshmoore]

Perhaps every 100 modifications or similar?

[mtbc]

Given that a running system seems able to generate thousands of cache hits per second and that logging implies statistics-gathering which means more state that needs concurrency protection, my plan tomorrow is to shift the cache to being thread-local.

[mtbc]

(Of course, the size of the cache is how many misses there were.)

[joshmoore]

Pasted some initial output to gh-5586. Looks good. Knowing that Counter can grow quite large, should counting be disabled if no logging will take place (with the caveat that it would then need to be restarted if logging is enabled at runtime).

[mtbc]

I would say that Counter performs well enough in time and space that it is fine to leave it going regardless of logging.

[mtbc]

Agreeably I am also not seeing any "cache violation" errors being thrown by BooleanArrayCache among eel's server logs.