dcsimg
Deadlock/deadly embrace suspected. Can you spot the problem?
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Darrin_Smith
Posted On:   Saturday, December 18, 2004 07:11 AM

I have what I suspect may be a deadly embrace/deadlock issue. Here is the scenario, I have a Java application acting as a client talking via COM to an MFC application acting as the server. The Java application is using JNI via a third party tool (jacoZoom) to do the COM work. The server sends messages to the Java application and on occasion the Java application responds back to the MFC server through COM. About 99% of the time all is well, but sometimes a dialog will pop up and display a "Server Busy" message. Normally, clicking on Retry will fix this, but every once in a while it just keeps displaying over and over again. During this time, the MFC server is responsive and not using any CPU cycles to s   More>>

I have what I suspect may be a deadly embrace/deadlock issue.

Here is the scenario, I have a Java application acting as a client talking via COM to an MFC application acting as the server. The Java application is using JNI via a third party tool (jacoZoom) to do the COM work.

The server sends messages to the Java application and on occasion the Java application responds back to the MFC server through COM.


About 99% of the time all is well, but sometimes a dialog will pop up and display a "Server Busy" message. Normally, clicking on Retry will fix this, but every once in a while it just keeps displaying over and over again. During this time, the MFC server is responsive and not using any CPU cycles to speak of while javaw is completely idle. Killing javaw gets rid of the dialog and allows the server to continue working properly.

Here is the way...in semi-psuedo code...everything is set up.




Java Application

----------------


Constructor
Initialize everything
Start the thread to handle COM (call it COMHandler which implements Runnable)


Method1 (not synchronized)
Do some GUI work using InvokeLater as needed


Method2 (not synchronized)
Do some database reading


Method3
Call COMHandler to send a message back to the MFC app




COMHandler class

Synchronized Run

{

RequestForMethod1
call back into MFC app to get more info
call Method1 in main class


RequestForMethod2
call Method2 in main class

}


CallBackToMFCApp (not synchronized and outside of Run)
Send a message back to the MFC application


ToggleFinishOfThread (not synchrnoized and outside of Run)
means to stop this thread from the main class




That is about it. Looking at it, I was thinking that as long as the calls to the COM part (from the MFC server) are blocking and single threaded on the MFC server side, all should be well, but maybe this is a bad assumption?



Thanks, and any help is appreciated!

   <<Less

Re: Deadlock/deadly embrace suspected. Can you spot the problem?

Posted By:   Sandeep_Shilawat  
Posted On:   Sunday, January 2, 2005 05:25 PM

Dear Darren



My friend Ajit always smiled when I told him that there seems like, the my swing application has a deadlock issues (or threading issue). I always hated him for that smile but most of the times he was right. He showed me a trick. I will tell you the same, try this



Press Ctrl+Break on your dos console if you are running on dos(Hope the process is running in forground). If you are not then run it on DOS as I do not know what to do to see stack trace on UNIX console.



Once you have the stack trace OBSERVE it for the calls being made from your calllback handler. You will find the answer. Post it if you do not find an answer and I will browse it. You can clearly see a deadlock if there is any.



I love being speculative though, I think you may see Socket.accept is waiting for ever. Looks like whatever you are using to make COM calls is stuck as it is doing that stuff synchronusly and can not do it any more for a well known Socket read problem. Solution to that is use some event notification mechnics so that you do not rely too much on that Socket read call. Meaning there will be always a next read call that you can make.



Try one more thing, the COM tool you are using must be opening some port from Client side. Try pinging in to that port. May the Socket is dead or timedout or something like that. As its third party tool there is very little you can do about it but refer to FAQ of that COM package. They might have some properties/config file



Here is I think is the best solution. Write a small java process (Server for you)which will do all the COM calling business using the third party tool. Then use messaging to talk with this process which will eliminate synch calling business. But I am not sure how easy to do this in your world...



Did any of this help(I have serious doubts :))? Do let me know... :)

About | Sitemap | Contact