deltalounge

This week few initiatives to find sample code caught my eyes.

Oracle Sample Code Repository

Although there was already a sample code page on Oracle’s Technet. There probably were more… Oracle has created a Sample Code Repository. Like any repository this one should centralize and consolidate the large pile of samples that is available, both from Oracle product specialist, consultant, partners and customers.

Actually this could make it easier to find samples. To make this a success, there has to be a spirit of reuse. And as the major part of developers and architects out there can testify that’s not always easy part. It boils down to the same willingness for reuse of code that is required for a successful long term Service Oriented approach of software development within an organization.
Anyway some good examples are already available. A good introduction on samplecode at Oracle Technet can be found in this podcast (m4v) that features Duncan Mills. By the way, more podcasts can be found on the techcast page.

Google Code Search

Google Code Search is not exactly new, but it caught my attention because of some blogpost and comments I saw this week. To give it a try I did some queries with it and have mixed feelings so far. Asking around co-workers did not raise and enthusiastic crowd. Leaving me with the question whether any of you out there uses Google Code Search on a regular basis? And, do you have any examples for what kind of queries this works for you?
Thanks in advance for your comments.

In today’s post you can find out why you need a changelog, and what activity to add to your upgrade roadmap.

After a recent upgrade of SOA Suite to a more recent patch level, we saw errors that some of us vaguely remembered. They were traced back to transaction timeouts in the BPEL Server. Searching Metalink, OTN, and of course Google we found out we had to change the transaction-timeout and min-instances in the orion-ejb-jar.xml. More detailed information on these settings can be found on in the SOA Suite best practises. However they are not in the spotlight of this post. So let’s go back to the main story.

At that time it seemed strange that the suggested values in the documentation, and as mentioned in blogposts, conformed with the ones we thought set in production.

Need for a changelog

Fortunately we have a changelog. We checked it, and indeed the values should correspond. We set these during a previous tuning effort. Time to check the actual orion-ejb-jar.xml in the production environment. Oops! During the SOA Suite upgrade our fine tuned orion-ejb-jar.xml was overwritten with one with default values

Recommendations

What can you learn from our experience:

• Maintain a changelog – also for configuration settings;
• Include a post upgrade action in your plan to check whether all tuning and other configuration settings are still at the appropriate values;
• Oh, and by the way, keep your test environment in sync with production (including all configuration settings)! So all this can be well planned and tested before the actual go live.

Because the growth in the number of messages that one of our customers is receiving on it’s Oracle ESB, they were looking into how to enhance it’s performance. Oracle came up with the following clues:

• Upgrade SOA Suite to a higher patch level
• Reduce logging (including instance tracking in ESB)
• Increase the number of listeners in ESB on Queues
• Turn off payload validation

In order to see what these could do for them we did some loadtesting. The upgrade to a higher patch level of SOA Suite was needed at least to get the ESB working correctly with the configured number of listeners. However because of some issues running Oracle Universal Installer there wasn’t any time left to verify that the patch resulted in increased performance.
For functional and application management reasons turning of logging was not considered an option at this stage.

Increase the number of listeners in ESB on Queues

For each ESB System the number of listeners can be configured. These listeners are used to read from JMS topics. If there is only one listener (which is the default) message are read from the JMS Topic one at a time. The first screenshot shows where to set the number of listereners using the ESB Console.

To determine the optimum number of listeners for the specific ESB, OS, hardware combination we did some loadtesting. The results for the average response time are shown in the next screenshot.

As expected the respons time increases at a certain point when the number of listeners is raised.

“Time out” messages are never created by averages. While this first graph looks great and is very convincing, we are even more interested in the 90% and maximum respons times. A chart for these statistics has been included as well. Analyzing this graph one can conclude that this has an even stronger support to set the number of listeners to an appropriate level.

From this experiments it can be concluded that the response time can significantly be reduced by setting the number of listeners of an ESB system to the appropriate level. The maximum respons time has can be decreased by over 50%. This has a significant impact on the availability of the services exposed using the ESB.

Turn off payload validation

Another idea to enhance the performance is to turn off payload validation. Needless to say that this also has functional aspect. In most cases the validation that is performed here has some kind of business (related goal), like data quality. To switch it off, has impact, and the validation has te be migrated to some place else in the software.

The performance results can be dramatic. In a positive way! As is shown in the figure on the right, the respons time can be reduced to a fifth of the original. This goes for both the average and the maximum respons times.

If you can change your service so payload validation at this point is no longer required, this is a great step in enhancing the Oracle ESB’s performance.

SOA Suite patch set 5 – also known as SOA Suite 10.1.3.5 – is available, as is mentioned in this blog post. The patch can be downloaded here. We have been waiting for this patch as described earlier. The release document can be found here.

Metalink doc.id 745094.1 promises that 10.1.3.5 is the SOA Suite 10g release that wil be supported on WebLogic 10.3. Where older release were supported on 9.2 (although for 10.1.3.4 requiring the patch 490612 and patch 7337034).

So far the Metalink note has not been updated and is still stating a “planned” support. It could be that it is still a little premature to draw conclusions, since the released downloads and documentation pages haven’t yet been update with the information on this release.
Beside that no information on support on WebLogic 10.3 was found in the release documentation. The OTN downloaded page still features SOASuite10133OnWeblogic.