Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove use of synchronization in XPackLicenseState? #45819

Closed
polyfractal opened this issue Aug 21, 2019 · 4 comments
Closed

Remove use of synchronization in XPackLicenseState? #45819

polyfractal opened this issue Aug 21, 2019 · 4 comments
Labels
>refactoring :Security/License License functionality for commercial features team-discuss

Comments

@polyfractal
Copy link
Contributor

XPackLicenseState synchronizes access to the internal Status, which was probably sufficient in the past since calls to various isFooEnabled() methods were infrequent. But the surface area of xpack features is growing, and we are beginning to introduce features which will require frequent checks. E.g. imagine a licensed aggregation, which needs to be checked on each execution. This could be a lot more frequent than checking during a PutWatch for example.

The caller can cache the value locally with a cluster state listener (that's the path I took on a recent PR), but it would perhaps be better solved centrally instead of having each caller reinvent the same caching behavior?

I only skimmed, but it looks like the status object is always re-assigned, and only updated by LicenseService so making status volatile and dropping synchronization on getters would probably work. Volatile always scares me though :) Maybe protect it with a RWLock or similar?

Not trying to over-engineer it, but the synchronized behavior concerns me moving forward :)

@polyfractal polyfractal added >refactoring :Security/License License functionality for commercial features team-discuss labels Aug 21, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@jasontedor
Copy link
Member

@polyfractal This came out of a conversation between me and @jaymode last year. See the resulting PR #33396. Note too that security already reads the license state on every action (cf. SecurityActionFilter).

@jasontedor
Copy link
Member

My thoughts are that given that we haven't seen any reports of performance-related issues from the usage in SecurityActionFilter (which hits every action, not just every request), that anything we do here would be premature optimization). I don't think we need caching, and if this turn out to be problematic, we can certainly consider alternatives such as a read-write lock. For now what we have is relatively simple to reason about and doesn't appear to be harmful (everything that happens under a lock here is extremely cheap).

@polyfractal
Copy link
Contributor Author

Makes sense to me especially in light of SecurityActionFilter, thanks for the explanation. Closing! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>refactoring :Security/License License functionality for commercial features team-discuss
Projects
None yet
Development

No branches or pull requests

3 participants