It's about 111739 characters long.
Even the context context.addMapping(mapping) take quite a bit. Not to
mention the actual unmarshal.
Werner Guttmann-6 wrote:
>
> Hi,
>
> what is the actual size of of the String before unmarshalling ?
>
> Regards
> Werner Guttmann
>
> On 29.09.2011 23:30, Richard2011 wrote:
>>
>> Sure,
>>
>> I'm having around 29 Objects that are filled up when I unmarshalled a big
>> String.
>>
>> Those Objects are parsed out using a mapping.xml file, like the
>> following:
>>
>> <class name="com.class.objects.parentClassName">
>> <map-to xml="InquiryResponse" />
>>
>> <field name="field1" type="string">
>> <bind-xml name="Field1" node="element"/>
>> </field>
>>
>> <field name="inquiryResponseHeader"
>> type="com.class.objects.className">
>> <bind-xml name="InquiryResponseHeader"
>> node="element" />
>> </field>
>>
>> ........etc.....
>> </class>
>>
>> <class name="com.class.objects.className">
>> <field name="id" type="string">
>> <bind-xml name="id" node="attribute"/>
>> </field>
>> <field name="seq" type="string">
>> <bind-xml name="seq" node="attribute"/>
>> </field>
>> .... etc....
>> </class>
>>
>> It takes about 1 - 2 minutes to unmarshall this objects. It may be longer
>> depending on the String received.
>>
>> I have been thinking also in the possibility to have less objects, for
>> example, although is much cleaner in a sense to have objects for each
>> "xml
>> section" that encapsulates information, will it be better to try to enter
>> information in less objects?
>>
>> Also I have the context and unmarshaller set up as the following:
>>
>> Mapping mapping = new Mapping();
>> InputSource in = new
>> InputSource(getClass().getClassLoader().getResource("fileName.xml").getPath());
>> mapping.loadMapping(in);
>>
>> //Added to increase performance with similar mappings
>> context.addMapping(mapping);
>> //End of XmlContext change
>>
>>
>> Unmarshaller unmarshaller = context.createUnmarshaller();
>>
>> unmarshaller.setMapping(mapping);
>> unmarshaller.setValidation(false);
>>
>> I read somewhere about a .cdr file that needs to be there but my I
>> basically
>> don't use generated files.
>>
>> Any idea? I can bring more information if required.....
>>
>> I really appreciate any thought or direction.
>>
>>
>> Werner Guttmann-6 wrote:
>>>
>>> Hi,
>>>
>>> I can only second that statement about the (non-) cost of logging.
>>> Having said that, what kind of degradation are you actually observing ?
>>> Can you share some information with us on this subject ?
>>>
>>> Kind Regards
>>> Werner Guttmann
>>>
>>> On 26.09.2011 20:42, Thom Hehl wrote:
>>>> Hi, Richard!
>>>>
>>>> If you look through the documentation for log4j, there is a trivial
>>>> cost
>>>> for supplying these log statements and probably much less if you turn
>>>> them off.
>>>>
>>>> The cost of this is pretty minor and I wouldn't worry about it.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Richard2011 [mailto:[email protected]]
>>>> Sent: Monday, September 26, 2011 2:41 PM
>>>> To: [email protected]
>>>> Subject: [castor-user] Castor Performance Degradation - Can INFO
>>>> messages, .cdr file or lot's of classes be the cause of it?
>>>>
>>>>
>>>> My first reasonable question, can INFO messages as the following:
>>>>
>>>> INFO: org.exolab.castor.xml.UnmarshalHandler - #endElement: bind-xml
>>>>
>>>> INFO: org.exolab.castor.xml.UnmarshalHandler - #characters:
>>>>
>>>> Degrade the performance? (I see in the logs lot's of this messages -
>>>> using
>>>> Net Beans 6.9.1) and I was curious. Until it ends this type of messages
>>>> it
>>>> continues with normal processes. Can logging be the cause of castor
>>>> degradation?
>>>>
>>>> 2.) I was reading about a .cdr file.. would this help? How can I
>>>> generate
>>>> one?
>>>>
>>>> 3.) I have at least 20 classes, some are nested on others.. is there
>>>> any
>>>> chance this can cause degradation as well? Or maybe that a mapping made
>>>> in
>>>> the xml file can be changed in order to improve performance?
>>>>
>>>> I really appreciate any assistance that anyone can give me...
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
>
--
View this message in context:
http://old.nabble.com/Castor-Performance-Degradation---Can-INFO-messages%2C-.cdr-file-or-lot%27s-of-classes-be-the-cause-of-it--tp32503960p32591592.html
Sent from the Castor - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
