[
https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696903#action_12696903
]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
I must say I am somewhat worried about this deadlock issue, and may we we
should reopen this ticket ?
Stuard, Karl, I let you re-open it if you think it makes sense.
Let me explain:
---------------------
First of all, I just would like to notice that the problem I am facing here is
a story of legacy code which is
using Class.forName, and I just can't modify this legacy code in order to
replace the Class.forName by anything
else, like the OSGi registry. Indeed, I could rework the legacy code in order
to register class implementations
inside the OSGi registry, and inject them in client bundles (using iPOJO, SCR,
etc ...).
But the point is: I just can't modify the code, it's not mine.
Morover, I would like to notice that many third party open source libraries
(like log4j for instance) rely on
class.forName, and we can't ignore this fact ... Think of Log4j, which loads
Appenders using Class.forName ...
So, now, here is my problem: Yesterday, I successfully started my app server
with the options
"UnlockDiagnosticVMOptions/UnsyncloadClass", without any deadlocks. So far so
good.
Now, I have made a sample code in order to be able to get the problem in a
reproducible way .
My intent here was to make a Junit auto-test and verify that the
UnlockDiagnosticVMOptions/UnsyncloadClass
options really resolves the issue.
But Unfortunately, the sample code does not reproduce the deadlock.
However, and this is the point of this issue, when I run my sample code with
the
UnlockDiagnosticVMOptions/UnsyncloadClass, then I get some abnormal
ClassNotFoundException
(and I don't have them without the mentioned options !)
I have attached to this post the sample code. May be I did a mistake ? can you
look into it, please.
sample code description:
-----------------------------------
- The bundle "A" export the package "a" with a class a.A
- The Bundle "B", when started, fires some threads which perform
Class.forName("a.A").newInstance()
(B does an ugly "DynamicImport-Package: *)
- The Bundle "Updater" constantly updates the bundles A,B and refreshes them,
using PackageAdmin.refresh(null).
Hence, I ensure that wiring is re-done after each updates.
- Without, the UnlockDiagnosticVMOptions/UnsyncloadClass, I get the following
traces (I have activated
felix.log.level=4), and I don't have any deadlocks (unfortunately ..., well
...):
rm -rf felix-cache/; java -server -jar bin/felix.jar
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
DEBUG: WIRE: 10.0 -> org.osgi.service.packageadmin -> 0
DEBUG: WIRE: 10.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 9.0 -> org.osgi.framework -> 0
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
DEBUG: WIRE: 9.0 -> org.osgi.framework -> 0
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
DEBUG: WIRE: 9.0 -> org.osgi.framework -> 0
etc ...
- With the -XX options, I then get the following abnormal exceptions:
rm -rf felix-cache/; java -server -XX:+UnlockDiagnosticVMOptions
-XX:+UnsyncloadClass -jar bin/felix.jar
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
DEBUG: WIRE: 10.0 -> org.osgi.service.packageadmin -> 0
DEBUG: WIRE: 10.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 9.0 -> org.osgi.framework -> 0
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
DEBUG: WIRE: 9.0 -> org.osgi.framework -> 0
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
java.lang.ClassNotFoundException: *** Package 'a' is imported by bundle 9
from bundle 8, but the exported package from bundle 8 does not contain the
requested class 'a.A'. Please verify that the class name is correct in the
importing bundle 9 and/or that the exported package is correctly bundled in 8.
***
at
org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1448)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at b.Legacy.run(Legacy.java:6)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.ClassNotFoundException: a.A
at
org.apache.felix.framework.searchpolicy.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:565)
at
org.apache.felix.framework.searchpolicy.ModuleImpl.access$100(ModuleImpl.java:59)
at
org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1434)
... 5 more
-> Could anyone please check my sample code. I am just worried about unexpected
side effects from the -XX options ...
> deadlock with felix 1.6.0 ?
> ---------------------------
>
> Key: FELIX-1027
> URL: https://issues.apache.org/jira/browse/FELIX-1027
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Environment: jdk1.5, linux
> Reporter: Pierre De Rop
> Priority: Critical
> Attachments: deadlock.txt,
> deadlock_after_patch_FELIX_1027_20090406.log, FELIX_1027_20090406.txt
>
>
> I just came across a deadlock with the felix 1.6.0 candidate version for the
> next fwk version.
> I have attached to this post the corresponding "kill -QUIT" output.
> Richard, is it really an framework deadlock ? This is strange because I am
> testing the trunk since one month and never noticed the problem ...
> /pierre
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
