CLFRN1152E: Unable to contact the global search service. Please start the Search application if it is not started. If the service is started, please check the network connection.

Working through my various notes relating to a recent Lotus Connections 2.5 clustered installation, we did see this error: -

CLFRN1152E: Unable to contact the global search service. Please start the Search application if it is not started. If the service is started, please check the network connection

This occurred despite the Search application ( actually installed onto the same WAS instance that hosts Home Page and News, as per the recommended practice ) being started.

The problem was due to my having failed to completely update LotusConnections-config.xml after the cluster.

This wiki article: -

http://www-10.lotus.com/ldd/lcwiki.nsf/dx/S1_Editing_the_configuration_file

directs you to update the config. file ( using the wasadmin scripts to check it out and back in again ) to reflect the fact that all of the services are now accessed via an HTTP server ( actually a load balancer in front of TWO HTTP servers, in my case ).

I'd missed this crucial line: -

 All entries in this file should be updated to the Web server URL with the exception of the three bootstrap entries – two of which should not be modified at all. The only bootstrap entry which must be modified is that for search. Leave the host and port blank as shown:

In essence, I had to change: -

    <sloc:serviceReference bootstrapHost="dm.uk.ibm.com" bootstrapPort="2811" clusterName="Homepage" enabled="true" serviceName="search" ssl_enabled="false">

to: -

    <sloc:serviceReference bootstrapHost="" bootstrapPort="" clusterName="Homepage" enabled="true" serviceName="search" ssl_enabled="false">

In other words, I removed the host name and port number for the bootstrapHost and bootstrapPort parameters, but *ONLY* for the Search service.

Prior to this error, we had been seeing: -

[09/11/09 15:01:12:978 GMT] 00000037 WsnInitCtxFac W   NMSV0602E: Naming Service unavailable. A communications error occurred.
[09/11/09 15:01:12:979 GMT] 00000037 TagCloudServi E com.ibm.lconn.comm.internal.service.TagCloudServiceImpl getEJBSearchHandlerFromSearchEjbDefault Caught naming exception!
                                 javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context with the provider URL: "corbaloc:iiop:dm.uk.ibm.com:2811".  Make sure that any bootstrap address information in the URL is correct and that the target name server is running.  A bootstrap address with no port specification defaults to port 2809.  Possible causes other than an incorrect bootstrap address or unavailable name server include the network environment and workstation network configuration. [Root exception is org.omg.CORBA.TRANSIENT: java.net.ConnectException: Connection refused:host=dm.demo.ibm,port=2811  vmcid: IBM  minor code: E02  completed: No]

        at com.ibm.ws.naming.util.WsnInitCtxFactory.mapInitialReferenceFailure(WsnInitCtxFactory.java:2226)
        at com.ibm.ws.naming.util.WsnInitCtxFactory.mergeWsnNSProperties(WsnInitCtxFactory.java:1386)
                                                  

This particular problem was, in my simple world, was that the Deployment Manager node (DM) was being contacted by the WAS instance on which Connections was installed, but that the hostname / IP address was being incorrectly resolved; note that the FQ hostname differs within the error message.

Once we fixed the DNS name resolution ( by hacking the /etc/hosts file ), that particular error message went away, and was replaced by the aforementioned CLFRN1152E.