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) in Protege-3.2.1 with Jambalaya

Timothy Redmond tredmond at stanford.edu
Thu Jan 25 11:34:24 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