-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
SessionManager: Allow backend storage to be configurable #481
base: master
Are you sure you want to change the base?
Conversation
This allows using the built-in session feature without having to use the CacheMap, which is limited to the current process and not suitable in larger deployments.
@DarkLordZach Thanks so much for the patch. this is very helpful for multiple pods scenarios. |
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.
@DarkLordZach Thanks so much for your pull request. Besides the same question @an-tao already asked, which I would like to clarify before this gets merged into master
, this changeset LGTM.
I currently don’t have a Redis instance running outside of production environments, and would’ve to set up an environment to test the framework behavior on this branch by myself.
@@ -547,6 +557,7 @@ class HttpAppFrameworkImpl : public HttpAppFramework | |||
size_t clientMaxWebSocketMessageSize_{128 * 1024}; | |||
std::string homePageFile_{"index.html"}; | |||
std::function<void()> termSignalHandler_{[]() { app().quit(); }}; | |||
std::function<std::unique_ptr<SessionStorageProvider>(trantor::EventLoop*, size_t)> sessionStorageCreator_{createCacheMapProvider}; |
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.
std::function<std::unique_ptr<SessionStorageProvider>(trantor::EventLoop*, size_t)> sessionStorageCreator_{createCacheMapProvider}; | |
std::function<std::unique_ptr<SessionStorageProvider>( | |
trantor::EventLoop*, size_t)> sessionStorageCreator_{createCacheMapProvider}; |
if (!provider_->findAndFetch(sessionID, sessionPtr)) | ||
{ | ||
sessionPtr = std::make_shared<Session>(sessionID, needToSet); | ||
provider_->insert(sessionID, sessionPtr, timeout_); |
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.
If the provider_ is created for redis, how do we store the sessionPtr to the redis server?
And as the session object (sessionPtr) can be accessed by users via Http Request objects, how do we synchronize its changes to the redis server?
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.
I think we have to make the Session class as a pure virtual class for different implementations of memory storage or redis storage. But how to deal with the template and the any
?
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.
Protobuf for session fields serialization/deserialization?
@an-tao , Yes, using an asynchronous interface with std::future does seem much better, I didn't do that because I was trying to change as little code as possible. I can fix that today. |
@DarkLordZach Thanks for your reponse. |
@DarkLordZach If we use std::variant instead of std::any, does that mean we can only store data of some predefined types to sessions? This seems to increase the constraints on the type of data stored in sessions. |
Yes, but the problem with |
You are right, the current API only suitable for memory storage. |
At this point of development API breaking changes should be prioritized lower in my opinion, so that it would be OK to change the API. But I think we should find a better solution and strive towards getting the best one for a plain memory storage and key-value stores like Redis at the same time, not find a compromise that will hinder the design and usage of one or the other. The current API is beneficial for plain memory storage as it is as flexible as possible. Changing the API to I wonder how often you’ve a case that it is necessary to provide a “drop-in” replacement for plain memory storage? From my experience it is rather clearly defined what gets stored in a session and what in a key-value store. In this case we could maybe decouple both APIs, keep |
This allows using the built-in session feature without having to use the CacheMap, which is limited to the current process and not suitable in larger deployments.
In my use case of drogon, I am running multiple pods behind a single load-balancer, so the built-in session handler won't work without sticky load balancing, which isn't feasible and is more of a bandaid fix. This allows the user to optionally specify their own implementation of backing storage, for example using redis. By default, CacheMap is used and current usages should require no changes, it is opt-in only.