Hi Heath, Heath Gerhardt wrote:
> Hi all, > > I've noticed that when xstream.fromXML(xmlString) is called a > sun.reflect.GeneratedSerializationConstructorAccessor class is created. Which XStream and Java version you're using? Please use the latest XStream release 1.4.2. > We are using xstream on a highish volume web service and these generate > classes are causing our permgen to fill up and trigger painful garbage > collections. Do you have a stack trace to the place where these objects are created? Since it is internal code of the Java runtime, I can only guess where such an object might be used. I am quite sure it is triggered by the converters based on reflection (mainly SerializableConverter and ReflectionConverter). Can you identify which creation of your objects triggers such an instance? > Is there a way to avoid this while continuing to use > Xstream? Use custom converters instead of the ones based on reflection. Reflection provides a convenient way to marshal your objects, but those converters have a lot to do (not only reflection, they will also have to respect all your configuration for aliases, local converters and the like). With custom converters you define directly what is written and read. If you have the need to optimize for every millisecond, that's a way to go. http://xstream.codehaus.org/faq.html#Scalability_Performance > I've tried using different drivers (jdom, dom4j, DomDriver, xpp, > jettison) all with the same effect. Expected, since the driver only selects the XML parser, but has nothing to do with the functionality that recreates the objects. > Thanks in advance :) Hope this already helps a bit. - Jörg --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
