[
https://issues.apache.org/jira/browse/WICKET-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891032#action_12891032
]
Hudson commented on WICKET-2950:
--------------------------------
Integrated in Apache Wicket 1.4.x #53 (See
[http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.4.x/53/])
> remove final from AbstractHttpSessionStore#getSessionId
> -------------------------------------------------------
>
> Key: WICKET-2950
> URL: https://issues.apache.org/jira/browse/WICKET-2950
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Reporter: Peter Ertl
> Assignee: Juergen Donnerstag
> Fix For: 1.4.10, 1.5-M1
>
>
> Hi wicket devs!
> I am currently working on an own implementation of a wicket failover-safe
> session store.
> I know about
> http://letsgetdugg.com/2010/02/07/clustering-wicket-for-fun-and-profit but
> want to get around the session affinity problem and avoid using the one pass
> rendering strategy.
> There's still some way to go before my implementation could eventually work.
> However I am facing the problem that a critical method in
> AbstractHttpSessionStore is final.
> public ____final____ String getSessionId(Request request, boolean create)
> I am asking you guys if this final could be removed. I don't see much danger
> there or harm that could be done by making this method overridable.
> Currently my approach to clustering is like that:
> For efficiency's sake someone should use sticky sessions.
> Whenever the session changes the delta (only the important parts of the
> session) should be replicated to a memcache instance (other distributed
> storage will work as well).
> When a server dies another server will be called through the load balancer
> and should restore the user's session from memcache.
> I figured out that the best place to restore a previous session would be
> AbstractHttpSessionStore.getSessionId()
> The basic idea is like this:
> MyCustomHttpStoreThatProvidesPrettyFailoverCapabilities.java :-)
> @Override
> public String getSessionId(Request request, boolean create)
> {
> // check if session exists
> String sessionId = super.getSessionId(request, false);
> // no session there, but create required ... this could be a failover
> scenario
> if (sessionId == null && create)
> {
> // save client's requested session id (this should contain the
> id of the lost session before failover)
> WebRequest webRequest = toWebRequest(request);
> String requestedSessionId =
> webRequest.getHttpServletRequest().getRequestedSessionId();
> // create new session
> sessionId = super.getSessionId(request, true);
> // was a previous session id requested?
> if (requestedSessionId != null)
> {
> String oldKey = memcachePrefix + SESSION_PREFIX +
> requestedSessionId;
> FailoverSessionInfo savedState = (FailoverSessionInfo)
> memcache.get(oldKey);
> // check if memcache contains the previous session
> if (savedState != null)
> {
> // store previous session under new session key
> // (currently storing everything as one state
> instance this is very
> // stupid and simple and obviously needs some
> tuning,
> // e.g. storing only the session delta after
> each request, ...)
> memcache.delete(oldKey);
> memcache.set(memcachePrefix + SESSION_PREFIX +
> sessionId, Integer.MAX_VALUE, savedState);
> HttpSession httpSession =
> webRequest.getHttpServletRequest().getSession(false);
> // restore http session from failover storage
> for (Map.Entry<String, Serializable> entry :
> savedState)
>
> httpSession.setAttribute(entry.getKey(), entry.getValue());
> }
> }
> }
> return sessionId;
> }
> So I would really beg you to remove [final] from
> AbstractHttpSessionStore.getSessionId(..) in 1.4.x and 1.5.x :-)
> Best Regards
> Peter
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
