OraTransplant

Two interesting posts by Steven Chan

I finally managed to read up on all the blogs and stumbled upon two very interesting articles by Steven Chan that are very relevant to us:

• OracleAS 10g Upgrade Paths which describes how Oracle eBusiness Suite handles the upgrade and co-existence of the later AppServer versions. As Steven describes there are a lot of Application Server releases and he is trying to shed some light on them.
• Will the Real JRE Please Stand Up?. This posting describes why you need a specially patches version of Sun 1.5.0_10. Very interesting read and very relevant to us as a technology customer who uses the same tech stack as eBusiness Suite.

Oracle’s plans for Forms version 11g

Tonight Oracle Product Management held a webinar about their future plans with Oracle Forms version 11 for the Customer Advisory Board for Development Tools. As you might know I’m a member of that advisory board, so I attended the webinar.

In this blog entry I would like to outline the plans as they were presented. Of course the webinar had the usual disclaimer that it was for informational purposes only and it is not a commitment to deliver these features.

Forms version 11 is planned to be part of Oracle Application server version 11, which is planned in 12-15 months, which means summer 2007. Forms will not participate in the 10.1.3 platform, so the version 11 will be the first after the current 10.1.2 line.

The primary focus for this new Forms version is with three areas; Interoperability, Deployment and Administration. In total, Oracle presented 8 new features that are approved and scheduled for version 11. Some of the features are even already being worked on. There’s a fair chance that all of these 8 new features will make it into Forms 11. This means it is not guaranteed that all these new features will make it in the final version. I assume that’s due to the normal time and budget limitations.

Let’s get on with describing the eight new features:

External Events

The first very exiting new feature is External Events. This will make it possible to call into Forms from the outside world. Currently we just have user initiated events and timers that can trigger code being executed in the Form (and thus on the Forms server). With External Events, Forms can be triggered by messages in Oracle Advanced Queuing in the database. Since BPEL can also communicate with Oracle AQ, this enabled triggering events in Oracle Forms from Oracle BPEL.

This strengthens the central position Oracle BPEL seems to take in the Service Oriented offering by Oracle. BPEL can already communicate with a whole range of external sources (monitor changing files, web services, mail, wireless, JMS, database data, .Net services, B2B, EDI, etc.). Using Oracle Advanced Queuing and Oracle BPEL all of these external systems can basically trigger events in Oracle Forms asynchronously.

But how can an event triggered on the server propagate to the client? The Forms client uses the HTTP protocol which is by its nature request/response only. If the user is actively working with the Forms session, any server side triggered event can propagate to the client. For example, if the triggered event changes some visual attribute, the client is synchronized on the next user interaction. But what if the user is idle? Oracle solved this with a polling mechanism. There is a MAX_EVENT_WAIT setting that sets the polling interval. You can define this in your configuration file, but you can also change this at runtime with SET_APPLICATION_PROPERTY.

The External Events sounds like an interesting new feature to Oracle Forms, but the downside is the extra resources used by the polling mechanism. You have to be wise in setting the polling interval.

Scheduled pre-starts

Back in the old days, every new user session had to create a new Forms server process on the fly. This resulted in delays for every new session. In Forms 10g, pre-starting was introduced. This allows you to define a number of pre-started sessions. This reduces the startup time of new sessions.

This works fine, but is a bit rigid. With Forms 11 you can schedule pre-starts. You manage this from the Enterprise Manager. You can schedule in a number of ways; define the number of pre-starts at server startup (what we have today in 10g), set a number of pre-starts to be effective immediately, schedule a number of pre-starts delayed (e.g. tomorrow at 11:00 AM pre-start 25 sessions), daily, weekly and monthly. This enables you to have a different number of pre-started sessions available at different moments. For example, be sure to have 25 extra pre-started session every Friday at 11:30 AM when the end-of-week cycle starts and user load increases.

JavaScript integration

