My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 265: Web sessions expire before 12 hour timeout
  Back to list
Status:  Released
Owner:  code-rev...@gtempaccount.com
Closed:  Oct 2012


Sign in to add a comment
 
Reported by code-rev...@gtempaccount.com, Sep 24, 2009
Reported by Shawn Pearce <sop@google.com> on Mon Aug 24 14:51:14 PDT 2009
Source: JIRA GERRIT-266
Affected Version: 2.0.19

I'm seeing my web session timeout much more rapidly than it should.
review.source.android.com uses a 12 hour session timeout, which is the
default, yet I've seen a session only a few hours old timeout with an invalid
xsrfKey error (see GERRIT-265).  I think Ehcache is killing cache entries,
even though the cache is not yet full, and the timeout has not yet been
reached.
Sep 24, 2009
#1 code-rev...@gtempaccount.com
Comment by Shawn Pearce <sop@google.com> on Tue Aug 25 08:46:48 PDT 2009

I think I've tracked this down to a misconfiguration of Ehcache.

web_sessions is by default sized at 1024, but on at least one server I've
increased memoryLimit to 4096.  Gerrit configures Ehcache to always use the
LFU eviction policy, which kills the entry with the lowest hit count when the
cache decides to evict something.  However, when the cache size is "fairly
large", where "fairly large" is >100 buckets in the hash, and both 1024 and
4096 are over that limit, Ehcache takes a random sampling of the elements to
perform the eviction against.  Since the sample is random, there is a
possibility that a reasonably live session can fall into the random sampling,
and get voted out.

I still haven't quite figured out why with a cache of 1024 elements allowed in
memory and about 100 elements actually present according to the cache
statistics shown in "gerrit show-caches" Ehcache is deciding to do an eviction.

For web_sessions we may want to change our cache policy to LRU, and we may
want to use LruMemoryStore rather than the default MemoryStore, since it
provides a stronger LRU policy by always updating the LRU chain on each
access, instead of taking a randomly sampled approximation.
Sep 24, 2009
#2 code-rev...@gtempaccount.com
Comment by Shawn Pearce <sop@google.com> on Wed Sep 02 18:13:44 PDT 2009

This might be fixed by I6e2e67d4e7f0bb2131005627a1e0d446d9990b60, which at
least moves to an LRU based store.  But it may really turn out to be the case
that we can't trust Ehcache with something like this, because I still suspect
they are evicting earlier than they should be given the idle timeout we have
configured.
Sep 24, 2009
#3 code-rev...@gtempaccount.com
Update by Shawn Pearce <sop@google.com> on Wed Sep 02 18:13:50 PDT 2009

Fixed in version 2.0.21.
Status: Fixed
Sep 25, 2009
#4 code-rev...@gtempaccount.com
(No comment was entered for this change.)
Labels: FixedIn-2.0.21
Oct 21, 2012
#5 sop@google.com
(No comment was entered for this change.)
Status: Released
Sign in to add a comment

Powered by Google Project Hosting