Hi Dmitry, the memcached-session-manager (http://code.google.com/p/memcached-session-manager/ ) is a tomcat session manager that was created with two major goals in mind: minimal impact on performance + scalability.
Optimal performance: can only be reached if you don't do any I/O for a request. Scalability: Just put more tomcat/memcached nodes and that's all for scaling out. The solution for the performance goal was, that when a request is handled, the local (in memory) session should be used, and when the request is finished the session is sent asynchronously to memcached (actually you can also do this sync). This solution was appropriate, as wicket is told to work best with sticky sessions. Still, technically it's possible to use the memcached-session-manager (msm) with a non-sticky configuration, so that the session is pulled from memcached for each request (that accesses the session). You just should tell msm to store sessions synchronously at the end of the request. For non-sticky sessions of course you need to keep concurrent session access (ajax requests, multiple windows etc.) in mind. Also, be aware that you can't use wicket's default mode REDIRECT_TO_BUFFER. Perhaps you'd want to ask others here on the list what their experiences are with non-stickyness + wicket. Cheers, Martin On Thu, 2010-05-27 at 20:40 -0700, DmitryM wrote: > Hello, guys > > I need your advice for the following case. > The Wicket application I'm working on is supposed to be deployed to Amazon > EC2 cloud. This way standard Tomcat (used as a webapp container) clustering > won't work (cloud doesn't accept multicasts). There is a third-party session > manager available for Tomcat but it still needs sticky sessions from the > load balancer (which is not conceptually good for app scaling). if you're referring to the memcached-session-manager here (http://code.google.com/p/memcached-session-manager/ ), I have to say that it turned out that you should be able to use this even with non-sticky sessions. > I tried Hazelcast distributed data support (which allows for TCP unicasts) > as a PageStore implementation (thanks this blog post: > http://wicketbyexample.com/apache-wicket-clustering-with-multiple-options/) > It works fine but needs session clustering (though Hazelcast makes PageStore > available for each webapp instance already which seems to be an overhead. > And I would like to use Hazelcast alone for this kind of 'clustering'). > > My question is about non-sticky sessions w/o clustering. I can try to extend > SecondLevelCacheSessionStore to get the PageStore/page map etc. from > Hazelcast and stick it to a newly created session (when load balancer > forwards a request to the server which is different from the session's > original server). > > But do I need to try to transfer something else except for the PageMap to > the fresh session (the webapp doesn't store anything in the Http session > directly)? > > I mean, does Wicket store anything else for its functional purposes in the > Http Session (which I may need to distribute via Hazelcast)? > > Thanks, > Dmitry -- Martin Grotzke http://twitter.com/martin_grotzke
signature.asc
Description: This is a digitally signed message part
