felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Shutdown deadlock on OS X while doing AWT stuff
Date Tue, 05 Mar 2013 14:18:04 GMT
On 3/5/13 09:02 , Dan Gravell wrote:
> Sorry, 'platform' is my code.
>
> Here's the full listing for platform.shutdown:
>
> public void shutdown() {
> if(null!=main) main.shutdown();
>   if(lastContext!=null) {
> try {
> lastContext.getBundle(0).stop();
> } catch (BundleException e) {
> LOG.error("Failed to stop system bundle, attempting system.exit", e);
> System.exit(0);
> }
> } else {
> LOG.error("Failed to stop system bundle because had no BundleContext");
> System.exit(0);
> }
> }
>
> As far as I can see, "main.shutdown" is not causing any trouble, because if
> @deactivate is being called on my Components,
> lastContext.getBundle(0).stop() must've been called. main.shutdown()
> performs some further shut down code, code that otherwise I guess could be
> part of another @deactivate.
>
> I don't receive any of the log messages.
>
> I'm beginning to wonder if this is just a interoperability problem with
> System.exit being called as a result of system shutdown.

How are you launching the framework? If you are using the standard Felix 
launcher, it registers a VM shutdown hook to actually stop the framework 
which can sometimes cause issues. Since you are explicitly stopping the 
framework, you could disable the launcher's shutdown hook in 
conf/config.properties...look in that file and you'll see how to disable it.

That may or may not help.

-> richard

