[ 
https://issues.apache.org/jira/browse/FELIX-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782010#comment-13782010
 ] 

Richard S. Hall commented on FELIX-4258:
----------------------------------------

Not sure there is much we can or should do about this. We can't force the 
garbage collector to release the class loaders holding the native libraries 
quicker, but until they do we can't re-use the native library. Potentially you 
could try to detect this situation and extract another copy of the native 
library (which is possible because of fragments), but it doesn't seem like this 
is worthwhile for such a corner case.

> Native library problems when the framework is quickly restarted
> ---------------------------------------------------------------
>
>                 Key: FELIX-4258
>                 URL: https://issues.apache.org/jira/browse/FELIX-4258
>             Project: Felix
>          Issue Type: Bug
>    Affects Versions: framework-4.2.1
>            Reporter: Guillaume Nodet
>
> If the framework is restarted quickly enough (using stop on the bundle 0 with 
> a restart for example), native libraries are not unloaded and the bundle 
> cache for those bundles is not refreshed leading to exceptions thrown when 
> loading native libraries.
> {code}
> ERROR: Bundle org.apache.servicemix.bundles.snappy-java [113] Error starting 
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.snappy-java/1.0.4.1_1
>  (org.osgi.framework.BundleException: Activator start error in bundle 
> org.apache.servicemix.bundles.snappy-java [113].)
> java.lang.UnsatisfiedLinkError: Native Library 
> /Users/sjavurek/Fuse/JBossFuse/jboss-a-mq-6.0.0.redhat-024/data/cache/bundle113/version0.0/bundle.jar-lib/0/org/xerial/snappy/native/Mac/x86_64/libsnappyjava.jnilib
>  already loaded in another classloader
>       at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1792)
>       at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1716)
>       at java.lang.Runtime.loadLibrary0(Runtime.java:823)
>       at java.lang.System.loadLibrary(System.java:1045)
>       at 
> org.xerial.snappy.SnappyBundleActivator.start(SnappyBundleActivator.java:33)
>       at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
>       at org.apache.felix.framework.Felix.doActivateBundle(Felix.java:2317)
>       at org.apache.felix.framework.Felix$7.call(Felix.java:2255)
>       at org.apache.felix.framework.Felix$6.call(Felix.java:2199)
>       at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>       at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>       at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
>       at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
>       at java.lang.Thread.run(Thread.java:680)
> {code}
> Not sure what the best way to fix this, as performing a systematic refresh 
> when the framework starts or stops may not be a good idea.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to