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#a12486133 Sent from the Muse User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
