Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] Multi-threading problem (and solution) inProtege-3.2.1 with Jambalaya

Timothy Redmond tredmond at stanford.edu
Fri Jan 26 10:33:17 PST 2007


It is very interesting that you can make this deadlock go away by
removing the Jambalya plugin.  I agree that Jambalaya shouldn't be
running this listener if the Jambalaya tab is not enabled.  I will
see if I can get this changed.

But the hang you are experiencing is actually a Protege threading
issue more than a Jambalaya issue.   I have seen variations of this
problem before with other applications.  If I understand how your
code is working and depending on conditions, there are many plugins
that might cause your code to hang.  This is because the Protege
threading model is a little limiting.

To make your code  robust: you need to turn off event dispatch (and
maybe event generation) for the duration of your thread execution.
This can be done with the knowledge base call

	kb.setDispatchEventsEnabled(false)

Event dispatch can be turned on after the separate thread has
executed.  You may also want to consider turning event generation off
also as this may improve memory consumption. If you turn event
generation off then you will need to refresh the gui after the thread
has completed its operation. This can be done with the call

	ProjectManager.getProjectManager().getCurrentProjectView().reload();

Finally - though this has an obvious disadvantage - you might want to
turn off the undo manager if performance is important.  One other
developer did this and had a significant performance improvement.

Here is my summary of what is happening:

	Thread-3: 	Modify Knowledge Base (takes kb lock)
	Thread-3: 	Generate Event
          Thread-3: 	Dispatch event to listeners
   	Thread-3: 	Listener invokes "swing" thing
	Thread-3: 	Listener is waiting on event in the AWT-Event-Queue
          AWT-Event-Queue Thread:	Event invokes knowledge base routine
	AWT-Event-Queue Thread:	To proceed knowledge base routine must wait
for kb lock

In more detail here is what I believe is happening:


     1. Your plugin is doing some processing in a separate thread (not
the AWT thread) that updates the knowledge base.  In your stack
traces this is Thread-03.

     2. When you invoke Protege, Protege takes the knowledge base
lock.  In the example below you are changing the knowledge base
(DefaultCls(DefaultFrame).addOwnSlotValue(Slot, Object) ). Therefore
events will get generated and dispatched
(EventDispatchFrameStore.dispatchFrameEvent(FrameEvent)).

     3. The dispatch is *synchronous* so all the listeners waiting for
events are invoked synchronously in thread-03.

     4. Many of these listeners will want to do something to update
the graphical interface (MyJTabbedPane
(Container).getComponents_NoClientCode()).  Often this involves
waiting for the AWT Event Queue.

     5. The event in the AWT Event queue tries to invoke a protege
knowledge base call but must wait for the knowledge base lock to be
free.


At this point both threads are stuck waiting for one another.  The
process is hung.  An obvious fix for this is for Protege to invoke
the listeners asynchronously.  But this is a fairly significant
change in the protege behavior and I believe it would probably break
several things.

BTW. The full thread dump is very useful in diagnosing deadlock
situations because it also shows where the locks are being taken.  I
think that this is invoked in windows by a C-Break in the Protege
console.  I am not positive but I think that Java would detect this
deadlock and tell you where it is.

-Timothy



On Jan 24, 2007, at 11:37 AM, Micheal Hewett wrote:

