On Sun, Apr 10, 2011 at 7:31 AM, Andrea Aime
<[email protected]>wrote:
> Hi,
> following up a report of GeoServer creating thousands of http sessions
> during "normal" operation I've built a tool to investigate the session
> creations and a patch that solves the session creations I've noticed.
>
> The tool is a servlet filter that wraps the HttpServletResponse and
> logs the full stack trace of every call forcing the creation of a http
> session. It is included in this patch:
> http://jira.codehaus.org/browse/GEOS-4478
>
> About the tool, it's quite handy in that it would allow someone else
> to also do this kind of debugging, on their own servers.
> I'm just undecided on how to integrate it:
> a) ship it in the code, but comment out its declaration in web.xml
> Whoever needs it just had to hand modify the web.xml to activate it
> b) ship it in the code and have it statically declared in the web.xml,
> and use a system variable to actually make it wrap the servlet
> request (otherwise make it a no-op)
> c) ship it and have it always on, any session creation outside of
> the web UI is something we want to be informed of asap anyways
>
Seems pretty useful. I don't have a strong opinion about how to integrate
it. (c) seems good but I wonder if the start of a new session should be
logged as INFO in the web case? Perhaps FINE seems more appropriate for that
case since it is a normal occurrence? Logging at INFO for the non web ui
case seems well warranted though.
>
> I'm tempted to go c), even when wrapping the tool is quite light
> unless there is indeed a session creation going on...
> how do people feel about this?
> Can someone double check/review the patch at
> http://jira.codehaus.org/browse/GEOS-4478
>
> The other part of the work is the actual fix, using the tool I've found
> a couple of unexpected session creations, both due to the Spring Security
> integration not behaving quite like I hoped:
> http://jira.codehaus.org/browse/GEOS-4477
>
> Recently some of our client side folks have been working on authentication
from javascript apps using some of the current geoserver auth logic... not
sure if this patch affects that at all. I will work with Tim to try and test
this out to see if the patch changes anything.
> The patch fixes the issues I've seen and should result in greater
> scalability for applications that are using secured data layers and
> the "www" folder.
> However the testing I've made is quite on the light side (checked with some
> secured layers)... we'd need someone heavily using security to confirm the
> changes are not breaking anything else. Any takers?
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 333 8128928
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
