Java Threads and JNI (specifically jacob, java com bridge)

Forgive me having to call a COM object from Java but I do not have a choice. I am updating code that has been in production now for 4 years so I am stuck on JDK 1.4.

There are occasions where the COM Dispatch call will not return (more than likely a COM server side issue) but of course instead of trying to solve the problem they want me to work around it. Because this COM system has proven to not be Thread Safe I protect access to it with a Mutex class I created. The enhancement I need to add is to release the Mutex when the thread runs too long. This part is easy. However I have a Thread that is still running and being be a good programmer I would like to clean it up. Normally if this thread was in a BLOCKED state I would just interrupt it. However without being able to perform a Heap Dump when this situation arises I cannot tell what state the Thread is in. The behavior of not returning is not repeatable at least as far as I am concerned as it is another Vendor and of course the problem really does not exist

I do not have access to the C++ COM code at the moment and I don't like looking at M$ COM crap anyway. Assuming that my Java Thread is making a COM call that results in a DCOM call (The COM interface is calling out to another COM object overseas) what do you think the state of my thread would be in and would sending an interrupt be worthwhile? I know that if the Thread is in a RUNNING state that an interrupt just sets the interrupt flag and that is it.

And no I cannot throw everything away and start over with a pure java solution

thanks for your suggestions!

Doug

Probably I didn't understand everything (never worked with COM), but if the object is locked, wouldn't interrupting currently working thread throw any sort of exception? What's the problem of letting the thread simply die?

Hi, Doug -

This article should have everything you need:
http://www.ddj.com/java/184410467

'Hope that helps .. PSM

Originally Posted by Alien_Hominid Probably I didn't understand everything (never worked with COM), but if the object is locked, wouldn't interrupting currently working thread throw any sort of exception? What's the problem of letting the thread simply die?

Thanks Allen for your time. I do not know if my Thread enters BLOCKED state once it gets into the guts of the JNI COM call ... that is my question. You can only interrupt a thread if it is blocked via (wait, join, sleep) or if i/o blocked on an interruptible channel or Selector. Neither of these situations occur in the Java code as it goes off into JNI/COM land. It it were to block then yes I could interrupt it. What I want to do but don't have access to the box yet is to simulate a normal flow and then when the COM call is made I want to create a HEAP DUMP / Stack trace which will show me the state of all running threads. That should give me my answer but as of yet I cannot do that and I was wondering if any one out here has had any similar dealings with Java Threads, JNI and COM.

As of now I am letting the thread continue to live out its natural life. I still interrupt it so that it won't do any unnecessary work if it ever returns. What i want to guard against is running out of memory because so many threads get started and run but because of a DCOM problem they never get reaped.

I think you can interrupt anytime you want. The interrupted status flag will be set and that's all:

If none of the previous conditions hold then this thread's interrupt status will be set.

Normally you can check whether the thread was blocked or not. If it doesn't return an exception, then its interrupt status is set. Maybe BLOCKED state when making JNI COM call differs from normal thread BLOCKED state and this is what I don't know. You can ask at java forum. Probably you'll get better help there.