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
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 🙁
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.