Re: Performance Notes - Locking

Thank you very much for your insights and for looking into that problem.
I don't think that is an apartment problem since I designed our pool so that
COM objects are always accessed and finalized via the same unique thread.

I am starting to think (hope!) that the problem could be in our COM server
because, for the 4 times I did log a stack trace, the freeze turned out to
be inside the 'Navigate' call in our COM app. That might not be a
coincidence. So I am now focusing my investigation at our COM code. I'll
keep you posted on that.

On a side note, something that would be great to have in Jawin is some
tracing/debugging logs so that we could see what's happening in the JNI
layer. That would allow to isolate Jawin bugs from COM object bugs.

Regards,

-- Christophe

-----Original Message-----
From: Robert Hastings [mailto:[email protected]]
Sent: Wednesday, May 25, 2005 7:02 PM
To: [email protected]
Subject: Re: Performance Notes - Locking

This might be happening at the COM level. If I'm thinking of the correct
discussion thread, then you are trying to use these COM pointers from a few
different threads in a thread pool. If the call to CoInitialize is
free-threaded but the server is marked apartment threaded then COM will try
to marshal the call through to an apartment thread. If COM thinks there is
thread it can use for an apartment thread, but it is not pumping windows
messages then your app will hang.

jSegue only supports apartment threading, but there is a class called
OleThread that pumps windows messages as required by COM. I don't know if
jawin has anything similar.

Robert


-----Original Message-----
From: Discussion of Java/Win32/COM integration with Jawin
[mailto:[email protected]] On Behalf Of Christophe Warland
(FRSGlobal)
Sent: Wednesday, May 25, 2005 7:54 AM
To: [email protected]
Subject: Re: [JAWIN] Performance Notes - Locking

I did not notice it before, but is seems that my lock always happens at the
same location in the code:

dispatchPtr.invoke("Navigate",urn);

where urn is a String like fire://Work Collections/1/5/[1-01_100|VAD]

Does that help you?

Regards,

-- Christophe


-----Original Message-----
From: Roger I Martin PhD [mailto:[email protected]]
Sent: Wednesday, May 25, 2005 4:15 PM
To: [email protected]
Subject: Re: Performance Notes - Locking

I don't see anything in Jawin per say that does a critical section.  I
don't know.  What is the argument list types for the  method you are
invoking?

Christophe Warland (FRSGlobal) wrote:

>Getting back to this issue, I'd love to hear someone's explanation around
>this line in jawin-2.0-alpha1/docs/perfdata/Performance1.html :
>
>"Locking. Some parts of the marshalling code use critical sections and
>kernel objects which might be contested especially in a server
environment."
>
>In particular, what parts of the marshalling code are we talking about
here?
>I'll be happy to try to fix it if only I knew where to start looking.
>
>Thanks.
>
>Regards,
>
>-- Christophe
>
>-----Original Message-----
>From: Christophe Warland (FRSGlobal) [mailto:[email protected]]
>Sent: Thursday, May 12, 2005 2:11 PM
>To: [email protected]
>Subject: Performance Notes - Locking
>
>I believe that I am actually suffering from a locking problem in the
>marshalling layer. I hooked up JAWIN in a client-server environment, with a
>custom pool of thread so as to avoid the apartment 'nightmare', and once in
>every few hundreds calls I get stuck in a locking situation.
>
>The docs on Performance Notes on Java/Win32 integration warned that it
could
>happen. And I am now wondering if there is a technical solution or hack to
>the problem. Do any of you have a suggestion for this? Thanks.
>
>Regards,
>
>-- Christophe Warland
>
>PS: for those interested, here is a stacktrace from one on my Worker
>threads. As you can see it is stuck in a native method of the GenericStub:
>
>"Thread-33" daemon prio=5 tid=0x0098f258 nid=0x80 runnable
>[3c2f000..3c2fd8c]
>  at org.jawin.marshal.GenericStub.dispatchInvoke0(Native Method)
>  at org.jawin.marshal.GenericStub.dispatchInvoke(GenericStub.java:201)
>  at org.jawin.DispatchPtr.invokeN(DispatchPtr.java:587)
>  at org.jawin.DispatchPtr.invokeN(DispatchPtr.java:555)
>  at org.jawin.DispatchPtr.invoke(DispatchPtr.java:510)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>  at java.lang.reflect.Method.invoke(Unknown Source)
>  at com.s1.frs.rand.frsweb.broker.Worker.run(Worker.java:54)
>
>
>