Cron causes a fatal error if SOLR isn't running at the time

I can't reproduce that error with my installation. Scanning through ApacheSolrUpdate::update_index() I also couldn't find a source for an uncaught exception.

However, attached is a simple patch that should stop this from happening, by wrapping the whole ApacheSolrUpdate::update_index() call in a try block. If the error persists, I'm at a loss.

More info for me, for later.

What?! Monkey's already issued a patch? I didn't even have a chance to begin investigating! Nice work, D.M. I'll test this out in a bit and report back. ;-)

Well, a "patch", I just enclosed the whole thing in a try-catch, as said.

But now that you've posted the stack trace, I'm slightly (or, rather, considerably) more confused than before: If I didn't overlook something, in the whole module code (including code in the SolrPhpClient) there are only two points at which an exception with this message might be raised, in apachesolr.module at lines 82 and 182. And in both cases, the exception is caught three lines below.

Well, what do you make of such a bug? Only thing I can say is: please double-check, whether your version of apachesolr.module isn't a really old one. If it is, and it has those same two lines, with the catch statement below, I'm actually at said loss.
And also very interested in whether the bug still persists with the additional try-catch in apachesolr_update_index().

PS: Oh, overlooked the error's last line. So you are using the HEAD version, which means (besides that the two mentioned 'throw's are at the lines 82 and 239) that checking isn't necessary, unless you have manually hacked into the code, having fun with removing vital 'catch' statements. Well... Weird.

Just starting to get this set up. I can do searches from the solr search tab - but, when i run cron.php, cron bails in a couple seconds and returns to home page (only happens if apachesolr is enabled).

sound like the same issue?

That depends, is Solr up and running when that happens? I.e., do you get any warning from this module, when you enter the admin section?

solr is running fine from what i can tell.. i can do searches and i am running with the example jar in a WinXP command window so i see activity flying by as i do searches.. so pretty sure its working.

but haven't started to debug too much.. that will be todays work.

btw.. this also on Dr 5.8.

FYI - we have decided to use SOLR on our very large project - I work for the NY Times who owns ConsumerSearch.com and we are in the process of converting that site to Drupal. Needless to say we will be doing a lot of work with SOLR.

more testing to do for sure.. but in case this is of any help

jar window shows:

cron returns to home page in < 3 secs and i get msg stating "cache cleared"

Senpai: I can't recreate this (with Drupal 5 and 6): I turn off Solr, run cron, and the code never reaches line 239. Anything else you can see or tell us?

OK, just getting back to this. I have a D6.3 sandbox site with a virgin, unpatched core. All core modules are enabled. Admin_menu.module is enabled, as is cvs_deploy. I just checked out a fresh copy of the 6.x-dev version of apachesolr.module from CVS, and then enabled both the Apache SOLR Framework and the Apache SOLR Search modules.

Without SOLR running, try visiting the admin/reports/status page. You'll see the error. It's repeatable.

Applying the patch from #3 doesn't change the result, nor does it alter the error. However, if I fire up the SOLR java app and then refresh the admin/reports/status page, the error is gone. It's definitely directly related to being able to ping the java stack or not.

I'll try to do some more troubleshooting tonight and report back.

I did exactly the same, but I just can't produce this error. There is only the message in the Apache Solr row, where it should be, no fatal error of any kind. And cron runs normally, too.
It also, as I said, seems rather impossible, regarding the catch statement only three lines below the source of the excpetion.

The only reason I could in any way imagine is that you're using an older PHP version. To be honest, I don't remember about error handling in PHP versions before 5, so it could theoretically be possible that try/catch doesn't function there in the way that anyone remotely reasonable would excpect it to. Even though the parser accepts it.

If you are using PHP5, then the only explanation left is that you are using Windows too, and that Microsoft is much more imaginative when it comes to exotic bugs than anyone could have anticipated.

The only thing making sense in this issue is that my patch doesn't change a thing - if one catch doesn't work, why should two?

Yeah, if two try/catches don't work, add a third!? ;-)

My dev environment is MacBook Pro with MAMP Pro running PHP 5.2.5. I really don't know what's causing this error, and the fact that your patch didn't change anything is a good sign, I guess. I'll tell you what. It's gotta be something in my database config or something in my codebase that I've missed. I will set up a brand new sandbox site with a fresh D6.3 checkout, no additional contrib modules, and a drupal-6--1 checkout of the module.

If it works correctly, as I hope it does, I'll still have my current environment to fall back on, and in that case, I really need to figure out why the current system is broken. I can't imagine that it's a contrib module, but we'll see.

Standby...