OK sure. Cheers Rini
-----Original Message----- From: Gabriel Roldan [mailto:grol...@opengeo.org] Sent: Friday, 10 July 2009 2:41 PM To: Angreani, Rini (E&M, Kensington) Cc: Caradoc-Davies, Ben (E&M, Kensington); geotools-devel@lists.sourceforge.net Subject: Re: [ExternalEmail] Re: [Geotools-devel] app-schema build time/mem Hi Rini, I can do that right away but there's a gotcha. I got a single test failing that I'm finding myself unable to fix: AppSchemaDataAccessIntegrationTest. Problem seems to be that it references mineralOccurrence.xsd but it doesn't import Gsml.xsd and hence GeologicUnitType can't be found. I'm not sure why it worked before though cause the logic didn't essentially changed. May be if I commit you'll be able to assess it? (as it extends DataAccessIntegrationTest but I'm not sure exactly what for, other than to reuse the fake DataAccess on it?) What I did is the following: I decoupled the xsd to EMF and EMF to GeoTools parsing so that they're the responsibilities of different classes. So I like the separation of concerns more that way. EmfAppSchemaReader now only cares about parsing the schemas into SchemaIndex. The new class FeatureTypeRegistry takes them to parse the EMF objects on demand. This means not all the types and elements are parsed to geotools objects but only the needed ones, decreasing the memory usage lot. From 255m to 52m for FeatureChainingTest, for example. I can build now with 256m in 59 seconds. I think with that and your <schemaUri> magic we should be more than good. But certainly I didn't have time to test that on the wild (ie, with geoserver). Are you still going to let me commit? Cheers, Gabriel rini.angre...@csiro.au wrote: > It seems that way. > Go ahead and commit your changes first. We have the whole day here still. > > Cheers > Rini > > -----Original Message----- > From: Gabriel Roldan [mailto:grol...@opengeo.org] > Sent: Friday, 10 July 2009 2:16 PM > To: Angreani, Rini (E&M, Kensington) > Cc: Caradoc-Davies, Ben (E&M, Kensington); > geotools-devel@lists.sourceforge.net > Subject: Re: [ExternalEmail] Re: [Geotools-devel] app-schema build time/mem > > That's cool, so it seems that way it uses the Oasis catalog? > > btw, I'm about to get ready a patch to get the resource consumption even > lower, but am afraid of getting too much conflicts with your changes. Do > you think you can commit the test refactorings relatively soon? > > Cheers, > Gabriel > > rini.angre...@csiro.au wrote: >> I think I found the culprit. >> I refactored a bunch of tests to run the set up once, it got faster, but not >> enough. >> Then I changed all the test mapping files to point to: >> <schemaUri>http://schemas.opengis.net/GeoSciML/geosciml.xsd </schemaUri> >> Instead of the local schemas in test-resources. >> >> Now I can run all gt-app-schema tests with 256 M :D. >> I will make sure I didn't break any geoserver app-schema tests before I >> commit. >> >> -----Original Message----- >> From: Gabriel Roldan [mailto:grol...@opengeo.org] >> Sent: Friday, 10 July 2009 11:54 AM >> To: Caradoc-Davies, Ben (E&M, Kensington) >> Cc: Angreani, Rini (E&M, Kensington); Geotools-Devel list >> Subject: Re: [ExternalEmail] Re: [Geotools-devel] app-schema build time/mem >> >> Ben Caradoc-Davies wrote: >>> Ben Caradoc-Davies wrote: >>>> Thanks Gabriel, that is a definite improvement. GEOT-2608 committed as >>>> r33538. >>> Still not enough to get FeatureChainingTest to run with 256M heap, as on >>> Hudson. >>> >> nope, but because of a memory leak. If you run FeatureChainingTest only >> you can do that with 128m: >> mvn test -Dtest=org.geotools.data.complex.FeatureChainingTest >> -Dtest.maxHeapSize=128m -o >> >> So the two improvements needed keep being: >> - lazy parsing of emf elements/types into gt descriptors/types >> - fix mem leak (DataAccessRegistry is my suspect) >> >> I am looking into the former now. No promises though, it's getting late, >> but I may hopefully come up with at least a sensible plan. >> >> As for the seconds, I would also like to provide a patch. But may be >> over the weekend as this is spare time. >> >> Cheers, >> Gabriel > > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel