DocumentBuilder hangs

[annegrl]

Hi all,

I tried this post in the XML forum, but it was suggested I try the java forum instead...so here goes...

I have an application which is using Xerces parser for XML parsing. Most of the time, I have no problems. However, occasionally, at the point I am creating the new DocumentBuilder ..
...
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
DocumentBuilder builder = dbf.newDocumentBuilder();
...
..the entire application will freeze. The exact same XML message may sometimes work fine, and sometimes cause this freeze and sometimes not(well, I guess it really unrelated to the message, since it's not at the point of parsing it yet). Sometimes when restarting the application, everything will proceed fine. Other times, it consistently freezes, across multiple restarts.

What I'm trying to figure out is if there are any tricky situations when working with Xerces/JAXP/etc that would corrupt the environment or would prevent it from cleaning up (across application restarts)? By the way, I am running this on AIX.

Thanks for any ideas you may have!
anne

 

[palbano]

anne,

I hoped you would add some information about the nature of your application, i.e., is it multi-threaded, using inter-process communications, etc. Without more specific information my suggestion in the XML forum is all I can offer.

-pete

 

[idarke]

I'm curious about the symptoms of the freeze. How do you know it's freezing at that point in the program? In a true "freeze", buffers don't get flushed so the output in System.out and System.err often trails the actual error. Is there a loop beyond the code you gave us where the program could possible be looping? Have you had it under a debugger and had it freeze?

Could the freeze actually be garbage collection? How long do you wait before declaring it dead?

 

[annegrl]

Pete,

The application is multithreaded. There is MQ Connection Pooling (so a thread for each MQ connection) and also a thread is started to handle each message on the queue. Each of the message handler threads creates its own instance of the XML parsing logic. In some cases, this thread (after XML parsing is complete) may need to start a new process (with Runtime.exec), but I don't want to confuse the issue by adding this information since I saw the problem occur even before this code was in place.

From the facts, it does "sound" like a deadlock situation, except for that this behavior can occur consistently across application restarts--it will work 100 times just fine, then once it fails, even restarting the app after logging out & back in, is not a sure fix to the problem.

idarke,

You make a good point in that I guess I can't really pinpoint the exact location of the freeze since it is not when I am debugging it. I am basing my assumption on system.out's. Past the point where I know it reached, the DocumentBuilder is doing the actual parse--which could be a more "reasonable" place for a hang. Most of the times, I only wait a few minutes to confirm that it is hanging--but one time I forgot and left it running overnight...still hadn't finished the next day. Another thing is that this only seems to happen 5% of the time, so I would assume if it were stuck in a loop, it would consistently be stuck in a loop, and not just some of the time.


Thanks for your help guys,
anne

 

[idarke]

Perhaps, just as an experiment, you should assume that the Xerces parser is not thread-safe and synchonize its use.

 

[palbano]

>> I saw the problem occur even before this code was in
>> place.

This is getting interesting.

So you had a problem that was unresolved and you kept developing? If i am reading that right, do you have an old version of the code that isolates the problem from the MQ and threading/synchronization code? If you do then can you execute it and reproduce the problem? If so then you will have eliminated deadlocks (at least in your code) as the problem.

-pete

 

[annegrl]

idarke,

I'll try synchronizing with Xerces and see what turns up--unfortunately I don't have a predictable way to reproduce the problem yet, so it will be tough to tell if it's a cure or not

pete,

I only meant that the code starting another process w/ Runtime.exec() was new. The MQ pooling and multi-threaded message handling was in place before I came across the problem.

anne

 

[palbano]

>> The MQ pooling and multi-threaded message handling was
>> in place before I came across the problem.

Then i would consider that highly suspect. If you isolate your use of Xerces and execute that isolated code in an automated fashion without reproducing the problem then the problem lies elsewhere yes?

>> I'll try synchronizing with Xerces and see what turns up

Are you synchronizing because the factory and builder code you posted is application scope and the instances of factory and/or builder are being reused across threads? If your executing the code you posted in each thread then synchronizing should not effect anything other than using more resources for the synchronization.

-pete

 

[annegrl]

>>>> The MQ pooling and multi-threaded message handling was
>>>> in place before I came across the problem.

>>Then i would consider that highly suspect. If you isolate
>>your use of Xerces and execute that isolated code in an
>>automated fashion without reproducing the problem then
>>the problem lies elsewhere yes?

I think my statement was unintentionally leading. I had the pooling and thread handling in place before using Xerces. Unfortunately, I have not isolated my usage of Xerces.

>>>> I'll try synchronizing with Xerces and see what turns up

>>Are you synchronizing because the factory and builder
>>code you posted is application scope and the instances of
>>factory and/or builder are being reused across threads?
>>If your executing the code you posted in each thread then
>>synchronizing should not effect anything other than using
>>more resources for the synchronization.
I am using a different instance in each thread, and not sharing instances across threads. As I understand it, this should be fine. I've seen documented that Xerces is not thread-safe on DocumentBuilderFactory, so that's specifically why I'm using a new instance within each new thread. However, I am now considering that maybe this implies that even more than one instance of this class running at the same time could cause a problem?

anne

 

[palbano]

>> maybe this implies that even more than one instance of this class
>> running at the same time could cause a problem?

If that is true it is a platform specific problem. I have code that does exactly what you describe using Sockets rather than MessageQueues and it has been running flawlessly for over two years now. It was tested at an Intel lab where severe loads were applied. As stated in your XML forum thread my application has been running on Windows 2000 Server.

-pete

 

[annegrl]

Maybe. I have been running my same code on Windows and have not come across this problem (doesn't mean it's not there as well, I am not pushing it as hard, mostly using it for unit testing and debugging). Glad to hear yours has been running flawlessly, there is hope for me

Thanks for your help,
anne