The third (and for me most interesting) feature presented was the JavaScript integration. This goes both ways. JavaScript in the web page can raise Forms events and you can call JavaScript from Forms. This JavaScript integration enables you to mix and match your “old” forms with newer web applications (e.g. JSP or JSF).

The Forms applet has an extra method raiseEvent that can be called from JavaScript. This method accepts two arguments: the name of the event and a payload. A snippet of JavaScript to illustrate this:

function raiseFormsEvent(data) {
  forms=document.getElementById('frm');
  forms.raiseEvent('myEvent', data);
};

If this JavaScript function is called it will fire a WHEN-CUSTOM-JAVASCRIPT-EVENT trigger in Forms. This trigger can access two new system variables: javascript_event_name (the name of the event) and javascript_event_value (the data/payload). An example of such a WHEN-CUSTOM-JAVASCRIPT-EVENT trigger:

declare
  eventName  varchar2(30) := :system.javascript_event_name;
  eventValue varchar2(100);
begin
  if (eventName='myEvent') then
    eventValue := :system.javascript_event_value;
    handleMyEvent(eventValue);
  end if;
end;

It also works the other way around. You can call JavaScript from Forms with a new function javascript_eval in the already existing web package:

function web.javascript_eval (expression varchar2,
  target varchar2 default null)
return varchar2;

With the target argument you can specify the window in which to evaluate the javascript. If not specified, the window the applet is in is used.

Java Events

In version 10g, Java Components extending VBean (Java Beans) can raise server events. In version 11, all Pluggable Java Components (PJCs) will be able to raise these events. This will no longer be restricted to VBean childs.

We don’t use Java Components (yet), so this is not a very exiting feature for our environment.

Proxy User support

Forms 11 will be able to connect to the database thru a Proxy user. A proxy user only has the privileges to connect only. It does not have privileges to modify or select any data. The proxy user is allowed to connect “on behalf” of another user. This “other user” is the real user using Forms. That user does not require connect privileges in this scenario. This keeps these users out of the database directly with tools like SQL*Plus or ODBC connections.

Both in the database and in Forms you can get both the proxy user name and the “real user” name. In Forms this will be through GET_APPLICATION_PROPERTY calls.

PL/SQL tracing

Forms 10g already has a tracing facility. Unfortunately this trace does not log the names and parameters for called PL/SQL. This will change in version 11. This will log the name of all called procedures and functions, including the IN and OUT parameters, whether the call is to a local program unit or stored PL/SQL in the database.

Performance tuning

Forms 11 will include a Performance Tuning Tool that can identify and correct common performance draining application constructs. It will start by making a duplicate of the form(s) to scan, it will scan it and suggest ways to tune performance. You can call it by using a GUI or via the command line.

Typical constructs it will scan for:

• Raise on entry property set for initially not displayed canvasses.
• Unnecessary boilerplate objects
• Prompt vs. boilerplate text
• Explicit to implicit cursors. Back in the old days explicit cursors were preferred due to performance. But since (probably) version 9.2 of the database implicit cursors have been highly optimized and should now be preferred over explicit cursors.
• Calls to SYNCHRONIZE
• Use of CLIENT_TEXT_IO
• URL_To_Client vs. AS_To_Client
• Timers
• Interaction mode
• Query array size
• Number of records buffered
• Bind vs. PL/SQL variables
• Mouse-Up and Mouse-Down triggers

I guess it will be similar to the Forms Migration Assistant that is based on the JDAPI.

Oracle Diagnostics Logging (ODL)

All the different components of the Application Server have their own logging strategy, which basically makes it a mess. You are left with dozens of log files in very different locations with very different naming strategies.

Oracle has developed the common logging mechanism ODL (Oracle Diagnostics Logging). This has to be used by all Application Server 11 components. It extends the Java logging framework in J2SE (java.util.logging API). In the first incarnation only the Forms Servlet will use the ODL framework.

Using OLD means that the log files will be easily accessible from Enterprise Manager. It also enables correlation of messages in different log files. It also handles things like log file rotation and file size restrictions.

