From a recent post, you may need to restore your local RAD DB2 database, and it may or may not be a backup from another toolkit. When the database is restored, all the data you need is there, but Solr is still not returning the expected products.

So you open a command prompt, and cd into c:\IBM\WCDE80\bin.

Run the preprocessor for your master catalog or your catalog asset store, which we will pretend is 12345:

di-preprocess.bat C:\IBM\WCDE80\search\pre-processConfig\MC_12345\DB2

Everything works fine, and then you go to di-buildindex since that’s mainly what you wanted:

di-buildindex.bat -masterCatalogId 12345

And you end up with a terrible stack trace like so:

SEVERE: error: IOException occured when talking to server at: http://the-wrong-server:3737/solr
org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://the-wrong-server:3737/solr
	at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(
	at org.apache.solr.client.solrj.impl.HttpSolrServer.request(
	at org.apache.solr.client.solrj.impl.HttpSolrServer.request(
	at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(
Caused by: org.apache.http.conn.ConnectTimeoutException: Connect to timed out
	at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(
	at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(
	at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(
	at org.apache.http.impl.client.DefaultRequestDirector.execute(
	at org.apache.http.impl.client.AbstractHttpClient.doExecute(
	at org.apache.http.impl.client.CloseableHttpClient.execute(
	at org.apache.http.impl.client.CloseableHttpClient.execute(
	at org.apache.http.impl.client.CloseableHttpClient.execute(
	at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(
	... 7 more

Locally, you are can probably figure out the server shouldn’t be the-wrong-server:3737 but localhost:80.

To fix the server URL, you need to check the database:

select * from SRCHCONF;
select * from SRCHCONFEXT;

Both tables contain a config column. SRCHCONFEXT overrides SRCHCONF. However, if you restored a database backup from a dev or QA server, it could be pointing to the wrong Solr server for everything.

Update SRCHCONF to use the right SearchServerPort (80), SearchServerName (localhost), and PreProcessConfigDirectory (same path you use for the di-preprocess utility, in our example, C:\IBM\WCDE80\search\pre-processConfig\MC_12345\DB2)

If any other config is set, you will likely want to leave it. It will likely just be IndexScopeTag.

For SRCHCONFEXT, update config for the the catalog IDs (probably all of them) you want to run Solr for locally to:

Re-running the di-buildindex utility should now complete without throwing that exception.

This also applies for QA servers or any testing environment that is getting the IOException. The URL is likely wrong. Other possibilities are:

  • Solr is not accessible from the machine you are running di-buildindex on, either a network issue or a firewall.
  • Solr isn’t running. di-buildindex requires Solr to be started in order to work.