FAST Search Server … Remember Java!

At Creative SharePoint we are working on a Line of Business project that uses the capabilities of FAST Search Server 2010 to index selected content from a custom database. The size of the project means that we have multiple development environments, all using the same custom database but using separate installations of SharePoint and FAST Server.

As part of the development process, we have a deployment guide that we have used whenever we have built a new environment. Last week we repeated this process to build a new environment for user acceptance testing.

All went well with the installation and configuration of all components of the solution until we initiated a crawl of the custom database content. Again this is a process that we have repeated many times without issue. In our new environment the process failed!

We checked the existing environments to confirm that they were all still working and then we repeated the process of the build to double check that we had done it correctly.

Still the FAST crawl failed.

The point at which it failed was when it was checking connections.

PS C:FASTSearchbingt; jdbcconnector.bat testconnections -f C:CSPJDBCCSP_FullCrawl_KPCatalogueItem.xmlbrCopyright (c) Microsoft Corporation. All rights reserved.
10:45:31,214 INFO [JDBCConnector] Starting the connector!
10:45:31,480 INFO [JDBCConnector] Checking if connections to source and target work....

Our first thought was that it was the JDBC configuration file – having to create a new set for each environment had caused issues, mostly with the encrypted password for each environment. We confirmed quite quickly that the connection to the database was being made correctly.

Next we reviewed the configuration of every service, confirming that the ports were open and accessible through firewalls, we also tested that the web services were accessible. Following confirmation of all of these settings we moved on to reviewing all of the FAST log files and comparing them to log files on the other environments that were still working.

At this point we also compared the versions of the Java SE Runtime Environment and found that we had Java 6 Update 29, 27 & 26 running on three different environmentsThe environment that was failing had update 29.

To discount this as a cause (we did not suspect this as a cause!!) we installed update 29 on an environment that had been working previously. The crawl failed!!!

We immediately removed update 29 and installed update 27 on the environment that was failing and found the issue was resolved.

To summarise the areas that we checked:

  • JDBC configuration file
  • Database connection
  • Port numbers and access to the ports
  • Java SE Runtime Environment

To download the last working version of the Java SE Runtime Environment (Java 6 Update 27) follow this link –