Conclusion

Personally I was impressed with all the new planned (and scheduled) features for Forms version 11. Lots of people have been saying that Oracle Forms is dead and that Oracle is abandoning Forms and minimizing development. To me, this proves otherwise. Oracle is not allocating the amount of resource to Forms as it does to JDeveloper, but I don’t think it is necessary for a mature product like Forms. Especially features like External Events and the JavaScript Integration opens up Forms for integration with other technologies. This means Forms can be part of your architecture for years to come and can integrate with all the new BPEL, SOA and other stuff coming our way. It means Oracle is protecting your investments in Forms technology while still enabling you to start using newer technologies while integrating both.

Future of Forms

I just attended a session by Robin Zimmermann on the future of Forms and the move to SOA. He did his best to get the message across that FORMS IS NOT DEAD! Oracle has been saying this for a while but it just seems hard to accept for a lot of people. It looks like Forms is still an important and interesting product since the room was almost full.

He then went on to explain some of the new features in the latest Forms releases and what’s coming next. The main focus is on integrating with the J2EE/SOA world. He also gave a short introduction to JDeveloper and ADF for the ones that do want to make the switch from Forms to Java or (more likely) want to do both and integrate.

The two major new features of 10.1.2 he showed where JVM Pooling and End User Monitoring. JVM Pooling is what was really necessary to make the Java Importer useful. With the Java Importer you can “import” a Java class into your Form application. It will basically create a PL/SQL wrapper for the class so you can call it from any program unit or trigger. In the pre-10.1.2 releases this would mean that each Forms server process would have its own JVM. A JVM can be an expensive thing and can consume a considerable amount of memory. This is not something you want spawned for each individual user. Even more so, since you cannot set the parameters used for this JVM meaning it will use the defaults for your platform. With JVM pooling the JVM can be shared across multiple Forms sessions.

The other thing is the End User Monitoring. This uses Javascript to measure the time it takes to startup a form, open a form using open_form/call_form/new_form, execute a query and perform a commit. All this data is stored and you can analyze and graph it. The important thing is that it measures the time it takes on the client side, so it is really representative of the end user experience. You’ll have to use Enterprise Manager Grid Control to take advantage of this feature. It is not included in the normal server control of EM.

The things that really caught my attention were the JavaScript API and Java Callback planned for future releases. Forms has been able to call Java in a number of ways on both the client and the server for a while. But is has been very hard to do it the other way around; have some Java code control the Forms application. This is what the JavaScript API and Java Callback have to offer. The JavaScript API will make it possible to control the Forms application on the client by controlling it from JavaScript. The Java Callback is at the server end and allows a Java class to control the running Forms process. This sounds like music in my ears and is exactly what we need to slowly migrate from Forms to J2EE/web applications. I want to switch the control of our applications away from the menu in Forms and to the web application by using links and buttons on a webpage. However, I don’t want to navigate away from a running Forms applet without doing normal post-form processing warning a user about outstanding changes and perhaps committing these.

After the session I went up to Robin to ask about an expected timeframe for the JavaScript API and/or Java Callback. Unfortunately he couldn’t give any, but he did suggest another solution to my problem. It will require some work but it is doable. I should be able to create my own small Java applet running on the same page as the Forms applet. My own applet would be invisible to the user but can receive events from other applications (perhaps JavaScript on the client or some sort of communication from the server). My own applet can then make a call to Forms activating a WHEN-CUSTOM-EVENT trigger. That trigger could then do whatever processing is necessary. This is definitely something I will investigate further when I’m back at the office. Wouldn’t it be great if Oracle would publish some sort of whitepaper on this (if it isn’t there yet)? I will ask around at the Customer Advisory Board tomorrow.

I must say this session was a great way to start my official part of OpenWorld. Now off to lunch and hurry to the next session at 13:30.

Patch 9.0.4.2.0 misses MouseWheelHandler.class

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.