Watch tuning settings when applying SOA Suite patchset

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.

One thought on “Watch tuning settings when applying SOA Suite patchset

  1. Frits Hoogland

    keep all config files in a version control system, like subversion. this will give you total insight in changes of any kind. (checking the config after an upgrade is done with one command that way!)

Leave a Reply

Your email address will not be published. Required fields are marked *