On Mon, May 28, 2012 at 12:43 PM, Andrea Aime
<[email protected]>wrote:
> On Mon, May 28, 2012 at 7:57 PM, Justin Deoliveira <[email protected]>
> wrote:
> > Given that I have not heard anyone complain about this I feel stating
> that
> > it makes the GUI "unusable" is an overstatement. That code has been in
> place
> > for years. Although admittedly i don't monitor the user list, irc, and
> jira
> > as closely as others.
>
> I had to go through 25 shapefile layers to do manual changes on some HTTP
> headers setup, each save took its own 5 seconds, during which the GUI
> could not be used in other tabs also due to the lock protecting the GUI
> from concurrent changes (which means you cannot do anything in another
> tab either).
> I'm quite sensitive to slowdowns and delay, so this makes the GUI unusable
> for me (personal feeling, I understand it).
>
Right, my point was that this isn't really the "typical" use case. But i
totally understand, and am fine with the change I just think that any
changes to the configuration serialization subsystem (no matter how small)
can lead to subtle changes in behaviour, etc... and probably warrant a bit
of discussion before hand.
>
> > Well i am happy to try to help come up with the patch. I don't know the
> > referencing system very well but my idea was just a simple fixed sized
> > thread safe set that kept recently looked up CRS objects around. Then in
> > CRS.lookupEpsgCode when the fast path fails scan through the second level
> > cache and do the comparison. If that fails fall back to the full scan. If
> > that sound sane I will proceed. One question i have is whether the second
> > level cache should be used when fullScan = false?
>
> Actually, why not go through the cache first?
>
> I was actually wondering if the cache should not be better placed in
> the GeoServer own configuration subsystem, and automatically filled
> on startup with the associations that the admin already made in the
> existing config, that would kill also the first lookup most of the time
>
> Ah, another bit, the cache in GT would need to be wiped out when the admin
> does a reset/reload anyways as part of the CRS.reset("all") call, one
> in GeoServer
> may not have to abide to the same issues, or at least could be refilled by
> the
> existing associations during the reload).
>
Makes sense. A cache at the geoServer level makes sense... although given
that calling this method with the extensive flag set is such a no-no
performance wise it would be nice to have it at the core gt level. Anyways,
no sense in worrying about this now but will flag this email in case I do
have to revisit it.
>
> 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 339 8844549
>
> 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
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
