WebSphere Application Server 6.0, the nightmare continues

Life too simple? Dull? Lacking adventure? WAS V6 is here to change all that! In no time, those long, rainy afternoons sat comatose in front of the monitor will be a distant happy memory, as you swear, curse and throw your hands up in exasperation at the sheer regrettable tragedy of the continued blight of IBM on this earth. Why does IBM WebSphere exist? Because there is no god, only a random and entropic natural universe ranged against us.

(BB notes that the so-called “Father of WebSphere” recently defected from IBM. Good riddance, you fucking cu…oh wait, he went to Microsoft. Pass the Kool-aid.)

WAS V6 isn’t a terrible update from V5.1. In fact, it’s not much of an update at all. But it remains just irritating enough to keep an administrator sufficiently riled on a day-to-day basis.

What’s New

• Erm…not a great deal. Same JDK version. A minor redesign of the admin console. Something called installation profiles, which are a good idea done half-heartedly. New install path, some integration bits and pieces, a few improvements on the development side but nothing amazing. Look at V6.1 if you want something radically better different (e.g. JDK 1.5) - assuming it’s supported on your platform.
• WAS continues to be a pain in the arse whenever you have to go anywhere near it. What’s new indeed?

Issues and notes

• As discussed in a previous rant here, if you want to upgrade from Solaris 8 to Solaris 10, then you have to factor in an intermediate WAS 6.0 upgrade because it’s the only version that supports both.
• Product packaging has changed from V5; WAS ND now includes all the components of Base edition.
• For a distributed cell (cluster), you need WAS ND for the deployment manager plus WAS ND for each node…or maybe WAS Base also works on them. IBM’s documentation is contradictory on this point, suggesting that you need the ‘managed’ profile template (which is only in ND), but that the ‘default’ standalone template also works.
• Each component (appserver, plugin, IHS, etc.) now has a separate installer. Note that you can’t install the plugins in the same directory as an existing application server installation, even though the responsefile has an option to tell it where one might be (why?? what’s the point if it can’t use it?).
• There are separate versions of the fix packs for each WAS component, so be sure to download every applicable one. (The appserver fix pack covers all editions of the product.) You’ll definitely want Refresh Pack 2, otherwise it simply won’t work (btw, the RP2 installer exits quickly but continues to run in the background so check the log). And once you see the scary list of bleedin’ obvious bugs for the later fix packs, you’ll want those too. Good luck applying those fix packs though; we found we had to make our own separate copy of the WAS JDK to get the FP17 installer to work (if you use the WAS one directly, it sees its own process and assumes that WAS is running - duh). FIX: create a symlink in the updateinstaller parent directory to the WAS java/ directory.
• WAS ND requires a whopping 1.6GB for the product, fix packs and a default profile. WAS Base isn’t much better at 1.3GB. Expect the memory requirement to increase as well.
• On Solaris 10, an application server may fail to start following installation of FP17, unless the maximum number of file descriptors is increased to 10000(!). This is due to something in V6 called the HA-Manager; somewhere in an infinite number of parallel universes, there is one where the purpose and operation of this feature makes sense. See IBM technote #1244375, but note that it doesn’t currently discuss the S10 resource control (process.max-file-descriptor) that should be used. There’s also a Jython script in the Infocenter to disable the HA Manager - which doesn’t work.
• IHS 2.x is the only officially supported version with V6 according to the software prerequisites, but the 1.x plugin module is also shipped and can be used.
• Unbelievably (in the most Victor Meldrew sense of the term), the Sun JVM is run with the default client HotSpot compiler, rather than the more obviously appropriate server one. As far as I can recall, WAS V4 used the -server argument for the Java command line, but this appears to have been dropped from V5 onwards. I’m not sure there’s even a parallel universe where this makes sense. FIX: add -server to the generic JVM arguments for each application server. (There’s a brief note recommending this in the Infocenter, under “Java virtual machine settings” - so why isn’t it the default?! And why hide this important change away?)

Other bubbles

• Dileep Kumar’s tuning tips for WAS 6 on Solaris 10; not detailed but indicates what you need to examine.
• Just for kicks: WebSphere sucks.