I am receiving an error when trying to index attachments on the Apache Solr search Default Index page. I've searched all around the forums but can't anything similar. Any help is greatly appreciated. Below is my setup:

On the "Default Index" page, it shows Remaining "4 items (50% has been sent to the server)". Under the "Configuration" section, I have "File" checked. When I click on "Index all queued content", and then click "Index all remaining", I receive the following error:

----------------------
Solr indexing has encountered an error.
Please continue to the error page

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /LLIS/batch?id=148&op=do StatusText: OK ResponseText: Fatal error: Unsupported operand types in W:\www\LLIS\sites\all\modules\apachesolr\apachesolr.index.inc on line 316

----------------------

When I click on the link for the error page, it brings me back to the "Default Index" tab with the following error message at the top:

An error occurred while processing apachesolr_index_batch_index_entities with arguments :apachesolr_index_batch_index_entities

The error only happens if I have the "File" option checked. The indexing works fine for all other content types, but as soon as I add "File" it breaks.

I also looked in the Drupal Recent Log Messages report, and it doesn't record any errors. Any help?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Nick_vh’s picture

Project: Apache Solr Search » Apache Solr Attachments
Version: 7.x-1.0-rc2 » 7.x-1.x-dev

Moving to the attachments queue.

Can you specify which modules you use and how we can reproduce the error? Perhaps some special field?

jh81’s picture

Confirmed I'm getting same error on clean D7 installation. Using Apache Solr search 7.x-1.0-rc2 and Apache Solr search attachments 7.x-1.2. As soon as I check File I get the error. Nothing special about my setup. I have a few Word and PDF file attachments uploaded.

Nick_vh’s picture

hmm

// edit:reply was too quick, thanks below for correction

Please try to investigate and come up with a possible fix? Also, update to latest dev and see if the line number is still the same. That way we can locate the bug

jh81’s picture

This error is actually happening in the Apache Solor module in the file apachesolr.index.inc on line 316. Not sure where the code is you're showing above. But for sure the error is happening on indexing file attachments. I've even created a brand new content type just to make sure there is nothing strange about my existing content type and its still not indexing the attachment. My new content type just has "Title", "Body", and "URL path settings" (default fields) and I've added a File field for the attachment. I deleted all existing content and created one node for this content type with a Word document attached.

I put a watch dog in there before the error:

  $path = entity_uri($entity_type, $entity);
  // A path is not a requirement of an entity
  if (!empty($path)) {
    $document->path = $path['path'];

     watchdog('Apache Solr', '%path document to index file path', array('%path' => $document->path), WATCHDOG_WARNING);

    $document->url = url($path['path'], $path['options'] + array('absolute' => TRUE));
  }

What I'm seeing in the error log is the nodes being index properly, "node/170 document to index file path" for example.

But for the file its showing "p document to index file path". So is it not getting the file path for the document attachment correctly? What the heck is "p"?? Shouldn't that be the full path and document to index name, something like "/files/my test doc.doc"?

Nick_vh’s picture

Status: Active » Needs work

It should be, have you figured out more? Have you tried with the latest rc of apachesolr?

jh81’s picture

I have not figured out anything else with this error other than its only happening for me on our development server (Windows 2003/IIS 6). It does not occur on my localhost (Windows 7/IIS 7) or on another clean server we have. So something in the setup on that server is probably causing this. Our security person did do PHP hardening on that development server so I'm thinking it may be related to that. We rolled back the changes he made but it did not fix the problem. Strange but for me I only have the issue on the one server. Have not tried the latest rc yet.

Pimmy’s picture

I am also getting this problem on a D7.15 with Apache Solr Search Integration 7.x-1.1.

jlk4p’s picture

For what it's worth, I am seeing this problem on a CentOS server and I'm not running this module. I'm using apachesolr (7.x-1.2) and apachesolr_file (7.x-1.x-dev 2013-Mar-19). And I don't have the issue at all on my development laptop running OSX with everything installed identically. And like jh81, if I uncheck the File types in the apachesolr interface, the problem doesn't appear at all.

@jh81: Did you ever figure out the issue on your secured dev server? My CentOS server is tightly locked by the sysadmin group and I'm wondering if I need to ask for settings to be adjusted.

jh81’s picture

@jlk4p I never figured out the issue. We're suppose to be revisiting this in a few weeks. If I discover anything, I'll reply to this thread.

aphentik’s picture

Assigned: Unassigned » aphentik

Hi,

I have the same problem but my error message is:
"Error : An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /batch?id=116&op=do StatusText: Internal Server Error ResponseText:".

Did you ever figure out the issue? I'm searching it since 2 months and some help could be very cool !

aphentik’s picture

Version: 7.x-1.x-dev » 7.x-1.3
Priority: Normal » Major
aphentik’s picture

Assigned: aphentik » Unassigned

Finally find the solution. It was a problem of file extension that solr try to index. I've exclude .zip and .vsd and it's work properly.

subhojit777’s picture

@aphentik could you please explain more on

I've exclude .zip and .vsd and it's work properly.

Where can I find this setting.

Jordanmt’s picture

I encountered the error message in #10 (followed by the error 2 in the original post) and found it to be a PHP memory error. I was able to get attachments working after increasing my limit.