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 Chris.Twiner wrote: > > Sorry a little further research and I found this issue: > > https://issues.apache.org/jira/browse/XERCESJ-911 (nodeListItem unsafe) > > i.e. it doesn't matter about having seperate builders, its just that the > entire xml tree cannot be represented in the xerces dom and then read > with nodelists. > > xerces wise this is due to an optimisation. Since EPRS are essential to > Muse and there is alot of code that uses the getChildNodes / NodeList > combination it seems to be that only a hack (using hasChildren in a > synchronized block in the EPR then getFirstChild / getNextSibling when > reading items from it) will remove the problem and reduce contention for > the lock. > > In short using nodelists in xerces are 100% thread unsafe, but the rest > of it doesn't claim to be thread safe even for reading in multiple > threads :-<. > > chris > > NB (the hack is to trigger synchronizeChildren to be called for > defferedimpls etc, but I'm not sure it really covers all the needs given > the dom heavy interface in eprs and the rest of muse). > > -----Original Message----- > From: Twiner Chris, IT-TBU-DL2-EAI-EDE > Sent: Sunday, September 02, 2007 7:29 PM > To: [email protected] > Cc: [EMAIL PROTECTED] > Subject: RE: EndpointReference thread-safe? > > Hi All, > > I don't think synchronizing on any set of functions will solve the > problem. EndpointReference is using XmlUtils.EMPTY_DOC i.e. a single > document instance for every thread. As Dong said, according the the > javadocs ( and XmlUtils.createBuilder() of course ^_^) you must use a > DocumentBuilder per thread, the documents used within it cannot be used > safely across threads (or the document builder itself) when involving > writes. > > So unless I'm missing something (always possible) EndpointReference > should be using XmlUtils.createDocument() instead (lines 124, 175 and > 239). I think its a bug, and if its agreed to be one, I'll have a look > for others (72 references to EMPTY_DOC in the codebase) as this is also > very important to me, and raise Jiras with patches off the 2.2 code. > > Vinh/Dong is it possible to verify this works as a fix? > > cheers, > Chris > > PS(If any one wants me to make patches against latest HEAD instead, let > me know) > > -----Original Message----- > From: Vinh Nguyen (vinguye2) [mailto:[EMAIL PROTECTED] > Sent: Friday, August 31, 2007 8:02 PM > To: [email protected] > Cc: [EMAIL PROTECTED] > Subject: RE: EndpointReference thread-safe? > > Hi Dong, > > Have you found a resolution on this yet? Looks like you are > encountering a problem we're seeing now, too. Synchronize on setting > the producer EPR is probably not the best solution because this really > slows things down, especially if you have to generate large numbers of > notifications. > > -Vinh > > > -----Original Message----- > From: dnguyen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 04, 2007 9:45 AM > To: [email protected] > Subject: Re: EndpointReference thread-safe? > > > The only thing that works is to synchronize on the producer EPR, since > making copies of it does not seem to work. Does this mean that the EPR > deep copy or Xerces deep copy is broken? Anyway, this effectively > serializes all notifies to any consumers, which impacts scalability to a > certain degree. > -- > View this message in context: > http://www.nabble.com/EndpointReference-thread-safe--tf3506487.html#a983 > 9159 > 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] > > > --------------------------------------------------------------------- > 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] > > > -- View this message in context: http://www.nabble.com/EndpointReference-thread-safe--tf3506487.html#a12481946 Sent from the Muse User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
