Hi all
The code was written by me. I is hard to find the problem but looking at
the code in
org.geoserver.security.auth.AuthenticationCacheKey
I see the equals(..) implementation comparing strings with == instead of
using String.equals(). Maybe the cache is filled up.
Proposal:
I can send you an AuthenticationCacheKey.class file. You have to replace
this file in the main-<version>.jar file contained in your WEB-INF/lib
folder. (The jar is a zip file, use your preferred zip tool).
After replacement, restart Geoserver and look at the results.
Let me know
Christian
On Wed, Aug 21, 2013 at 9:42 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Mon, Aug 19, 2013 at 10:33 PM, Mike Grogan
> <d.michael.gro...@gmail.com>wrote:
>
>> This looks like it may be getting stuck in a TimerTask
>> in LRUAuthenticationCacheImpl.java that is searching for expired
>> authentication tokens. The stack from the process utilizing 100% CPU is
>> consistently:
>>
>> "Timer-0" daemon prio=10 tid=0x00007f57495e1800 nid=0x6d0e runnable
>> [0x00007f5743546000]
>> java.lang.Thread.State: RUNNABLE
>> at
>> org.geoserver.security.auth.LRUAuthenticationCacheImpl$1.run(LRUAuthenticationCacheImpl.java:66)
>> at java.util.TimerThread.mainLoop(Timer.java:555)
>> at java.util.TimerThread.run(Timer.java:505)
>>
>> In this case, my process id was 27918, which matches the hex 6d0e above.
>> I see this consistently after tomcat restart, though, obviously, the
>> PID/nid changes. Each time, though, the trace for PID/nid returns the
>> TimerTask above.
>>
>> Looking at the source, this is a TimerTask for adding authentication
>> tokens to be removed.
>>
>
> Yep, I noticed. Not sure why this is happening, haven't wrote that code
> myself, but that thing
> just loops over authentication cache keys, my only guess is that they
> might be accumulating faster
> than we can expire them, which might be compatible with a tilecache like
> workload when many
> parallel requests are coming in, under the assumption that each one for
> some reason creates
> a new entry.
> By looking at the code, it seems that might happen if the client does not
> send back the
> _geoserver_security_cache_key attribute...
>
>
>> Do you think this issue goes away once I remove all the authentication to
>> the data layers?
>>
>
> This one seems more related to the client and maybe the fact you're trying
> to authenticate from it?
> I cannot be more precise without spending time in a serious investigation,
> the code in question has been
> written by Justin and Christian (cc'ed) so I'm not familiar with it.
>
> 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
>
> -------------------------------------------------------
>
--
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
------------------------------------------------------------------------------
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
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
