We recently came across an interesting issue with one of our clients. Our client was trying to setup Solr 4.7.2 on WAS 8.x and was unsuccessful in starting up the Solr application. When they contacted us with the issue, the first thing we looked at was the AppServer logs.
Here’s a snippet from the AppServer logs:
[6/20/14 16:19:04:959 CDT] 00000082 CompositionUn A
WSVR0191I: Composition unit WebSphere:cuname=solr_war in BLA WebSphere:blaname=solr_war started.
[6/20/14 16:19:18:683 CDT] 0000008d webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError
SRVE0293E: [Servlet Error]-[com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor]: java.lang.NoSuchMethodError:
org/apache/http/conn/scheme/Scheme.(Ljava/lang/String;ILorg/apache/http/conn/scheme/SchemeSocketFactory;)V
at org.apache.http.impl.conn.SchemeRegistryFactory.createSystemDefault(SchemeRegistryFactory.java:83)
at org.apache.http.impl.client.SystemDefaultHttpClient.createClientConnectionManager(SystemDefaultHttpClient.java:121)
at org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:312)
at org.apache.solr.client.solrj.impl.HttpClientUtil.setMaxConnections(HttpClientUtil.java:201)
at org.apache.solr.client.solrj.impl.HttpClientConfigurer.configure(HttpClientConfigurer.java:33)
Based on prior experience with WebSphere AppServer and Solr, we were able to conclude that the issue was caused by WebSphere Application Server failing to include the the jar files available under ${solr.home} in the application’s classpath at startup.
When we looked at the WAS configuration, under JVM startup options, the properties for -Dsolr.solr.home and -Dsolr.data.dir were defined correctly and were pointing to the expected location (solr.solr.home was configured to E:/solr-home and solr.data.dir was configured to E:/solr-home/collection1/data). However, there were no errors in the startup logs indicating a problem with the solr.solr.home or solr.data.dir parameters.
Fortunately, given WebSphere Application Server’s flexibility as an enterprise class AppServer, there were other ways to define the solr.solr.home and solr.data.dir parameters. We removed the -Dsolr.solr.home and -Dsolr.data.dir values from the JVM startup options and defined these properties under $AppServer_Name -> Java and Process Management -> Java Virtual Machine -> Custom Properties. Once these custom properties were defined, we bounced the WebSphere AppServer instance and accessed the Solr console at http://AppServerhost:port/solr; this time around, the application server logs contained a new error message. Progress!
The new error message indicated that WebSphere AppServer was looking for ${solr.solr.home} under E:/IBM/WebSphere/AppServer/WAS8/E:/solr-home and ${solr.data.dir} under E:/IBM/WebSphere/AppServer/WAS8/E:/solr-home/collection1/data which was very surprising to us. We recognized that E:/IBM/WebSphere/AppServer/WAS8 was the AppServer node root directory, but had not specified it in the values of the Solr properties. From this, we determined that there was something wrong with the AppServer configuration.
In order to fix this new issue, we changed the values for solr.solr.home and solr.data.dir under $AppServer_Name -> Java and Process Management -> Java Virtual Machine -> Custom Properties to relative paths, saved the configuration, and bounced the AppServer. Once the AppServer started, we were able to access Solr admin console with no problems.