relay api key #805
relay api key #805
Conversation
| @@ -87,6 +88,10 @@ type BGS struct { | |||
|
|
|||
| // Management of Compaction | |||
| compactor *Compactor | |||
|
|
|||
| apiKeys atomic.Pointer[ApiKeys] | |||
There was a problem hiding this comment.
Is there a reason we use this instead of a lock?
There was a problem hiding this comment.
We don't use these atomic semantics anywhere else and I'm a bit wary of throwing them in here now over using a standard mutex pattern.
There was a problem hiding this comment.
Ideally atomics are faster; there are a few large system NUMA cases where they are less good than usual, but I'm not sure they're ever slower than sync.Mutex ? I think in the optimistic case where there is no contention they're much faster.
They don't provide fairness of unlock to multiple lockers like sync.Mutex, but that doesn't matter here.
|
The good news is that I can demonstrate that it works. With no setup, works as present, no api key needed. With api key set uploaded, can set threshold priority up and down and allow/disallow various api keys (or unkeyed access). The messy news is that it is currently stateless and I should do more work to add it to the local database. Otherwise the API keys need to be re-uploaded after any reboot. |
in case we need to play favorites to keep the system up, allow API keys with multiple tiers of priority and the ability to shed lower levels