Ping failure due to bad response header

117 views
Skip to first unread message

Pitaro

unread,
Jan 10, 2012, 9:50:19 PM1/10/12
to PHP Solr Client
Hello everyone,

We've been using Solr with PHP Solr Client on a LAMP server
successfully for a long time now, but just recently noticed a strange
issue with pings failing because of bad response headers, and we were
hoping someone might be able to help us?

We have our code setup to ping Solr first before executing a search
query, like this:

$solrObject = new Apache_Solr_Service($host, $port, $path);

if ($solrObject->ping()) {
... proceed with the search query ...
}

Usually the ping comes back fine, and we have no problems, but
occasionally the ping fails and our search isn't executed.
I did some debugging and found that the ping() method was failing at
this point:

//at the very least we should get a response header line of
//HTTP/1.1 200 OK
$response = fread($fp, 15);

...

//finally, check the response header line
if ($response != 'HTTP/1.1 200 OK')
{
return false;
}

The $response was not 'HTTP/1.1 200 OK', so the ping fails.
I added some debug code to show me exactly what response header was
coming back, and this is what it was:

HTTP/1.1 200
orgapachelucenequeryParserParseException_Cannot_parse_paypal_mall_flag1_AND_item_introduction_Encountered_EOF_at_line_1_column_41_Was_expecting_one_of_________________QUOTED______TERM______PREFIXTERM______WILDTERM__________________NUMBER______
Date: Wed, 11 Jan 2012 02:20:40 GMT
Server: Jetty(6.1.3)
Last-Modified: Tue, 10 Jan 2012 04:04:57 GMT
ETag: "ZDRmYjNhYTMyYzgwMDAwMFNvbHI="
Content-Type: text/xml; charset=utf-8
Connection: close

So it does have a status of 200, but where the usual "OK" should be,
there's an error message from solr.
And we're only doing a ping at this point, we haven't even gotten into
the search query yet, so this error is from something else.

My guess is that there's a bad query somewhere else in the code (in a
different part of the project) which causes the above solr error, and
whenever that error occurs, the next time we ping solr after that, we
get the error from the last bad query in the response header of our
ping.

But does anyone have any idea why a solr error would be hanging around
and show up in a ping like that? If there's a bad query and an error
is generated, shouldn't the error just be displayed once at that time,
and then be gone? Is this garbage data or some sort of cache or buffer
which hangs around until it's cleared?

I've been searching in Google and going through the code for a couple
of days now without making much process. If anyone can shed some light
on this for us it would be greatly appreciated.

Thanks in advance,
Peter

Donovan Jimenez

unread,
Jan 11, 2012, 7:11:15 PM1/11/12
to php-sol...@googlegroups.com
That's pretty weird.

This could *theoretically* happen if underneath there is connection pooling going on and you were using a connection that was already opened to the server and had been sent an incomplete request previously. However, I can't think of usage scenario where that would really happen with the solr client. My suggestion would be to put a logging http proxy between your php application and the solr server so you can log the traffic going between them, or probably simpler, use a network packet sniffer like tcpdump / wireshark / etc. See what's actually getting transmitted back and forth.

Based on your code excerpt, you're using an older version of the client. Have you tried a newer version and used any of the other transports (e.g. the curl based transport)?

Aside from that, I'd like to recommend that you can probably remove the ping call all together if you set acceptable timeouts and handle the typed exceptions specifically. Sort of a "try first, ping later" approach. With the current version, an Apache_Solr_HttpTransportException is thrown very quickly if your solr service is down completely, if its misconfigured you'll probably get a 404 / 500 coded exception, and if its just slow to respond you'll get an exception at your set request timeout. If you're maintaining a pool of servers in application, you could retire any that product transport failures and then use ping to bring them back in after a cooloff period. It all depends on your architectural preferences though.

Good luck,
Donovan
> --
> You received this message because you are subscribed to the Google Groups "PHP Solr Client" group.
> To post to this group, send email to php-sol...@googlegroups.com.
> To unsubscribe from this group, send email to php-solr-clie...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/php-solr-client?hl=en.
>
>

Pitaro

unread,
Jan 12, 2012, 12:08:43 AM1/12/12
to PHP Solr Client
Thanks for the response.

What I ended up doing to stop the errors for the immediate moment was
to fix the underlying bad query which was causing the error that was
getting stuck in the ping response header, and then I also modified
the ping() method to only look for 'HTTP/1.1 200' to verify if it's a
valid response header, and not look at any characters beyond that.

So that has resolved the problem for now, but the underlying issue of
why that error was getting stuck in the ping response header still
isn't resolved, so I'm going to take your advice and see about
upgrading to a newer version of the client, and also look into setting
up a logging solution as you suggested.

Thanks again for the insight,
Peter
Reply all
Reply to author
Forward
0 new messages