>
> Dan
>
>
> On Tue, Mar 5, 2013 at 1:54 PM, Ferry Huberts <mailings@hupie.com> wrote:
>
>>
>> On 05/03/13 14:15, Dan Gravell wrote:
>>
>>> In my OSGi app (running on Felix 4.0.2) I use the Java SystemTray to add
>>> items to the system tray. One of these items is a 'quit' item:
>>>
>>> miQuit.addActionListener(new ActionListener() {
>>> @Override
>>> def actionPerformed(e:ActionEvent) {
>>> platform.shutdown();
>>> }
>>> });
>>>
>>> Then, PlatformImpl.shutdown does a:
>>>
>>
>> Why do you delegate to 'platform'.
>> I think you can call bundleContext.getBundle(0).**stop() right there.
>>
>> See if that fixes your deadlock
>> Otherwise try removing the systray items before calling stop.
>>
>>
>>> lastContext.getBundle(0).stop(**);
>>>
>>> Where lastContext is the BundleContext for the containing bundle. The
>>> SystemTray code and PlatformImpl are in different bundles. Stopping the
>>> bundles has the effect of calling:
>>>
>>> @Deactivate def shutdown() {
>>> awt.SystemTray.getSystemTray.**getTrayIcons.foreach(**systemTray.remove);
>>> }
>>>
>>> This is back on the SystemTray component (I'm using bnd style DS here).
>>>
>>> I am seeing a deadlock occur, but fairly infrequently and only on OS X.
>>> I managed to get a stack trace last time. Here are two suspicious
>>> looking threads (I attached the entire thing):
>>>
>>> "FelixStartLevel" daemon prio=5 tid=109c2d800 nid=0x10f371000 in
>>> Object.wait() [10f36e000]
>>>      java.lang.Thread.State: WAITING (on object monitor)
>>> at java.lang.Object.wait(Native Method)
>>> - waiting on <7eae23890> (a java.awt.EventQueue$**1AWTInvocationLock)
>>> at java.lang.Object.wait(Object.**java:485)
>>> at java.awt.EventQueue.**invokeAndWait(EventQueue.java:**1117)
>>> - locked <7eae23890> (a java.awt.EventQueue$**1AWTInvocationLock)
>>> at java.awt.Window.doDispose(**Window.java:1036)
>>> at java.awt.Window.dispose(**Window.java:974)
>>> at apple.awt.CTrayIconPeer.**disposeImpl(CTrayIconPeer.**java:58)
>>> at apple.awt.PeerImpl.dispose(**PeerImpl.java:30)
>>> at java.awt.TrayIcon.**removeNotify(TrayIcon.java:**701)
>>> at java.awt.SystemTray.remove(**SystemTray.java:273)
>>> - locked <7ed5e5968> (a java.awt.SystemTray)
>>> at
>>> com.elsten.bliss.ui.**systemtray.SystemTray$$**anonfun$shutdown$1.apply(*
>>> *SystemTray.scala:149)
>>> at
>>> com.elsten.bliss.ui.**systemtray.SystemTray$$**anonfun$shutdown$1.apply(*
>>> *SystemTray.scala:149)
>>> at
>>> scala.collection.**IndexedSeqOptimized$class.**
>>> foreach(IndexedSeqOptimized.**scala:34)
>>> at scala.collection.mutable.**ArrayOps.foreach(ArrayOps.**scala:38)
>>> at com.elsten.bliss.ui.**systemtray.SystemTray.**
>>> shutdown(SystemTray.scala:149)
>>> at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method)
>>> at
>>> sun.reflect.**NativeMethodAccessorImpl.**invoke(**
>>> NativeMethodAccessorImpl.java:**39)
>>> at
>>> sun.reflect.**DelegatingMethodAccessorImpl.**invoke(**
>>> DelegatingMethodAccessorImpl.**java:25)
>>> at java.lang.reflect.Method.**invoke(Method.java:597)
>>> [...]
>>>
>>> "AWT-EventQueue-0" prio=6 tid=105d82800 nid=0x11505f000 in Object.wait()
>>> [11505d000]
>>>      java.lang.Thread.State: WAITING (on object monitor)
>>> at java.lang.Object.wait(Native Method)
>>> - waiting on <7ece2ed20> (a org.apache.felix.main.Main$1)
>>> at java.lang.Thread.join(Thread.**java:1210)
>>> - locked <7ece2ed20> (a org.apache.felix.main.Main$1)
>>> at java.lang.Thread.join(Thread.**java:1263)
>>> at
>>> java.lang.**ApplicationShutdownHooks.**runHooks(**
>>> ApplicationShutdownHooks.java:**79)
>>> at
>>> java.lang.**ApplicationShutdownHooks$1.**run(ApplicationShutdownHooks.**
>>> java:24)
>>> at java.lang.Shutdown.runHooks(**Shutdown.java:79)
>>> at java.lang.Shutdown.sequence(**Shutdown.java:123)
>>> at java.lang.Shutdown.exit(**Shutdown.java:168)
>>> - locked <7faf9e240> (a java.lang.Class for java.lang.Shutdown)
>>> at java.lang.Runtime.exit(**Runtime.java:90)
>>> at java.lang.System.exit(System.**java:921)
>>> at com.apple.eawt._**AppEventHandler.performQuit(_**
>>> AppEventHandler.java:124)
>>> - locked <7ed6a2420> (a com.apple.eawt._**AppEventHandler)
>>> at com.apple.eawt.QuitResponse.**performQuit(QuitResponse.java:**31)
>>> at
>>> com.apple.eawt._**AppEventHandler$_**QuitDispatcher.**
>>> performDefaultAction(_**AppEventHandler.java:382)
>>> at
>>> com.apple.eawt._**AppEventHandler$_**AppEventDispatcher$1.run(_**
>>> AppEventHandler.java:487)
>>> at java.awt.event.**InvocationEvent.dispatch(**InvocationEvent.java:209)
>>> [...]
>>>
>>> Is there something I'm doing incorrectly? It looks like
>>> "_AppEventHandler.performQuit" is calling System.exit... but won't this
>>> be prone to deadlocks with OSGi?
>>>
>>> It's possible in this case that I chose to shutdown my app and this is
>>> what sent the event. If this is the case how can I work around this? I'm
>>> guessing that the removal of SystemTray items can't be done in this
>>> case, or has to be done in some managed thread context.
>>>
>>> Just wondering if anyone else has seen this.
>>>
>>> Dan
>>>
>>>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<users-unsubscribe@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> --
>> Ferry Huberts
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message