-
Notifications
You must be signed in to change notification settings - Fork 38
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
token-cache-PLT-19 #19
Conversation
…ntry was not present before.
…ith correct init values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
It passes tests
Dialyzer is happy :)
I am not sure about indentations, but lets check and fix that later. Looks Ok at a quick glance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of things to make it follow general OTP patterns a bit better
…l, oauth2c_token_cache should now be started through its supervisor.
…n time of a running oauth2c_token_cache GenServer.
b47d648
to
2a1e44c
Compare
e1df3be
to
dac7b7c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's try this out.
I have added a GenServer which is responsible for managing cached tokens. The API of oauth2_client has not changed, it is identical to what it was before. Whenever an application invokes retrieve_access_token, the function first checks whether the caching GenServer (oauth2c_token_cache_gen_server) is running and if this is the case it will first check in the cache before trying to fetch a new token. There should be no breaking changes since if the caching GenServer is not running, retrieve_access_token should work exactly as before. However, applications that want to utilize the caching mechanism needs to start the GenServer responsible for the caching. By default, a cached token is saved for 1 hour before being discarded. However, it is possible to specify the expiration time when starting the caching GenServer.
UPDATE:
The cached tokens are stored in a ETS-table which can be concurrently read by multiple processes and thus avoiding the "single process botlleneck" which existed in the previous implementation that only allowed the GenServer process to read and write the cache. The new implementation also handles "bursts" better than the previous implementation. If multiple concurrent requests for the same key to an empty cache would be performed in the old implementation, it is possible that several processes would have asked the remote provider for a token that would later be cached. In the new implementation, only a single process would ask the remote provider for a token and all other concurrent request would use the token returned to the single requesting process from the remote token provider.
For instance, if multiple token requests are made concurrently for the same key to an empty cache; only a single of those requests will ask the remote provider for a token and the rest will use the cached one.