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.
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
>
>
>
