Hi Gabriel, Sure thing. I'll reopen the issue and assign to myself. Thank's for spotting this.
Cheers Rini -----Original Message----- From: Gabriel Roldan [mailto:[email protected]] Sent: Tuesday, 15 September 2009 11:36 AM To: Justin Deoliveira Cc: Geoserver-devel; Angreani, Rini (E&M, Kensington) Subject: Re: [Geoserver-devel] GML3EncodingUtils.idExists performance impact thaaat's what I call a satisfactory answer :) Rini, see how FeatureTypeCache is used in WFSConfiguration.configureContext As Justin suggested, the same way you can register a new instance of, say, IdLookUp in GMLConfiguration.configureContext and have AbstractFeatureTypeBinding take an extra constructor argument of type IdLookUp (if my understanding is correct the picocontainer will take care of passing over the constructor argument as long as it's registered by GMLConfiguration) Then IdLookUp might be something like: class IdLookUp{ ... boolean idExists(String gmlId){...} void add(String gmlId){...} } May you have time to do that so we fix the perf penalty? (Justin please confirm my above suggestion is correct) Cheers, Gabriel Justin Deoliveira wrote: > Even though the Configuration object is a singleton in geoserver > (hopefully fix that someday), the binding context is not stored as a > member of it, it is created by the encoder and passed into > Configuration.configureContext(). So as long as two processes are not > storing the same encoder instance as state there should be no problem. > > Gabriel Roldan wrote: >> That'd be a good solution to provide a context to the gml encoding >> process, my open question is now how to ensure that context is not >> shared between encoding processes, as the list of ids is to be checked >> independently for each one. My understanding is FeatureTypeCache is >> shared and that's ok, but this one may require a per process >> "context". What do you think? >> >> Justin Deoliveira wrote: >>> Hmmm... well one possibility might be to use a similar solution as >>> FeatureTypeCache. Each time the encoder stats, the container context >>> gets a FeatureTypeCache instance which basically serves as a cache >>> for feature type objects, used while parsing features to avoid >>> creating the feature type over and over again. >>> >>> A similar class could be used ot track ids during encoding. >>> GMLConfiguration.configureContext could register it, and then >>> whatever binding (AbstractFeatureTypeBinding or whatever) could >>> declare a dependency on it, grab the instnace and check for or update >>> the set with encoded ids. >>> >>> The downside being that for huge feature collections the set could >>> get quite large... but i guess its better than the current solution >>> of building up a document full of ids. >>> >>> Gabriel Roldan wrote: >>>> Hey Justin, >>>> >>>> when you have a chance please take a look at the comments in >>>> <http://jira.codehaus.org/browse/GEOT-2627>, as >>>> GML3EncodingUtils.idExists() is making the gml encoding process >>>> almost twice slower and I would love you opinion on the proposed >>>> workaround >>>> >>>> Cheers, >>>> Gabriel >>> >>> >> >> > > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
