Revision history [back]

click to hide/show revision 1
initial version

answered 2016-01-25 02:19:04 +0800

cor3000 gravatar image cor3000

ZK Team

With the given information it's hard to give a definite answer but I'll try anyway:

If one thread is blocked while waiting for a resource, there is usually another thread having a lock on the same resource. E.g. in ZK 3.6 is was quite common to use the event processing threads feature (now deprecated).

This feature enabled synchronous blocking Messageboxes, which will block the a server side thread while waiting for user input. To verify you can check if another thread is currently waiting in this line

https://github.com/zkoss/zk/blob/v3.6.4/zk/src/org/zkoss/zk/ui/impl/EventProcessingThreadImpl.java#L221

Then (when the desktop is about to be cleaned up) it will try to gain a lock and wait forever resulting the the stack trace you provided (I am still just making up a case here - this has been made configurable somewhere in ZK 5). It will then wait here (few a method calls deeper according to your stack trace):

https://github.com/zkoss/zk/blob/v3.6.4/zk/src/org/zkoss/zk/ui/impl/SimpleDesktopCache.java#L118 -> https://github.com/zkoss/zk/blob/v3.6.4/zk/src/org/zkoss/zk/ui/impl/UiEngineImpl.java#L180 -> to activate a desktop it will try to get a lock.

However if that's the case you can implement a DesktopCleanup-Listener which is called before trying to activate https://github.com/zkoss/zk/blob/v3.6.4/zk/src/org/zkoss/zk/ui/impl/SimpleDesktopCache.java#L114

In this listener you can try calling this method to unblock any event processing threads on the current desktop still waiting for user input:

org.zkoss.zk.ui.sys.DesktopCtrl.ceaseSuspendedThread(EventProcessingThread, String)

I hope these few ideas give some insight on what might be happening and maybe I was lucky to guess right cause of your locking issue. Otherwise I hope you can provide some additional details on your findings.

With the given information it's hard to give a definite answer but I'll try anyway:

If one thread is blocked while waiting for a resource, there is usually another thread having a lock on the same resource. E.g. in ZK 3.6 is was quite common to use the event processing threads feature (now deprecated).

This feature enabled synchronous blocking Messageboxes, which will block the a server side thread while waiting for user input. To verify you can check if another thread is currently waiting in this line

https://github.com/zkoss/zk/blob/v3.6.4/zk/src/org/zkoss/zk/ui/impl/EventProcessingThreadImpl.java#L221

Then (when the desktop is about to be cleaned up) it will try to gain a lock and wait forever resulting the the stack trace you provided (I am still just making up a case here - this has been made configurable somewhere in ZK 5). It will then wait here (few a method calls deeper according to your stack trace):

https://github.com/zkoss/zk/blob/v3.6.4/zk/src/org/zkoss/zk/ui/impl/SimpleDesktopCache.java#L118 -> https://github.com/zkoss/zk/blob/v3.6.4/zk/src/org/zkoss/zk/ui/impl/UiEngineImpl.java#L180 -> to activate a desktop it will try to get a lock.

However if that's the case you can implement a DesktopCleanup-Listener DesktopCleanup-Listener which is called before trying to activate https://github.com/zkoss/zk/blob/v3.6.4/zk/src/org/zkoss/zk/ui/impl/SimpleDesktopCache.java#L114

In this listener you can try calling this method to unblock any event processing threads on the current desktop still waiting for user input:

org.zkoss.zk.ui.sys.DesktopCtrl.ceaseSuspendedThread(EventProcessingThread, String)

I hope these few ideas give some insight on what might be happening and maybe I was lucky to guess right cause of your locking issue. Otherwise I hope you can provide some additional details on your findings.

Support Options
  • Email Support
  • Training
  • Consulting
  • Outsourcing
Learn More