Hi Dong and Chris, Thanks for your replies. Let's merge onto the thread "EMPTY_DOC thread stability issues". This EPR problem stems from this. -Vinh
-----Original Message----- From: dnguyen [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 1:36 PM To: [email protected] Subject: RE: EndpointReference thread-safe? Hi Chris, I have not been able to create a testcase with EPR by itself being accessed by multiple threads that will cause the issue. It is only when we send subscribers NotificationMessage using separate threads for each subscriber. I am willing to try the patch if available. Dong Chris.Twiner wrote: > > Hi, > > From what I could work out, from within the list comments and the > code, the state is stored in the Document itself, and as cloneNode > uses Object.clone and then sets the doc it won't work. Using > importNode helps a little (as it uses > getFirstChild()/getNextSibling()), but it just puts the problem to a later stage. > > getAllElements just does the same, calls getChildNodes and then forces > the cache to be used. Deleting the cache just stops the null for the > parent, it doesn't stop incorrect nodes being returned or race > conditions with other nulls. > > The simple thing is to stop using getChildNodes, from what I can see > in the code there isn't a need for it. The only place I've seen that > doesn't require all of the nodes anyway is in EndpointReference's > getNumberOfParameters, but that behaviour can be safely cached (its > not used directly in the project anyway). > > Looking further at the use cases in Muse only the IsolationLayer > (because of the DeferredImpl) needs to call hasChildNodes() on the > document node, for it to force that synchronizeChildren be called (its > cached from then on in each node). Then every other piece of code can > simply pointer chase with the getFirstChild()/getNextSibling() approach. > No synchronization required. > > re using other jaxp's, the DOM itself makes no statement about even > read thread safety. All of the jaxp impls suffer some form of > threading problem. Considering all of the problems with fighting > against namespace problems (much worse IMO) it makes sense to stick > with the devil you know :-<. > > Again for most of the xerces releases using the > getFirstChild()/getNextSibling() is a seamless dropin for the > getChildNodes problem. Its a shame that the xerces guys are very much > against any form of thread safety (except application enforced). > Going with the standard approach the only safe thing is to always > serialize to objects / keep the strings around, which would overly > complicate the code. > > I'm willing to give it a try and send you patched libs to try out (I > don't have a test case for this yet) if its quick to reproduce, just > let me know. If it works out I can raise a jira with the patches. > > cheers, > Chris > > PS(this problem is a very unpleasent suprise for me, I've been caching > Documents in another application which can then be used in jaxp > transformations and xalan uses the getChildNodes approach in a few > places. Now I see its only been working by luck alone :-< ). > > -----Original Message----- > From: dnguyen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 04, 2007 6:46 PM > To: [email protected] > Subject: RE: EndpointReference thread-safe? > > > Hi, > > After some digging a good while back, we found that Xerces optimized > the processing by using caching. Tracing through the Xerces source, > we discovered that the cache was being deleted after the thread > finished processing or parsing the DOM object, thus invalidating the > current "state" > of the DOM object for other threads that may be in the middle of > processing. > It also seemed that even if you make a "deep" copy of the DOM object, > they would share the same cache (not sure)? We hacked > org.apache.xerces.dom.ParentNode to instead not delete this cache. > This got us around the NullPointerException due to invoking toXML() on > the producer EPR in SimpleNotificationMessage.toXML(), but we ran > across another NullPointerException further down the source at > XmlUtils.getAllNamespaces(root). The stacktrace ends at > XmlUtils.getAllElements(). At that point, we have given up. > > The question now is could another JAXP library be easily substituted > for Xerces? > > Dong > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/EndpointReference-thread-safe--tf3506487.html#a124 86133 Sent from the Muse User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
