> -----Ursprüngliche Nachricht----- > Von: Simon Lord [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 15. März 2007 15:27 > An: [email protected] > Betreff: Re: AW: [castor-user] [XML] XMLClassDescriptorResolver > XMLFieldDescriptorImpl cache possible memory leak > > Hello again Werner, > > Thanks for the reply. > > In the application i help to develop it is impossible for us to use only > one resolver, as we have many threads needing to perform (un)marshalling > operations and the implementation of XMLClassDescriptorResolver is not > thread safe (it uses HashMaps) and we cannot afford to block until the > resolver is available. I think for your use case, the XMLClassDescriptorResolver is sufficiently thread-safe once the descriptors for all classes have been loaded and cached. Once this activity has been finished, thread-safeness should not be an issue anymore.
> > Werner Guttmann wrote: > > Hmm, you should *not* be creating a resolver for each root class, but > one resolver only for all classes potentially used throughout your > (un)marshalling operations. Once the resolver has loaded - in your case - > the descriptors for all classes found in that package, it will cache them. > > > > And the Unmarshaller will be able to retrieve the cached descriptors as > needed. > > > > I hope this explains things in more detail. > > > > Werner > > > >> -----Ursprüngliche Nachricht----- > >> Von: Simon Lord [mailto:[EMAIL PROTECTED] > >> Gesendet: Donnerstag, 15. März 2007 10:22 > >> An: [email protected] > >> Betreff: Re: [castor-user] [XML] XMLClassDescriptorResolver > >> XMLFieldDescriptorImpl cache possible memory leak > >> > >> Hi Steven, > >> > >> Thanks for your speedy reply. > >> > >> I understand that there is an object graph underneath the root object, > >> hense i understand it needs to load the 3828 descriptors for the object > >> graph underneath my root object. What i don't understand is why when > >> marshalling/unmarshalling the same root class (albeit with possibly > >> different values e.g., two objects of type person might have different > >> names but it's still the same name field) the resolver is loading more > >> descriptors but should in my opinion be using the same descriptors, it > >> is only the values that have changed not the class/fields. I understand > >> that in a complex object graph it may need to load more descriptors for > >> different objects due to it having a larger object graph - but my > object > >> is staying relatively similiar each time - therefor i would expect some > >> growth but not constant growth with each iteration. > >> > >> Also i'm not trying to create a resolver for every class - i'm creating > >> a resolver for each root class and reusing them (and yes i am setting > >> the resolver on the marshaller/unmashaller ;-). I don't think it is > >> thread safe either - so i've implemented it in a thread safe manner > >> > >> I hope this sounds more like i'm implementing/understanding it all in > >> the right way. > >> > >> I'm off to write a unit test now and do some further investigation :) > >> > >> Thanks > >> > >> Simon Lord > >> > >> > >> > >> Steven Dolg wrote: > >>> Hi Simon, > >>> > >>> The 3828 FieldDescriptors indicate that the object graph your > >>> (un)marshalling contains some more classes than the one you're > creating > >>> the ClassDescriptorResolver for. > >>> So the (Un)marshaller asks the ClassDescriptorResolver to find all > >>> descriptors necessary for the whole object graph (not just the root > >>> object). > >>> This might lead to creating different ClassDescriptorResolvers (for > >>> different root classes) that might contain almost identical > descriptors > >>> (for all other objects in the object graph). > >>> > >>> It shouldn't be necessary to create a ClassDescriptorResolver for each > >>> class individually so I'd suggest using only one resolver. (I'm not > >>> entirely sure whether this is thread-safe or not) > >>> > >>> And do not forget to set the created ClassDescriptorResolver at the > >>> (Un)marshaller... ;-) > >>> Unmarshaller unm = new Unmarshaller(...); > >>> unm.setResolver(cdr); > >>> > >>> Regards, > >>> Steven > >>> > >>> > >>> ----- Original Message ----- From: "Simon Lord" > >> <[EMAIL PROTECTED]> > >>> To: <[email protected]> > >>> Sent: Wednesday, March 14, 2007 6:44 PM > >>> Subject: [castor-user] [XML] XMLClassDescriptorResolver > >>> XMLFieldDescriptorImpl cache possible memory leak > >>> > >>> > >>>> Afternoon all, > >>>> > >>>> I've recently moved from using an old version of Castor (0.9.xxx) to > >>>> the new stable 1.1. Mainly as i'd like to use the descriptor caching. > >>>> > >>>> However, after moving to castor 1.1 and creating an > >>>> XMLClassDescriptorResolver as per the xml-best-practices webpage, > >>>> running my application caused an out of memory expection (heapspace). > >>>> > >>>> So i ran the code under jProfiler and have seen symptoms of a memory > >>>> leak (or symptoms of not using the resolver correctly ;-). > >>>> > >>>> It my understanding that when marshalling/unmarshalling, the > >>>> XMLClassDescriptorResolver should be caching the descriptors for use > >>>> in subsequent operations. Then on the subsequent operation (marshal / > >>>> unmarshall) it shouldn't have to create those descriptors again > >>>> (assumming the same class/xml complex type is being used). > >>>> > >>>> But what i've seen in jProfiler is that after one run of my code > there > >>>> have been 3828 XMLFieldDescriptorImpl objects created (triggering > >>>> garbage collection a few times doesn't change that number either) > then > >>>> when i run it again (no restart, just second iteration) it finishes > >>>> what it's doing and the count of XMLFieldDescriptorImpl objects is > now > >>>> 7725! > >>>> > >>>> It increases with each iteration, and after 10 iterations is 38901 > >>>> objects, taking up 3.4 megabytes in memory - after a while this gets > >>>> so big it causes the memory exception. > >>>> > >>>> So it looks like it's created new XMLFieldDescriptorImpl for the same > >>>> classes and xml complex types i used the first time around. > >>>> > >>>> > >>>> Has anyone else seen this behaviour before? Am i doing somthing wrong > >>>> when creating / using the resolver? > >>>> > >>>> > >>>> Here's the code i use to contruct a resolver (sorry about the > >>>> formatting): > >>>> > >>>> private XMLClassDescriptorResolver createResolver(Class clazz){ > >>>> > >>>> XMLClassDescriptorResolver cdResolver = > >>>> > >> > (XMLClassDescriptorResolver)ClassDescriptorResolverFactory.createClassDesc > >> riptorResolver(BindingType.XML); > >>>> > >>>> > >> > cdResolver.setClassLoader(Thread.currentThread().getContextClassLoader()); > >>>> try { > >>>> cdResolver.loadClassDescriptors(clazz.getPackage().toString()); > >>>> return cdResolver; > >>>> } catch (ResolverException e) { > >>>> logger.warn(e.getMessage() + ":"+clazz.getPackage().toString(),e); > >>>> } > >>>> return null; > >>>> } > >>>> > >>>> as you can see from the above code i create a resolver for each Class > >>>> i marshal/unmarshall and store it for subsequent uses of the same > >>>> operation (so i'm not creating a new resolver each time as it might > >>>> appear) > >>>> > >>>> Thank you for your time > >>>> > >>>> Simon Lord > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe from this list please visit: > >>>> > >>>> http://xircles.codehaus.org/manage_email > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe from this list please visit: > >>> > >>> http://xircles.codehaus.org/manage_email > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe from this list please visit: > >> > >> http://xircles.codehaus.org/manage_email > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
