search

CandyShop / gerrit

Automatically exported from code.google.com/p/gerrit
Apache License 2.0
1 stars 0 forks source link

Web sessions expire before 12 hour timeout #265

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by code-rev...@gtempaccount.com on 24 Sep 2009 at 7:44

GoogleCodeExporter commented 9 years ago 
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.

Original comment by code-rev...@gtempaccount.com on 24 Sep 2009 at 8:41

GoogleCodeExporter commented 9 years ago 
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.

Original comment by code-rev...@gtempaccount.com on 24 Sep 2009 at 8:42

GoogleCodeExporter commented 9 years ago 
Update by Shawn Pearce <sop@google.com> on Wed Sep 02 18:13:50 PDT 2009

Fixed in version 2.0.21.

Original comment by code-rev...@gtempaccount.com on 24 Sep 2009 at 8:42

GoogleCodeExporter commented 9 years ago

Original comment by code-rev...@gtempaccount.com on 25 Sep 2009 at 2:59

GoogleCodeExporter commented 9 years ago

Original comment by sop@google.com on 22 Oct 2012 at 3:56