Hi Mike
geoserver_security_cache_key is for internal use only.
About your bash scripts. Can you reproduce the race condition using basic
auth (standard) and the Geoserver demo data. If you can, it would be nice
if you can send me these scripts.
Cheers
Christian
On Wed, Aug 21, 2013 at 4:04 PM, Mike Grogan <d.michael.gro...@gmail.com>wrote:
> I see the same thing as Andrew on 2.3.3 and 2.3.4
>
> I would be willing to swap the class file and give it a try if you want,
> Christian, though I just see your e-mail voting yourself -1 ... thinking
> existing code was ok.
>
> At first, this seemed almost random. It was happening really with close
> to 0 load on the geoserver. It was just me on a development box zooming
> and panning my map. Of course, in my case, my Google maps-based client did
> make multiple simultaneous requests to load tiles from the gwc gmaps
> service, but just a few at a time. It seemed that, if I hit it just right
> (or wrong, I guess) in making new requests, it would lock up. Sometimes
> this was even after everything had been idle with no requests at all for
> many minutes or more. I could initiate new requests after none had
> happened for a while and, bam, 100% cpu use and no response from gwc
> instantly. This is what made this seem like a race condition ... I would
> have to hit stuff just at the right time it seemed to make it happen.
> Sometimes I could get this to happen within a few minutes ... sometimes it
> would take me an hour or so to make this happen.
>
> So, I wrote some crude bash scripts that would make about 30 simultaneous
> requests continuously via wget. With this, I can often (but not always)
> get the 100% cpu lockup from LRUAuthenticationCacheImpl within 2 minutes.
> This sort of suggests to me that this problem is occurring whenever there
> is an incoming request happening at the exact instant with the TimerTask
> firing. I haven't dug through the code enough to prove this, but that is
> what it feels like.
>
> While Andrew has seen this with header proxy authentication, I have seen
> it with both basic and authkey plugin authentication, though it seems to be
> more reproducible with the authkey.
>
> Andrea speaks of having the client return geoserver_security_cache_key.
> Can you provide a bit more info? What would you expect the client to
> provide back to geoserver? Especially in the authkey case where it's one
> request and done.
>
> Thanks,
>
> Mike Grogan
>
>
>
>
> On Wed, Aug 21, 2013 at 8:14 AM, Christian Mueller <
> christian.muel...@os-solutions.at> wrote:
>
>> 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
>>
>>
>
--
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
