WMSG1603E - An error occurred trying to read the bundle
I encountered a strange error this weekend whilst installing multiple fix packs across numerous WAS systems. Despite installing these fixes numerous times, this error only occurred on one system.
I was upgrading from WAS 6.1.0.21 to 6.1.0.27 - that included WAS, SDK, IHS and Plugin fixes.
After installing the fix packs when I restarted the server I got the following error:
WMSG1603E: An internal error occurred. It was not possible to register the WebSphere MQ JMS client with the application serve
r due to exception org.osgi.framework.BundleException: An error occurred trying to read the bundle
followed by a java stack which included the following:
WMSG1603E: An internal error occurred. It was not possible to register the WebSphere MQ JMS client with the application serve
r due to exception org.osgi.framework.BundleException: An error occurred trying to read the bundle
A quick search and the reason was obvious. This WAS system does not run as root but when I checked the file permissions on the org.osgi.framework bundles in {WAS_INSTALL_DIR}/profiles/{PROFILE_NAME}/configuration the bundle in question was owned by root:
drwxr-x--- 2 wasadm wasadm 256 07 Feb 10:25 org.eclipse.update
drwxr-xr-x 4 root system 256 07 Feb 10:26 org.eclipse.osgi
drwxr-x--- 3 wasadm wasadm 256 04 Jan 11:24 org.eclipse.core.runtime
A quick change of permissions on the directory and all sub directories followed by a restart and everything came up fine.
Friday, March 5, 2010
Test connection on each node for cell scope datasource
Test connection on each node for cell scope datasource
I am sure pretty much every WAS administrator has used the "test connection" button in the WAS console to prove a JDBC datasource has been set up correctly.
Although not a problem, something that always got me and didn't seem to be as good as it could be, is the fact that if you work in a large scale enironment you may well end up setting the datasource at a cell level as this would cut down on the time it takes to set up a datasource on each node or appserver and also redude the likelihood of something being mis typed. Hoever, if you do this and then run test connection, the connection is just from the dmgr as you can see by lookiig in the dmgr logs.
So what happens if you have 10, 20 or more nodes and you want to make sure that all of them can connect correctly to the database. You could telnet from each box to the DB server on the correct port, but that just shows network connectivity rather than a full databsee connection.
I assumed this could be done in a jython script but it took me a day or 2 to figure this out. If I connected to the nodeagent in wsadmin, I couldn't get the config details of the datasources as these are accessed from a wsadmin session connected to the dmgr. But running a test connection when in a wsadmin session connected to the dmgr just does the same as the "test connection" through the admin console.
In the end, I managed to write a simple unix script, which does the following:
1. Open a wsadmin session to the dmgr to get the datasource ids and write these to a file, passing in the name of the cell
2. open a wsadmin session to each nodeagent, read the datasource id's from the file, then run a test connection.
This is the basic unix script:
###########################################################################
CELL=epwsdr21Cell
NODES="epwsdr21 epwsdr22 epwsdr23 epwsdr24 epbtdr21"
PORT=8878
echo "Running connection from each node to the datasources in WAS"
echo "Connecting to dmgr through wsadmin....."
# Connect to the dmgr through wsadmin - pass in the name of the cell - and run scropt dsconnect.py
/usr/was6/WebSphere/AppServer/bin/wsadmin.sh -lang jython -f ./jython/dsconnect.py $CELL
echo "Connecting to each nodeagent to run test connections....."
for node in $NODES;do
echo "Connecting to ${node} on port ${PORT} through wsadmin"
# Connect to each nodeagent in my list of nodes above - and run script dsconnect2.py
/usr/was6/WebSphere/AppServer/bin/wsadmin.sh -lang jython -conntype SOAP -host $node -port $PORT -f ./jython/dsconnect2.py $node
done
echo 'Complete '
#############################################################################
And here is what is in the first jython script - dsconnect.py
# Jython script to get the datasource id's once connected to the dmgr through wsadmin
import sys
print ' '
print "Getting datasources for cell " + sys.argv[0]
# First build the cell name we are interested in fromm the cell name passed from the main script
constructcell ="/Cell:" + sys.argv[0] + "/"
# get the cell id
cellid = AdminConfig.getid( constructcell )
# Get the datasource id's
print 'Datasources found are listed below:'
# In this instance I am after v4 datasources for v5 datasources use "dsid = AdminConfig.list("DataSource", cellid).splitlines()"
dsid = AdminConfig.list("WAS40DataSource", cellid).splitlines()
print dsid
# Now open a tmp file and write the list of dsid's to tfe file - this will be a string rather than a jython list
f=open('/tmp/dsconnect.out','w')
s=str(dsid)
f.write(s)
f.close()
##############################################################################
So the list of ids is written to /tmp/dsconnect.out, now the second script is called for each nodeagent I want to connect to and then run a test connection. The list that has been put into a file will be seen as a jython string rather than a list which is why I use the eval statment so it goes back into string format
# Jython script to run a test connection on a list of datasources
import sys
#
# Open temp file to get string of datasource ids and assign to a jython list
f=open('/tmp/dsconnect.out')
test=f.read()
dsids=eval(test)
f.close()
for ds in dsids:
print ' '
print 'Testing connection from ' + sys.argv[0] + ' to ' + ds
try:
outp=AdminControl.testConnection(ds)
except:
print 'Error connecting to datasource'
print outp
else:
print outp
##############################################################################
I am sure pretty much every WAS administrator has used the "test connection" button in the WAS console to prove a JDBC datasource has been set up correctly.
Although not a problem, something that always got me and didn't seem to be as good as it could be, is the fact that if you work in a large scale enironment you may well end up setting the datasource at a cell level as this would cut down on the time it takes to set up a datasource on each node or appserver and also redude the likelihood of something being mis typed. Hoever, if you do this and then run test connection, the connection is just from the dmgr as you can see by lookiig in the dmgr logs.
So what happens if you have 10, 20 or more nodes and you want to make sure that all of them can connect correctly to the database. You could telnet from each box to the DB server on the correct port, but that just shows network connectivity rather than a full databsee connection.
I assumed this could be done in a jython script but it took me a day or 2 to figure this out. If I connected to the nodeagent in wsadmin, I couldn't get the config details of the datasources as these are accessed from a wsadmin session connected to the dmgr. But running a test connection when in a wsadmin session connected to the dmgr just does the same as the "test connection" through the admin console.
In the end, I managed to write a simple unix script, which does the following:
1. Open a wsadmin session to the dmgr to get the datasource ids and write these to a file, passing in the name of the cell
2. open a wsadmin session to each nodeagent, read the datasource id's from the file, then run a test connection.
This is the basic unix script:
###########################################################################
CELL=epwsdr21Cell
NODES="epwsdr21 epwsdr22 epwsdr23 epwsdr24 epbtdr21"
PORT=8878
echo "Running connection from each node to the datasources in WAS"
echo "Connecting to dmgr through wsadmin....."
# Connect to the dmgr through wsadmin - pass in the name of the cell - and run scropt dsconnect.py
/usr/was6/WebSphere/AppServer/bin/wsadmin.sh -lang jython -f ./jython/dsconnect.py $CELL
echo "Connecting to each nodeagent to run test connections....."
for node in $NODES;do
echo "Connecting to ${node} on port ${PORT} through wsadmin"
# Connect to each nodeagent in my list of nodes above - and run script dsconnect2.py
/usr/was6/WebSphere/AppServer/bin/wsadmin.sh -lang jython -conntype SOAP -host $node -port $PORT -f ./jython/dsconnect2.py $node
done
echo 'Complete '
#############################################################################
And here is what is in the first jython script - dsconnect.py
# Jython script to get the datasource id's once connected to the dmgr through wsadmin
import sys
print ' '
print "Getting datasources for cell " + sys.argv[0]
# First build the cell name we are interested in fromm the cell name passed from the main script
constructcell ="/Cell:" + sys.argv[0] + "/"
# get the cell id
cellid = AdminConfig.getid( constructcell )
# Get the datasource id's
print 'Datasources found are listed below:'
# In this instance I am after v4 datasources for v5 datasources use "dsid = AdminConfig.list("DataSource", cellid).splitlines()"
dsid = AdminConfig.list("WAS40DataSource", cellid).splitlines()
print dsid
# Now open a tmp file and write the list of dsid's to tfe file - this will be a string rather than a jython list
f=open('/tmp/dsconnect.out','w')
s=str(dsid)
f.write(s)
f.close()
##############################################################################
So the list of ids is written to /tmp/dsconnect.out, now the second script is called for each nodeagent I want to connect to and then run a test connection. The list that has been put into a file will be seen as a jython string rather than a list which is why I use the eval statment so it goes back into string format
# Jython script to run a test connection on a list of datasources
import sys
#
# Open temp file to get string of datasource ids and assign to a jython list
f=open('/tmp/dsconnect.out')
test=f.read()
dsids=eval(test)
f.close()
for ds in dsids:
print ' '
print 'Testing connection from ' + sys.argv[0] + ' to ' + ds
try:
outp=AdminControl.testConnection(ds)
except:
print 'Error connecting to datasource'
print outp
else:
print outp
##############################################################################
Subscribe to:
Posts (Atom)