Hi Serge,
may i should have opened a new thread for this but instead i am resume the old one as this is related.... We have been using JNIwrapper 3.5 with Winpack 3.6 since we last spoke in production. We have a class that extends thread and is a HookEventListener. The class has a runloop which based on the hook events received calculates a user idle status (this is a chat system) and potentially installs/uninstalls hooks / sends status events. In the past this was receiving events even though there was no activity, something you found had to do with winpack hooks being installed / uninstalled too often and you gave us the 3.6 version of winpack to use instead which we have been so far. The reason we are uninstalling the hooks when we know there is user activity is that its an unnecessary overhead for the application and we had seen CPU spikes when it was happening.
When we receive an onHookEvent callback, the runloop may be still busy going through the cycle before the callback so we merely queue the OnHookEvent so that we process it asynchronously. What we have seen is that due to a timing problem the mechanism gets into a lock where events are not processed, but the problem is that the activethread count increases a lot very fast causing our application to spin. A thread dump showed the following: (only relevant threads shown)
"Thread-198" daemon prio=6 tid=0x0aca3e90 nid=0xb3c runnable 0x0e82f000..0x0e82fae8
at com.jniwrapper.Function.invokeCFunc(Native Method)
at com.jniwrapper.FunctionCall.a(SourceFile:121)
at com.jniwrapper.FunctionCall.call(SourceFile:34)
at com.jniwrapper.Function.invoke(SourceFile:162)
at com.jniwrapper.Function.invoke(SourceFile:198)
at com.jniwrapper.win32.system.EventObject.waitFor(EventObject.java:56)
at com.jniwrapper.win32.hook.Hook$HookEventLoop.run(Hook.java:343)
at java.lang.Thread.run(Unknown Source)
"ChatDock - Activity Monitor Thread" daemon prio=6 tid=0x0ad14f78 nid=0x924 in Object.wait() 0x0ef2f000..0x0ef2fd68
at java.lang.Object.wait(Native Method)
- waiting on <0x03621718> (a java.lang.Thread) at java.lang.Thread.join(Unknown Source) - locked <0x03621718> (a java.lang.Thread) at java.lang.Thread.join(Unknown Source) at com.jniwrapper.win32.hook.Hook.uninstall(Hook.java:277) at com.pcbsys.chat.gui.ActivityMonitorThread.uninstall(Unknown Source) - locked <0x034a3bd0> (a com.pcbsys.chat.gui.ActivityMonitorThread)
at com.pcbsys.chat.gui.ActivityMonitorThread.run(Unknown Source)
"ChatDock - Activity Event Q" daemon prio=6 tid=0x0ace6720 nid=0xe2c waiting for monitor entry 0x0ee6f000..0x0ee6fa68
at com.pcbsys.chat.gui.ActivityMonitorThread.a(Unknown Source)
- waiting to lock <0x034a3bd0> (a com.pcbsys.chat.gui.ActivityMonitorThread)
at com.pcbsys.foundation.uj.h(Unknown Source)
at com.pcbsys.foundation.fk.run(Unknown Source)
The activity monitor thread is the class with the runloop which is also a hook event listener. The Activity Event Q is the hook event queue which uses a thread pool to provide callbacks to the queued object processor which is again the activity monitor thread.
Sometimes we see a lot of threads like Thread-198 and sometimes just one but the CPU spikes very high in both cases. What i am wondering is whether the queueing of HookEventObjects corresponds to a 1-1 mapping in threads you create to serve the native call. Is that the case?
Also in the above stack trace part, we see that the activity monitor thread decided in its runloop that it should uninstall the hook, however the call is locked waiting for the event thread to die in the join call (this must be the Thread-198 in the dump). That thread is also blocked waiting for the native call to finish with an indefinite wait time...
Can you please clarify this is the case and provide with any suggestions to prevent this..
Thanks,
Alex Kritikos
my-Channels
Any updates on this?
Message was edited by: Alex Kritikos
