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]
