Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Advice please...problems with this?  RSS feed

 
Darrin Smith
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have what I suspect may be a deadly embrace issue.

Here is hte 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. 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
Synchrnonized Run
{
RequestForMethod1
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 are blocking and single threaded on the MFC server side, all should be well, but maybe this is a bad assumption?
 
Henry Wong
author
Sheriff
Posts: 23283
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is about it. Looking at it, I was thinking that as long as the calls to the COM part are blocking and single threaded on the MFC server side, all should be well, but maybe this is a bad assumption?


Unfortunately, it can be very difficult to debug something with Pseudo code. In fact, in certain cases, it may be difficult to do it with real code...

But to address your second issue, you could create a MFC dispatching thread. And have some sort of invokeLater() method, to place MFC calls onto this dispatching thread. (which BTW, is easy to implement if you have a threadpool implementation -- just configure one thread in your pool)

Henry
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!