Tuesday, 22 January 2013

Fun with IBM Business Monitor 8.0.1 and Cognos BI 10.1 on Red Hat Enterprise Linux 6.3

This is a strange one, but at least I have a solution.

Having recently ( January 17th ) installed IBM Business Monitor 8.0.1 ( aka BAM ) on a VMware image running Red Hat Enterprise Linux 6.3 x86-64, I was surprised to see the following exception: -

[1/22/13 14:48:10:787 GMT] 00000000 WsServerImpl  W   WSVR0100W: An error occurred initializing, BAM801.Support.bamNode01.0 [class com.ibm.ws.runtime.component.ServerImpl]
com.ibm.ws.exception.ConfigurationWarning: Exception caught when initializing component
Caused by: java.lang.NoClassDefFoundError: com.ibm.ws.process.linuxutil.ThreadUtil (initialization failure)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:168)


when I started one of the clusters today.

This cluster ( BAM801.Support.bamNode01.0 ) hosts IBM Cognos BI 10.1, which is a core component of BAM, and is used to provide cube views etc. of business metrics and KPIs.

The strange thing is that I did not see, or perhaps notice, this exception when I last started the cluster last Friday.

Be that as it may, this is a known issue with the combination of BAM, Cognos and 64-bit RHEL, as evidenced by this IBM Technote: -


which says, in part: -

Cause

The libfreebl3.so file shipped with Cognos V10.1.1 is not compatible with Red Hat Enterprise Linux 6.x. The IBM Business Monitor server fails to start because Cognos fails to start.

Resolving the problem

Add the following like to the .profile, .bashrc, or appropiate login initialization script for the Cognos user account:

export LD_PRELOAD=/lib64/libfreebl3.so

In order to test this, without rebooting my server, I updated my local Bash shell: -

export LD_PRELOAD=/lib64/libfreebl3.so

and validated the change: -

$ set | grep -i PRELOAD

LD_PRELOAD=/lib64/libfreebl3.so

$ echo $LD_PRELOAD

/lib64/libfreebl3.so

I then manually started the cluster from within that shell: -

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/startServer.sh BAM801.Support.bamNode01.0

In this way, I could test the change without rebooting. Had I not done this, when I started the cluster from within the WAS Integrated Solutions Console, via the Deployment Manager, the LD_PRELOAD environment change would NOT have been picked up.

Lo and behold, this worked a treat, and I now have a working Cognos BI environment.

My next step was to make this change permanent for the user who "owns" the WAS processes - wasadmin - by adding the line: -

export LD_PRELOAD=/lib64/libfreebl3.so

to: -

/home/wasadmin/.bashrc 

Actually, this goes along with some WebSphere MQ and Message Broker stuff about which I have previously blogged, so I now have: -

source /opt/ibm/mqsi/8.0.0.1/bin/mqsiprofile
export LD_LIBRARY_PATH=/opt/mqm/java/lib:$LD_LIBRARY_PATH
export LD_PRELOAD=/lib64/libfreebl3.so

Now, the next time that I log in as wasadmin and spin up any WAS process, including the Deployment Manager, Node Agent etc. the LD_PRELOAD variable will be picked up.

Good stuff …..

3 comments:

BennyInc said...
This comment has been removed by the author.
BennyInc said...

I would rather recommend adding that variable in the Administrative Console at Application servers > {server_hosting_Cognos} > Process definition > Deployment Environments > Environment Entries

Dave Hay said...

@Benny, OK, that makes sense. Better still, let's script it using Jython :-)

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...