|
Rick Hillegas made changes - 30/Sep/08 12:23 PM
We - http://www.jfire.org - have the same problem and assume that it is a caused by the deployment configuration: Because we use Derby for JBoss' messaging (JBossMQ), we have to put derby.jar into the lib directory (otherwise the JBossMQ fails with exceptions). However, the JMX seems to be in JBoss' deploy directory and therefore Derby has no chance to ever find the class (didn't verify this - just an assumption).
Additionally, it might be a problem with timing: When Derby is loaded, maybe the JMX is not yet started? I don't know the best solution to this problem, but I know that we don't need JMX. That's why we deactivated this line mentioned above. However, patching a libraries JAR is not a nice way. Therefore, I'd like to ask for another - more convenient solution: 1) Instead of an exception, it should simply log a warning and continue (JMX isn't really essential - is it?). 2) It should be possible to provide a system property which deactivates the JMX hooking on startup (to get rid of the WARN log). In the long run, it would be nice to have a clean solution that takes the said problems (deployment location + timing) into account.
Kristian Waagan made changes - 06/Oct/08 02:26 PM
Added a link to
I found this code fragment in org.apache.derby.impl.services.jmx#findServer,
notice the catch clause comment: try { mbeanServer = AccessController .doPrivileged(new PrivilegedAction<MBeanServer>() { public MBeanServer run() { return ManagementFactory.getPlatformMBeanServer(); } }); } catch (SecurityException se) { // Ignoring inability to create or // find the mbean server. MBeans can continue // to be registered with this service and // startMangement() can be called to get // them registered with JMX if someone else // starts the MBean server. Perhaps this ignore action should apply to the classNotFoundException, too?
Jeremy Gustie made changes - 10/Nov/08 08:20 PM
I have been seeing this issue as well, after a little poking around it appears that the JBoss classloader which contains the "missing" JBoss server builder is temporarily taken out of context by the
The "org.jboss.mx.server.MBeanServerBuilderImpl" class identified by the "javax.management.builder.initial" system property actually lives in the "JBOSS_HOME/lib/jboss-jmx.jar" JAR; this class is available on classloader being taken out of context by the What is not clear to me is why the platform MBean server isn't set by JBoss before this code executes: my guess is that this error is occurring before JBoss has fully initialized. If the ManagementFactory.getPlatformMBeanServer gets called anytime before Derby attempts to call it with a null context classloader this might not be a problem since the already created MBeanServerImpl instance would just be returned - like I said, if JBoss is not fully initialized this might not be possible. I'm not familiar enough with JMX or the JBoss implementation to know where this issue would need to be addressed (i.e. is this a JBoss or Derby issue). I don't think that ignoring the ClassNotFoundException would resolve the issue because you may end up masking other problems and making very difficult to track down why the management beans aren't being registered. If you are running JBoss with a security manager, you could in theory deny the Derby JMXManagementService the "setContextClassLoader" runtime permission; that would prevent the classloader from being taken out of context (and Derby will silently eat the security exception in the name of backwards compatibility). I'm not sure what other problems that causes though (I haven't tried it). You can enable JBoss to act as the platform MBean server on Java 5+ runtimes using the "jboss.platform.mbeanserver" system property (add it to the JBoss run script in the JAVA_OPTS variable). See JBAS-1610 on the JBoss JIRA site. Doing this will ensure that ManagementFactory.getPlatformMBeanServer returns the JBoss MBeanServerImpl instead of trying to create a new one with implementations that are not available.
Some possibly useful reading material for anyone wanting to investigate further:
http://blogs.sun.com/jmxetc/entry/the_mystery_of_multiple_mbeanservers
Kathey Marsden made changes - 09/Jan/09 04:47 PM
I am thinking I should back out the JMX portiion of the fix for
Kathey Marsden made changes - 12/Jun/09 05:25 PM
Here is the patch to back out the JMX related portion of
Thanks Kathey
Kathey Marsden made changes - 12/Jun/09 06:11 PM
Tests ran fine. Marking patch available. I'll check in as soon as I hear feedback on whether it corrects the issue.
Kathey Marsden made changes - 12/Jun/09 11:11 PM
committed change to 10.6,10.5, and 10.4. I hope some JBOSS users can confirm this fix. I will file a new issue for the apparent JMX related class loader leak after a bit more research.
Kathey Marsden made changes - 16/Jun/09 09:27 PM
Attached is a reproduction for this issue. Without the fix, it fails with:
Exception in thread "main" java.lang.ExceptionInInitializerError at java.lang.J9VMInternals.initialize(J9VMInternals.java:222) at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:136) at Derby3887.main(Derby3887.java:6) Caused by: javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class Derby3887: java.lang.ClassNotFoundException: Derby3887 at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:491) at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:522) at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:309) at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:224) at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:185) at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:298) at org.apache.derby.impl.services.jmx.JMXManagementService$3.run(JMXManagementService.java:207) at org.apache.derby.impl.services.jmx.JMXManagementService$3.run(JMXManagementService.java:205) at java.security.AccessController.doPrivileged(AccessController.java:202) at org.apache.derby.impl.services.jmx.JMXManagementService.findServer(JMXManagementService.java:204) at org.apache.derby.impl.services.jmx.JMXManagementService.boot(JMXManagementService.java:114) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2021) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573) at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Monitor.java:366) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:398) at org.apache.derby.impl.services.monitor.FileMonitor.<init>(FileMonitor.java:60) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:289) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:69) at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:201) at org.apache.derby.jdbc.EmbeddedDriver.<clinit>(EmbeddedDriver.java:96) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) ... 3 more Caused by: java.lang.ClassNotFoundException: Derby3887 at java.lang.Class.forName(Class.java:136) at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:438) at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:476) ... 25 more and I confirmed it passes with the fix. I will look at getting this checked in as a regression test, but will still leave this issue in a resolved state since the code fix is checked in.
Kathey Marsden made changes - 17/Jun/09 10:14 PM
I found that I am able to make a JUnit test based on the repro which will fail without my change but pass with it, but I can only get it to fail (with the old code) if it is run as the first test. If other tests booting derby are run prior to this one in the same JVM, I think a successful call to getPlatformMBeanServer() has already been made and thus registered, so the call to getPlatformMBeanServer() is successful.
I did not immediately see a way to clear the platformMBeanServer. Please let me know if you know of one. Otherwise I think I will work on trying to make a call to launch a Junit test in another JVM, which I need for the store recover tests anyway. Attached is derby-3887_test_attempt_diff.txt with my initial attempt.
Kathey Marsden made changes - 18/Jun/09 12:06 AM
Hi Kathey,
I'd like to test the fix. It there a binary build available with this patch? Latest Derby at http://www.apache.org/dist/db/derby/db-derby-current-bin.tar.gz is 10.5.1.1. You could try the binaries used in the nightly testing of the 10.5 branch, found here: http://dbtg.thresher.com/derby/bits/10.5/
Dag H. Wanvik made changes - 30/Jun/09 04:02 PM
Kathey Marsden made changes - 16/Jul/09 09:24 PM
Kathey Marsden made changes - 04/Aug/09 04:32 PM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Critical
Embedded Derby fails under JBoss because of JMX-related conflicts
http://java.sun.com/j2ee/1.4/docs/api/javax/management/MBeanServerFactory.html
I notice that the property javax.management.builder.initial, if set, will be used to decide which builder
to use for the MBeansServer. A possibility is that your environment defines this property
to the missing class "org.jboss.mx.server.MBeanServerBuilderImpl", and that class is not
on your classpath. Could this be your problem?