Your facet blocks are not appearing
First make sure you have the appropriate filters enabled at admin/settings/apachesolr/enabled-filters, and the blocks positioned in their correct regions at admin/build/block.

Do you have the Active Search feature of Javascript Tools enabled? There is a possible incompatibility with the ApacheSolr module and you should test with the Active Search feature turned off.

The devel module could also prevent the facet blocks from being shown.

Issues with accents / Add UTF-8 support
Although Solr supports UTF-8 by default, Tomcat does not. You can enable the character encoding by doing the following in Tomcat's server.xml:
  • Add URIEncoding="UTF-8" to the correct Connector
  • Be sure to remove useBodyEncodingForURI from that Connector

Be sure to restart Tomcat after making these changes.

Certain searches show the message "The Apache Solr search engine is not available. Please contact your site administrator." instead of results, and/or the Drupal log contains the messages "0" Status: Communication Error or "400" Status ...

This error indicates that the requests sent from Drupal to Solr are somehow invalid. One possible reason is that the requests are too long to be handled by the Solr servlet container: Tomcat or Jetty (the latter distributed with Solr itself).

For Jetty, the solution for this case is to add a line to etc/jetty.xml 

  <Set name="headerBufferSize">65535</Set>

within the <Call name="addConnector"> section. Like so:

  <Call name="addConnector">
      <Arg>
          <New class="org.mortbay.jetty.bio.SocketConnector">
            <Set name="port"><SystemProperty name="jetty.port" default="8983"/></Set>
            <Set name="maxIdleTime">50000</Set>
            <Set name="lowResourceMaxIdleTime">1500</Set>
            <!-- Next line added to handle incoming GET requests up to 64k in length -->
            <Set name="headerBufferSize">65535</Set>
          </New>
      </Arg>
    </Call>

and then restarting Solr.

In Tomcat, it is possible to configure the maximum URL length using maxHttpHeaderSize. See: http://tomcat.apache.org/tomcat-5.5-doc/config/http.html

In Apache, use the LimitRequestLine directive. See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline

In IIS http://www.asp.net/Learn/whitepapers/aspnet4#0.2__Toc253429244

Comments

qasimzee’s picture

qasimzee commented

Awesome. You made my day

--
Qasim Zeeshan
http://qasimzeeshan.com

philwhln’s picture

philwhln commented

I'm trying to find a solution that will address this for Jetty 7

wadmiraal’s picture

wadmiraal commented

We get the "0" Status: Communication Error error message event when searching for single words. The weird part is that it is not consistent. Sometimes it works, sometimes not.

Because it's only a single word, it shouldn't be that the request is too long.

Any thoughts ?

I blog about Drupal right here

wadmiraal’s picture

wadmiraal commented

Ok, the problem is now solved. It had indeed something to do with the GET size. More here: http://drupal.org/node/1306006#comment-5103076

I blog about Drupal right here

schultetwin’s picture

schultetwin commented

I just had an issue with apachesolr that I spent two days trying to solve before I figured out the issue. Be careful when exporting apachesolr configurations via features that you don't export the apachesolr_index_last variable. If you do, and you try reindexing your content, you will only reset the apachesolr_index_last variable to whatever date is in your feature, and not to 0, so only content with a $node->updated timestamp after the timestamp in the stronarmed variable will be re-indexed.

Denis Danielyan’s picture

Denis Danielyan commented

From Stack Overflow:

<Set name="headerBufferSize">65536</Set>
is now deprecated. You can use:

<Set name="requestHeaderSize">65535</Set>
instead.

http://serverfault.com/questions/136249/how-do-we-increase-the-maximum-a...

This worked for me.

Richarda253’s picture

Richarda253 commented

Restarting tomcat solved the problem for me.
On ubuntu sudo /etc/init.d/tomcat7 restart
(I need to find out what the problem tomcat was having but the restart did resolve the message: "0" Status: Communication Error - in the Drupal log)