I’m having hard time managing sessions with GAE/J and VAADIN. Facing two problems:
session is persisted in datastore between requests which gives hard limit of 1MB per session. our startup session is 700K, you can imagine that we can hit that limit pretty soon.
this definitely becomes performance issue. datastore/memcache session writes cause sometime significant delay which degrades user experience. as a workaround I customizes Vaadin GAE servlet and enforced only async datastore writes instead. this solves the performance problems, but compromises the application state. as a result I sometimes get out of sync screens detecting stale state.
Anyone having similar problems? Or give a solution hint?
It’s been a while since I last looked at GAE, but AFAIK these are the limitations that make GAE less that ideal. When using GAE, you should make sure to keep your session as small as possible, and especially not keep containers and data in memory. One thing that you could do, since Vaadin serializes the application state on its own, is customize it to use multiple blobs for one session - this will not help with your performance issues, though.
I do not recommend the async write, since synchronization can not bee guaranteed. The thing that would help, that we have been hoping for is if GAE would implement ‘sticky sessions’, so that one session would be guaranteed to stay on one server - but I wouldn’t hold my breath (They still have not done this, right? I have not been tracking developments lately…)
thanks for the fast response. Indeed sticky sessions would be perfect solution, I guess that’s what we all need when it comes to VAADIN + GAE. Unfortunately I didn’t see anything scheduled in this direction. The only solution that comes to my mind is to run AlwaysOn backend that serves in-memory sessions. performance would be dependent of network latency and it needs to be tested of course. any other ideas? I will try to update the thread if anything new comes up.
the solution is to lazy load the UI components bound to a “page” on fragment changed event. this solution involved substantial amount of refactoring, but at least works. Hopefully this gives a hint to someone stuck on the same problem.
That is a little ugly, but now that the work is done you’re better off for it. It’s good to keep the sessions as small as possible, especially in case your app ever hits the “big time” and you move to some highly available server architecture. In this case, with each request/response, the session is serialized and replicated to some other server to be safe. You’d like that to go quickly!
If you have any tips beyond what’s in the link, feel free to share. Someone has mentioned clearing listeners from components before removing them, but I haven’t looked into that yet.
I’d like to summarize some of our findings besides what Alex had already mentioned.
In the initial application design we were “emulating” tab sheet - a custom layout with “placeholders” where different application pages were placed. All the content were created at once and switching through pages were implemented by showing/hiding certain page. During the refactoring, we only left one “placeholder” and only one page was included at a time. Besides that, we had to remove all application scope listeners (for example transaction listeners), whenever a “page” was detached.
When a page is removed, no references to it should be kept in the TopLevel view/window/application. This is done by overriding the detach method for each page and removing listeners (transaction and fragment change listeners in our case).
To track the session size we used our own version of com.vaadin.terminal.gwt.server.GAENoMemcacheSessionApplicationServlet, which was dumping the session size in bytes after serialization. This way we could track down if there is a leak when we switch through pages in the UI.
