On Mon, May 28, 2012 at 12:43 PM, Andrea Aime
> On Mon, May 28, 2012 at 7:57 PM, Justin Deoliveira <jdeolive@...>
> > Given that I have not heard anyone complain about this I feel stating
> > it makes the GUI "unusable" is an overstatement. That code has been in
> > for years. Although admittedly i don't monitor the user list, irc, and
> > 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
> 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.
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 339 8844549
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.