I have had a look through some of the previous issues and can only see this issue for Drupal 6. I have had a look through the comments and have not been able to fix this issue.

When I tell ApacheSolr to index my site it fails right at the end of the batch process with the following

XXXX items successfully processed. An error occurred while processing apachesolr_batch_index_nodes with arguments :apachesolr_batch_index_nodes

The weird thing is that it says I have over 50,000 items in the index but also says that only a small percentage of the site has been indexed. The total of the two numbers add up to way more content than I have.

Can anyone help me so I can work out where the issue is with the indexing not working.

I did recently update to version 7 and it had been working prior. I have deleted the whole index and made sure that my schema and config files are up-to-date.

CommentFileSizeAuthor
#10 1174960-10.patch2.41 KBpwolanin
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

akoepke’s picture

Just deleted the index and told it to reindex.

69950 items successfully processed. An error occurred while processing apachesolr_batch_index_nodes with arguments :apachesolr_batch_index_nodes
The search index is generated by running cron. 23% of the site content has been sent to the server. There are 53925 items left to send.

Settings for: localhost server

Using schema.xml version: drupal-3.0-beta7
The server has a 2 min delay before updates are processed.

Number of documents in index: 53650 (2000 sent but not yet processed)
akoepke’s picture

Title: Indexing not working on Drupal 7 » Indexing not working on Drupal 7 after upgrade

Just providing a further update. I reverted back to Beta 6 (which comes with a Beta 4 schema) and the indexing did complete.

It still came up with the error but in this case it did still index the content. After the initial run there were only 213 articles not in the index and re-running the index queued content process resolved those.

Some change between Beta 6 and Beta 7 caused this to stop working.

jpmckinney’s picture

Status: Active » Fixed

Did you run update.php? That's likely the problem.

vabue’s picture

Status: Fixed » Active

Same problem, beta7.

Running update.php don't help.

jpmckinney’s picture

@akoepke: does running update.php not help you either?

akoepke’s picture

The update did run and did not help with this problem. The first time I did the upgrade I did it via the D7 module upgrade system and did run the database updates afterwards.

The second time I tried it I did the upgrade via drush (made it easier to revert back) which automatically applies the database updates.

jpmckinney’s picture

The message in the OP appears on the admin page. Are there no other messages in the watchdog logs? Common errors during indexing are caught and logged there.

pwolanin’s picture

Version: 7.x-1.0-beta7 » 7.x-1.x-dev

Where in the code is that error message generated?

It could be a SQL query that's very slow and fails.

jpmckinney’s picture

"An error occurred while processing apachesolr_batch_index_nodes with arguments" is in apachesolr_batch_index_finished.

pwolanin’s picture

Status: Active » Needs review
FileSize
2.41 KB

Ugh, this was annoying. So we added back the use of apachesolr_cron_check_node_table() on cron last release. Seems there was an unnoticed bug in that DBTNG ->condition() CANNOT be used to compare 2 columns, only a column and a value.

To compare 2 columns, looks like you have to use ->where()

So, the real fix is one line:

--- a/apachesolr.index.inc
+++ b/apachesolr.index.inc
@@ -332,25 +332,15 @@ function apachesolr_cron_check_node_table() {
   // Check for unpublished content that wasn't deleted from the index.
   $query = db_select('apachesolr_search_node', 'asn')
     ->fields('n', array('nid', 'status'))
-    ->condition('asn.status', 'n.status', '<>');
+    ->where('asn.status <> n.status');
   $query->innerJoin('node', 'n', 'n.nid = asn.nid');

but this patch also has some cleanup to get rid of silly code that can be replaced by appropriate use of array_chunk().

pwolanin’s picture

Priority: Normal » Critical
pwolanin’s picture

Category: support » bug
Anonymous’s picture

subscribe, review shortly.

Anonymous’s picture

Status: Needs review » Reviewed & tested by the community

this looks RTBC to me.

code cleanup is nice, and i can confirm this patch fixes the indexing bug.

pwolanin’s picture

Status: Reviewed & tested by the community » Fixed

committed. Thanks @justinrandell

exeapps’s picture

Excellent.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.