Unfortunately, I don't have a way to easily reproduce this. Is there way to pinpoint the location of the deadlock more precisely?
I've been reading the code and I don't see any synchronization that could lead to a deadlock. The only synchronized piece is where JXPathContext gets nodeFactories to protect against using the factories while they are also being registered. See if you explicitly register any node factories in your code - this might lead us to the cause of the problem. Thanks, - Dmitri ----- Original Message ----- From: "Adam J Chesney" <[EMAIL PROTECTED]> To: "Jakarta Commons Users" <[EMAIL PROTECTED]> Cc: "Adam J Chesney" <[EMAIL PROTECTED]> Sent: Friday, August 22, 2003 8:40 AM Subject: [JXPATH] Possible Sychronization Problem Hi, JXPath 1.1 running on Suse Linux 8.2, Sun JRE 1.4.2 We are using JXPath (which we think is great btw) in a highly multi-threaded environment where we are creating lots of contexts and we seem to be encountering an intermittent issue where a number of calls to jxp_context = JXPathContext.newContext(context); in different threads at similar times are blocking indefinitely (or at least > 60 secs). Other threads are also accessing there own JXPath contexts (which were successfully created earlier) at the same time. I have at a quick look into the JXPathContext source and it does seem that there is a bunch of synchronization of shared resources. Has anyone noticed any similar deadlock problems before. Thanks for any help you can provide. Adam Chesney ===================================================== Tel: (+44) 117 908 1254 (Direct) Mobile (+44) 7780 962 961 email: [EMAIL PROTECTED] This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Although this e-mail and any attachments are believed to be free of any virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Multicom Products Limited for any loss or damage arising in any way from receipt or use thereof. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