> I am experiencing random deadlocks while
> trying to create a knowledge base
> from a program running in a tab widget.
>
> Environment:
>   Protege 3.2.1 full (all plugins installed), frame mode
>   Java JDK 1.5.0_09
>   Windows XP Pro
>   Dell dual-core Intel hardware
>
> Protege setup:
>   tabs enabled: defaults + Algernon + my own
>
> Overview:
>   My plugin reads an XML file and imports the data into
>   Protege by creating classes, slots and slot values.
>
> Symptoms:
>   The plugin randomly hangs in the middle of the import,
>     at different places.
>   The more debugging output I generate, the less likely
>     it is to hang (I presume because it is updating
>     the knowledge base at a slower rate).
>   My import program never hangs if I run it standalone
>     rather than inside Protege.
>   Using a remote debugger I find that the thread doing
>     the import is running but not doing anything,
>     which implies a deadlock condition.
>     My own code is not using synchronization so the problem
>     is somewhere else.
>   I keep getting a mysterious "jambalaya.properties" file
>     in my directory even though I'm not running the Jambalaya
>     tab.
>   The stack dump of a hung thread is interesting:
>
> Thread [Thread-3] (Suspended)
>     MyJTabbedPane(Container).getComponents_NoClientCode() line: 298
>     MyJTabbedPane(Container).getComponents() line: 291
>     ProjectView.getTabByClassName(String) line: not available
>     JambalayaProjectPlugin.getJambalayaTab() line: 247
>     JambalayaProjectPlugin.knowledgeBaseChanged() line: 164
>     JambalayaProjectPlugin.access$0(JambalayaProjectPlugin) line: 160
>     JambalayaProjectPlugin$1.ownSlotValueChanged(FrameEvent) line: 49
>     EventDispatchFrameStore.dispatchFrameEvent(FrameEvent) line: not
> available
>     EventDispatchFrameStore.dispatchEvent(EventObject) line: not
> available
>     EventDispatchFrameStore.dispatchEvents(Collection, boolean) line:
> not available
>     EventDispatchFrameStore.dispatchEvents(boolean) line: not
> available
>     EventDispatchFrameStore.dispatchEvents() line: not available
>     EventDispatchFrameStore.setDirectOwnSlotValues(Frame, Slot,
> Collection) line: not available
>     SetDirectOwnSlotValuesCommand.doIt() line: not available
>     UndoFrameStore.simpleCommandExecute(Command) line: not available
>     UndoFrameStore.execute(Command) line: not available
>     UndoFrameStore.setDirectOwnSlotValues(Frame, Slot, Collection)
> line:
> not available
>     ArgumentCheckingFrameStore.setDirectOwnSlotValues(Frame, Slot,
> Collection) line: not available
>     ChangeMonitorFrameStore.setDirectOwnSlotValues(Frame, Slot,
> Collection) line: not available
>     DefaultDispatch.setDirectOwnSlotValues(FrameStore, Frame, Slot,
> Collection) line: not available
>     CleanDispatchFrameStore.setDirectOwnSlotValues(Frame, Slot,
> Collection) line: not available
>
> DeleteSimplificationFrameStore
> (FrameStoreAdapter).setDirectOwnSlotValues(Frame,
> Slot, Collection) line: not available
>     DefaultKnowledgeBase.setDirectOwnSlotValues(Frame, Slot,
> Collection)
> line: not available
>     DefaultKnowledgeBase.addOwnSlotValue(Frame, Slot, Object) line:
> not
> available
>     DefaultCls(DefaultFrame).addOwnSlotValue(Slot, Object) line: not
> available
>     ZProtegeClass.addSlotValue(Instance, Slot, Object) line: 226
>     ZProtegeClass.findOrCreateProtegeClass(Node, KnowledgeBase, Cls,
> Cls, ZParameters, List<String>) line: 156
>     Z.toProtegeTerm(Node, Cls, Cls, KnowledgeBase, ZParameters,
> List<String>) line: 384
>     Z.processComplexRelation(Node, Cls, Cls, KnowledgeBase,
> ZParameters,
> List<String>) line: 519
>     Z.toProtegeTerm(Node, Cls, Cls, KnowledgeBase, ZParameters,
> List<String>) line: 412
>     ImportTask.executeOne() line: 107
>     ImportTask(StandardManagedTask).run() line: 388
>     Thread.run() line: 595
>
> The Jambalaya plugin is apparently attaching a listener to
> Protege even though it is not activated.  The listener code
> is somehow accidentally causing a deadlock.  Jambalaya is
> also unnecessarily using processing time.
>
> Solution:
>   I removed the Jambalaya plugin from the Protege folder.
>   My import tab doesn't hang now.
>
> Comments:
>   Either Jambalaya is ill-behaved because it adds a listener
>   in a static initializer or in setup() rather than in the
> initialize()
>   method, or Protege is ill-behaved because it creates an instance
>   of each plugin even if it isn't activated by the user.  A non-
> activated
>   plugin shouldn't be consuming processor time.
>
>
> Thanks,
> Mike Hewett
> System Architect
> Evincii, Inc.
>
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/
> faq.html#01a.03




More information about the protege-discussion mailing list