Thursday 4 December 2014

WebSphere MQ and WebSphere Application Server - Gah, why oh why does this happen ?

The context

This is part of an integration between WebSphere Application Server (WAS) and WebSphere MQ (WMQ), in the context of integration between IBM Integration Bus and IBM Business Process Manager.

The detail

As I documented last time around: -


...
Update WAS MQ Provider to support local bindings ( need to add native path )

AdminTask.manageWMQ('"WebSphere MQ Resource Adapter(cells/bpm85Cell1/nodes/AppSrv01Node/servers/foobar|resources.xml#J2CResourceAdapter_1416556034607)"', '[-nativePath /opt/mqm/java/lib64/ -disableWMQ false ]')
AdminConfig.save()
AdminNodeManagement.syncActiveNodes()
...

It galled me to realise that, having updated the Resource Adapter, I needed to restart my cluster not ONCE but TWICE, as evidenced by this exception during startup: -

FFDC Incident emitted on /opt/ibm/WebSphereProfiles/ODMCell1AppSrv01/logs/ffdc/AppSrv01Node-DSServer_228e6d12_14.12.04_14.37.40.7908039937528265509387.txt null 789
[04/12/14 14:37:40:797 GMT] 00000001 WsServerImpl  W   WSVR0100W: An error occurred initializing, AppSrv01Node-DSServer [class com.ibm.ws.runtime.component.ServerImpl] com.ibm.ws.exception.ConfigurationWarning: WMSG1623E: The WebSphere MQ messaging provider installed at /opt/ibm/WebSphere/AppServer/installedConnectors/wmq.jmsra.rar has been updated and an application server restart is required to pick up this update. The WebSphere MQ messaging provider has been disabled.

 It's not a big issue in the grand scheme of things, but it is a bit of a niggle :-(

This is documented in the WAS Knowledge Centre: -


...
If you are running in an application server environment, you must restart all affected servers twice when you have changed the native path information. If you do not restart all of the affected servers twice, a WMSG1623E message is produced, indicating that the WebSphere MQ messaging provider is not available.

If you are running in a client environment, you must rerun the client program twice. Otherwise, a WMSG2013E message is produced.

Whichever environment you are running in, until you perform these restarts any attempt to use a WebSphere MQ messaging provider resource (for example, a connection factory) from one of the affected servers causes a javax.naming.NamingException and a WMSG2003E message.
....

However, it is quite annoying :-(

No comments:

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="{...