Wednesday, 18 November 2009
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: -
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]
[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)
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.
# posted by Dave Hay : 21:00
Subscribe to Posts [Atom]
