Werner,
A small correction we do not share marshaller instances between threads. It
is actually our wrapper object's instance which is a singleton and shared
across multiple threads. As far as the instance of marshaller goes we create
new instance for every single thread. Please see the following code.
_marshaller = new Marshaller(sw);
_marshaller.setResolver((XMLClassDescriptorResolver)
_cdResolver);
_marshaller.setSuppressXSIType(true);
_marshaller.marshal(myObject);
Apologies for the confusion. The marshaller instance shown above is not
shared amongst threads.
Thanks,
Gopinath R.
On Tue, Dec 16, 2008 at 12:46 PM, Gopinath Raghavan <
[email protected]> wrote:
> Thanks Werner for your suggestion. Let me try creating one instance of
> Marshaller for every single thread.
>
> Thanks again,
> Gopinath R.
>
>
> On Tue, Dec 16, 2008 at 12:40 PM, Werner Guttmann <[email protected]
> > wrote:
>
>> Hi,
>>
>> Gopinath Raghavan wrote:
>> > Hi Werner,
>> >
>> > Please find my answers inline.
>> >
>> > a) Do you have a test case that I can use to replay your probpem.
>> > [Gopi] We do not have a test case that could reproduce this problem. We
>> > have'nt been able to replay this problem in our test environments. From
>> the
>> > observation (looking at timestamps in the DB and log file) of the issue
>> we
>> > found that when two different xml messages are picked up for processing
>> by
>> > two different threads exactly at the same time (timing matches upto
>> > millisecond level) then one of the response xml is corrupted.
>> >
>> > b) How are you using Castor ? How are you creating Marshaller instances.
>> > [Gopi] We've a generic wrapper class that provides ability to configure
>> > castor or other xml data binding components. Please find the code below
>> on
>> > how we create marshaller/unmarshaller classes with in the wrapper
>> classes.
>> > // Marshaller Usage
>> > StringWriter sw = new StringWriter();
>> > _marshaller = new Marshaller(sw);
>> > _marshaller.setResolver((XMLClassDescriptorResolver)
>> > _cdResolver);
>> > _marshaller.setSuppressXSIType(true);
>> > _marshaller.marshal(myObject);
>> >
>> >
>> > // Unmarshaller Usage
>> > _mapping = new Mapping();
>> > _mapping.loadMapping(_xmlMappingFile);
>> >
>> > _cdResolver =
>> >
>> ClassDescriptorResolverFactory.createClassDescriptorResolver(BindingType.XML);
>> >
>> > MappingUnmarshaller mappingUnmarshaller = new MappingUnmarshaller();
>> >
>> > MappingLoader mappingLoader = (MappingLoader)
>> > mappingUnmarshaller.getMappingLoader(
>> > _mapping, BindingType.XML);
>> > _cdResolver.setMappingLoader((XMLMappingLoader) mappingLoader);
>> >
>> > _unmarshaller = new Unmarshaller();
>> > _unmarshaller.setResolver((XMLClassDescriptorResolver) _cdResolver);
>> >
>> >
>> > c) Do you share a Marshaller instance between the threads ?
>> > [Gopi] Yes we do share marshaller instances between threads. It is a
>> > singleton instance that is shared between the threads.
>> That is you problem, indeed. You should not share one Marshaller
>> instance between multiple threads; actually, you must not. In other
>> words, each thread must create its own instance of a Marshaller before
>> using it.
>>
>> As long as you resuse the ClassDescriptorResolver amongst all the
>> Marshallers, start-up tine for a Marshaller upon instantiation will be
>> minimal.
>>
>> Regards
>> Werner
>> >
>> > Thanks and Regards,
>> > Gopinath R.
>> >
>> >
>> > On Tue, Dec 16, 2008 at 5:38 AM, Werner Guttmann <[email protected]
>> >wrote:
>> >
>> >> Hi,
>> >>
>> >> to be honest with you, I have not heard a single person in the past
>> four
>> >> years or so that reported a concurrency issue with Castor. Please note
>> >> that I am NOT saying that you are doing somethnig wrong, but I think it
>> >> is extremly unlikely that this is the case.
>> >>
>> >> Let me ask you a few questions:
>> >>
>> >> a) Do you have a test case that I can use to replay your probpem.
>> >> b) How are you using Castor ? How are you creating Marshaller
>> instances.
>> >> c) Do you share a Marshaller instance between the threads ?
>> >>
>> >> Regards
>> >> Werner Guttmann
>> >>
>> >> Gopinath Raghavan wrote:
>> >>> Hi there,
>> >>>
>> >>> We are using castor 1.1 in a multi-threaded environment.
>> >>>
>> >>> Please find below a brief description about our usage of castor and
>> our
>> >>> system -
>> >>> Our application consumes xml message from messaging queue then uses
>> >> castor
>> >>> to process the message and send back a response. This is a plain
>> simple
>> >> POJO
>> >>> application that listens to the messaging queues and we've about 10
>> >> threads
>> >>> listening to the queue. Whenever a message arrives one of the thread
>> >> picks
>> >>> up the xml message and starts processing. We use a mapping.xml.
>> >>>
>> >>> Observation of the issue -
>> >>> Recently after upgrading to castor 1.1 we are seeing that when two
>> >> threads
>> >>> pick up and process different xml messages at the same time we see
>> that
>> >> the
>> >>> response of one thread has unwanted data attached to the response xml.
>> >> The
>> >>> corrupt xml response message has two parts first part was the correct
>> >>> repsonse xml and the second part actually has the Java object
>> converted
>> >> to a
>> >>> xml message for e.g. it was not using the mapping file to generate the
>> >> xml
>> >>> rather the java object's attribute names were directly used as tag
>> names.
>> >>> There are no errors / exceptions thrown or logged in the log files.
>> >>>
>> >>> We havent seen this kind of issue before when we were using Cator
>> 0.9.5.3
>> >>>
>> >>> Please let me know if someone has experienced the same issue or a some
>> >>> inputs towards what could possibly be causing the issue.
>> >>>
>> >>> Thanks and Regards,
>> >>> Gopinath R.
>> >>>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>>
>
