Hi, in this case, I'd like to see some relevant parts of your LOG files, to get an idea where and how things are going wrong. Would that be an option ?
Regards Werner Gopinath Raghavan wrote: > 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 >>> >>> >>> > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
