You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :)
The text was updated successfully, but these errors were encountered:
@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).
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).
XPackLicenseState
synchronizes access to the internalStatus
, which was probably sufficient in the past since calls to variousisFooEnabled()
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 aPutWatch
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 makingstatus
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 :)The text was updated successfully, but these errors were encountered: