OraTransplant

Patch 9.0.4.2.0 misses MouseWheelHandler.class

3 September 2005 at 16:56 CEST | In Bugs and issues, Forms, Oracle, Patches and upgrades |

We’ve seen a dramatic drop in performance of Oracle Forms since we installed patch set 9.0.4.2.0. As it turns out this is caused by a missing class called MouseWheelHandler. In this blog entry I’ll describe how I found out about it and how we fixed it. Looking at the Java Console (right-mouse click on the Java icon in your system tray and select Show Console) we could see hundreds of the same exceptions:

sun.plugin.cache.DownloadException
	at sun.plugin.cache.CachedFileLoader.load(Unknown Source)
	at sun.plugin.cache.FileCache.get(Unknown Source)
	at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.connectWithCache(Unknown Source)
	at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.connect(Unknown Source)
	at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.getInputStream(Unknown Source)
	at java.net.HttpURLConnection.getResponseCode(Unknown Source)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
	at sun.applet.AppletClassLoader.getBytes(Unknown Source)
	at sun.applet.AppletClassLoader.access$100(Unknown Source)
	at sun.applet.AppletClassLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.applet.AppletClassLoader.findClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.applet.AppletClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Unknown Source)
	at oracle.ewt.scrolling.MouseWheelUtils._getMouseWheelHandlerClass(Unknown Source)
	at oracle.ewt.scrolling.MouseWheelUtils._getMouseWheelHandlerInstance(Unknown Source)
	at oracle.ewt.scrolling.MouseWheelUtils.addMouseWheelListener(Unknown Source)
	at oracle.ewt.scrolling.scrollBox.ScrollBox.setWheelScrollingEnabled(Unknown Source)
	at oracle.ewt.scrolling.scrollBox.ScrollBox.(Unknown Source)
	at oracle.forms.ui.FScrollBox.(Unknown Source)
	at oracle.forms.handler.FormCanvas.onCreate(Unknown Source)
	at oracle.forms.engine.Runform.onCreateHandler(Unknown Source)
	at oracle.forms.engine.Runform.processMessage(Unknown Source)
	at oracle.forms.engine.Runform.processSet(Unknown Source)
	at oracle.forms.engine.Runform.onMessageReal(Unknown Source)
	at oracle.forms.engine.Runform.onMessage(Unknown Source)
	at oracle.forms.engine.Runform.sendInitialMessage(Unknown Source)
	at oracle.forms.engine.Runform.startRunform(Unknown Source)
	at oracle.forms.engine.Main.createRunform(Unknown Source)
	at oracle.forms.engine.Main.start(Unknown Source)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Some more testing revealed that you get a bunch of these errors when opening a Form. It looks related to the number of items on the form. The more items you have, the more DownloadExceptions.

I’ve noticed before that Sun JPI raises such a DownloadException when retrieving a file that does not exist over SSL. That’s not really an issue since the file couldn’t be downloaded anyway. However, in this case it seems to cause quite some delay. It looks like handling the DownloadException costs quite some CPU resources. On low end machines (Celeron 600MHz) you can see the CPU load peek to 100% and stay there for a while. Opening on of our larger forms in Query mode (so without any database interaction) took 6 seconds before the 9.0.4.2.0 patch. After installing the patch we started getting these download exceptions and the startup time of this form increased to 28 seconds. That’s more than four times as long!

I then looked at the Apache logs to find out which file the Forms applet was trying to download. It turned out it is trying to download /forms90/java/oracle/ewt/scrolling/MouseWheelHandler.class over and over. You can also see this from the Java error stack. You can see a method oracle.ewt.scrolling.MouseWheelUtils._getMouseWheelHandlerClass. By the looks of its name it is probably to get a MouseWheelHandler class. That’s exactly the file it is trying to download.

Normally, the Forms applet doesn’t need to download additional class files during its operation. Everything it needs should be in the JAR file. I opened f90all.jar to have a look. I browsed to the directory oracle/ewt/scrolling as seen in the 404 errors in the Apache log. In that directory I found a MouseWheelScrolling.class and a MouseWheelUtils.class but no MouseWheelHandler.class.

I then took a copy of the f90all.jar for Forms 9.0.4.1.0 as we didn’t have the problems with that version. As it turns out none of these mouse wheel classes are in that version. It looks like Oracle should have added three classes to the 9.0.4.2.0 patch set, but forgot one.

It was at this moment that I logged a TAR at MetaLink to let Oracle have a look. The support engineer quickly found (unpublished) bug 4259148, which apparently is exactly about this issue. That bug was filed against version 10.x of Forms and was fixed in the final release of 10.1.2.0.2. At some stage the MouseWheelHandler.class was also missing from an (internal) version 10.x of Forms and it was fixed before the final release.

This gave me the idea to download the just release 10.1.2.0.2 version and have a look at the JAR file. All three mouse wheel classes are there! I checked the signature of the two that were already in the 9.0.4.2.0 version and they’re exactly the same. If they haven’t changed since 9.0.4.2.0, then there might be a good change the extra MouseWheelHandler class might just work in version 9.0.4.2.0.

During all this investigation of my own, the Oracle support engineer (Roelof) kept pushing Development for a fix, since it was a major hit on performance for our system and complaints were very frequent. I must say that Roelof did a great job. He was right on top of it and really helped me a lot. After assuring Oracle that we couldn’t upgrade to 10.1.2.0.2 at this moment, they agreed to make a fix for the issue in version 9.0.4.2.0.

But we really needed the fix ASAP, since we were going to shutdown our old Citrix client-server Forms 6i environment. We have been running this in parallel with the new Forms 10g systems for two months. We really needed to shutdown the Citrix systems but we users were just refusing to use the Forms 10g systems because of the performance.

In the end, I took the risk and repackaged the JAR file myself adding the missing class file from the v10.1.2.0.2 JAR file. This even gave me the opportunity to re-sign the JAR file myself, getting rid of the confusion certificate by “Developer/Oracle”. It’s all documented at OTN and on my blog.

This completely fixed the problem and we’re back at the performance we have before the 9.0.4.2.0 patch. Oracle is still working on the official patch, but I guess (hope) that they are doing exactly the same as I did: just adding the MouseWheelHandler.class from Forms 10.1.2.0.2 to the f90all.jar of Forms 9.0.4.2.0.

So, if you are having performance problems of your own since the upgrade of Forms 9.0.4.2.0 this might be one of the reasons.

Other difficult to diagnose issues we had impacting performance are a faulty DNS server and having large amounts of data on your Windows clipboard.

Update 19-sep-2005: Oracle has just release a one-off patch for the issue. I didn’t have a chance to look at it yet, since I’m at Oracle OpenWorld in San Francisco. If you want to have a look for yourself just find patch 4259148. Looking at the ReadMe it’s just the new JAR files with (I guess) the missing MouseWheel class.