Hello,
We had/have on a production machine the same issue.
Following the discuss we looked into the implementation of
LRUAuthenticationCacheImpl
The origin of the problem is not clear but the result is only one loop over the
keys.
LRUAuthenticationCacheImpl. Some addional logging is also added but could be
removed
The changed snipped follows
----
TimerTask removeExpiredTask = new TimerTask() {
@Override
public void run() {
LOGGER.fine("Start searching for expired authentication tokens");
writeLock.lock();
try {
int removed = 0;
long currentTime=System.currentTimeMillis();
if (cache.size() > 50) LOGGER.info("AuthKey Cache entries: " +
cache.size());
Iterator<AuthenticationCacheEntry> iter =
cache.values().iterator();
while (iter.hasNext())
{
if (iter.next().hasExpired(currentTime))
{
iter.remove();
removed++;
}
}
LOGGER.fine("Number of expired authentication tokens found: " +
removed);
} finally {
writeLock.unlock();
}
LOGGER.fine("End searching for expired authentication tokens");
}
};
Op 22/08/2013 11:58, Andrea Aime schreef:
On Thu, Aug 22, 2013 at 11:52 AM, Christian Mueller
<[email protected] <mailto:[email protected]>>
wrote:
Hi Andrea
The problem is that most cache implementations have global expire time
settings. We need global expire times as default but it must be possible
to assign expire times to individual entries. As an example, digest
authentication has its own expire times and it does not make sense if the
cache has expire times larger than the configured expire times of the
digest authentication filter. A cache entry created by digest
authentication has expire times limited by the digest authentication
configuration.
The cleaner thread is here to guarantee that an unused authentication
token is not cached for a long time period, this is a security risk.
I am thinking about using Collections.synchronizedMap(..) and to kick out
all the locking stuff.
Ugh, it would limit scalability quite a bit. The Guava CacheBuilder should be
a much more performant solution.
Once built you can treat it as a regular map, it handles LRU and concurrency
internally.
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Eric Smets [email protected]
FKS bvba - Formal and Knowledge Systems http://www.fks.be/
Schampbergstraat 32 Tel: ++32-(0)11-21 49 11
B-3511 Hasselt Fax: ++32-(0)11-22 04 19
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
