We have spotted a lovely issue with patching Connections 4 to CR2 and above when using a < connections path > /data/shared folder on anything other than a single WAS node.
For example in a standard one node connections install the < connections path > /data/shared folder is on the same machine as the connections instance .. in a multi-node instance the shared data folder is normally on a san / network share.
In my instance the shared data was on a RHEL nfs share that was mapped to the node machines as a filesystem, we had seen no issue with this at all, until we attempted to update the Connections version 4.0 instance to CR4 – the CR4 updates installed correctly but on starting the connections servers up, the news feed and a lot of the widget data was not displaying correctly – throwing a javascript error!! I was stumped, I had seen this before, this particular instance is owned and run by a non root user, when the instances are started as root the permissions are not set correctly and it throws an error.
This was not the case here. The non root user owned all the files and had started the Connections servers, so it should work. There appeared to be no obvious errors in the SystemOut logs for the servers.
Flummoxed by this – I rolled the patches off, at Connections 4.0 again restarted the servers and it worked correctly.
Convinced there may be an issue in CR4 I decided to attempt CR2, so later on in the week had another attempt at patching. Stuart was also doing some maintenance on another customer machine at the same time so we worked through it together. Once the CR2 patches were installed correctly we saw the same issue. So with Stuart checking the errors thrown and I checking the logs and a fiddler trace we managed to deduce that when the fix packs were applying , the wrong webresources directory was being updated.
Under < connections path > /data/shared/provision/webresources on the local machine – all the files had been updated with the new fix pack files NOT the actual shared data folder on the network share. The WebSphere variable for the instance has the correct folder mapped and all the other files from the /data/shared folder are being served correctly.
The quick resolution to this was to delete all the files under the networked share folder /provision/webresources and copy the files from the local machine /data/shared/provision/webresources – restart the servers and as if by magic it works.
IBM have acknowledged that this is an issue and hopefully we wont see this issue again .. but IF you see something similar and you have a shared folder that is not on your connections machine – check to ensure the correct set of files has been updated.
Yet another one of those *fun* fixes – hope it helps someone else save some pain