400 Bad request on indexing or cleaning

I'm getting this too after switching to a multicore setup

Same issue here, used 7.x-1.x-dev and solved my problem.

Had a 400 Bad Request when trying to index after I changed the node title to be indexed as string instead of fulltext. Changing back to fulltext fixed it, but this means I can't sort by title.

Same thing happened for me. Can't index as a string any more. Tomcat error:

Apr 29, 2012 6:56:14 AM org.apache.solr.update.processor.LogUpdateProcessor finish
INFO: {add=[listings_index-1774]} 0 2
Apr 29, 2012 6:56:14 AM org.apache.solr.common.SolrException log
SEVERE: org.apache.solr.common.SolrException: ERROR: [doc=listings_index-1774] multiple values encountered for non multiValued field ss_type: [basic, drealty, listing]
        at org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:246)
        at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:60)
        at org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:115)
        at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:158)
        at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:79)
        at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:58)
        at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
        at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
        at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
        at java.lang.Thread.run(Thread.java:636)

Apr 29, 2012 6:56:14 AM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/update params={wt=json} status=400 QTime=2

I set the field in question in the field UI to be a longtext field, and it indexed as a string, no more error. Don't think that would work for a title, though.

Same problem here. Reverting Title to fulltext made it go away - but that means no more sorting on title.

Had the same problem with usernames being indexed as Fulltext and thus not being able to sort by username in Views.
Changing Fulltext to String would give the "An error occurred while indexing: '400' Status: Bad Request." error.

This doesn't solve the problem, but offers a work-a-round:

In Search API > 'Your Search Index'

Under tab Workflow:
  Tick "Aggregated fields"
  Scroll down to Aggregated fields' vertical tab and add "A new field".
  Give the field a name you can recognize later ( I used 'Username (sortable)')
  Under "Aggregation type" select "Fulltext"
  Tick the fields you want to sort on (Just "Name" in my setup)
  Save the configuration

Under tab Fields:
  Change Name back to Fulltext so indexing will work again.
  Tick the Aggregated field you just created to start indexing it. ("Username (sortable)" in my setup)
  Select "String" from the select options as the Type to index the aggregated field ("Username (sortable)") as.
  Save changes

Under Status
  Re-index content

After the above steps indexing works again and I was able the sort by "Username (sortable)" in Views and Search on "Name".
This might also work for a title field.

Same issue. I widdled everything down to just one field, Node ID, and I was still unable to index. Same 400 error.
*-------- Follow Up ----------*

Sorry. My issue looks like it was unrelated to this. I was trying to point my Solr Index to a Server that was already in use. Once I pointed it at the correct core, I was fine.

@mwesthof: thanks for the advice. i tried this with the title field, but the new aggregated field is blank so it doesn't work.

(actually, i'm using the title module to make title a field, but this error happened when i tried including the new title field or the actual title.)

anyone have this working with titles?

same problem exists in 7.x-1.x-dev (7.x-1.0-rc2+14-dev, 2012-12-15) with both solr 1.4 and 3.6.0.
i couldn't get this working with an aggregated field for node titles, node title fields (title.module), or user names.

same issue here, none of the described fixes worked for me

when i go to
admin/config/search/apachesolr
i can send the remaining items to the solr server through the "Index All" button.
The Drupal logs under
admin/reports/dblog tells me
Apache Solr 22.01.2013 - 12:07 Indexing succeeded on 15 documents
-----------------------
when i go to
admin/config/search/search_api/index/node_search/status
i can NOT index the remaining items to the solr server through the "Index Now" button. The Drupal logs under
admin/reports/dblog tells me
Apache_Solr_HttpTransportException while indexing: '400' Status: Bad Request in Apache_Solr_Service->_sendRawPost() (line 364 of /mysite/libraries/SolrPhpClient/Apache/Solr/Service.php).

In this file we find:

* @throws Apache_Solr_HttpTransportException If a non 200 response status is return     ed
          */
          protected function _sendRawPost($url, $rawPost, $timeout = FALSE, $contentType = 'te     xt/xml; charset=UTF-8')
          {
                  $httpTransport = $this->getHttpTransport();
 
                 $httpResponse = $httpTransport->performPostRequest($url, $rawPost, $contentT     ype, $timeout);
                  $solrResponse = new Apache_Solr_Response($httpResponse, $this->_createDocume     nts, $this->_collapseSingleValueArrays);
 
                  if ($solrResponse->getHttpStatus() != 200)
                  {
                          throw new Apache_Solr_HttpTransportException($solrResponse);
                  }
 
                  return $solrResponse;
          }

So trying to comment out this whole function gives me a Status Code 500 Error. Same when changing !=200 to =200 or =400 or =0.
Commenting out

 if ($solrResponse->getHttpStatus() != 200)
                  {
                          throw new Apache_Solr_HttpTransportException($solrResponse);
                  }

gives back the 400 Status Error.
As i am no programmer my search for a solution ends here. Maybe someone can go further?

Related or duplicate:
#1844250: Broken Solr 1.4 compatibility results with error: The Solr server could not be reached.

If you're using Acquia Network, please follow this issue: #1751662: Couldn't index items. Check the logs for details.

Usually this error is caused by misconfiguration of Solr instance. Make sure that your Solr instance is using the right files (schema.xml, solrconfig.xml, solrcore.properties, protwords.txt) from your recent Search API Solr module.

Yeah, you are right, after updating solr to 3.6.3 this problem is gone.

Thank you, kenorb - adding solrcore.properties was key for me. I'd requested that my hosting company set up solr using the Apache Solr Integration module files. However, I then received the 400 error, so I switched to the schema.xml and solrconfig.xml files from the Search API Solr module. After the switch I was able to index at admin/config/search/apachesolr, but not at admin/config/search/search_api/index/%/status. After the addition of solrcore.properties from Search API Solr module, all works well.

It also turns out that trying to index multivalued field about which solr thinks it has a single value - may cause same error. This may happen if you added a field to the index, indexed the site and after that - allowed this same field to have multiple values. Indexing will die trying to process such entity.

To fix the problem:
1. Delete multivalued field from the list
2. re-index the site
3. Add this field back to the index
4. re-index the site again

voila, you're done.

http://drupal.org/node/1272816 - in some cases this issue is about the same thin with only difference

ERROR: [product_display_index-19] multiple values encountered for non multiValued field ss_field_product_category:tid: [461, 457, 451]

this error is returned by solr

and this one

Apache_Solr_HttpTransportException: '400' Status: Bad Request em Apache_Solr_Service->_sendRawPost() (linha 364 de /home/mercado/public_html/sites/all/libraries/SolrPhpClient/Apache/Solr/Service.php

can be seen in dblog. And the actual reason for this error was timeout of the connection (60sec) at least in my case.

Marking this as fixed, because error 400 is too general.
If you still having this, check the solutions described above, otherwise raise the new support ticket describing your problem.
Normally solr gives you the proper explanation in the logging file (or foreground) behind this error.