Timeout error after save (Lucene)

[jaronkk]

After a seemingly random number of times saving a tutorial, our installation of Guide on the Side will start throwing timeout errors every time a tutorial is saved. The only way to resolve while leaving Lucene enabled has been to clear out the Lucene index, but that was only a temporary fix.

For now we've just disabled the Lucene code in the Tutorial's afterSave function. I looked a little bit, but didn't see an obvious place where the Lucene index as actually being used by Guide on the Side.

I also saw there's an active branch fixing something related to Lucene - https://github.com/ualibraries/Guide-on-the-Side/tree/569_lucene_bug and was wondering if that's at all related.

Log:

2015-01-12 10:04:50 Error: Fatal Error (1): Maximum execution time of 30 seconds exceeded in [app/Vendor/Zend/Search/Lucene/Index/SegmentWriter.php, line 618]
2015-01-12 10:04:50 Error: [InternalErrorException] Internal Server Error
Request URL: /guide-on-the-side/tutorials/edit_content/17
Stack Trace:
#0 lib/Cake/Error/ErrorHandler.php(203): ErrorHandler::handleFatalError(1, 'Maximum executi...', '/shared/website...', 618)
#1 [internal function]: ErrorHandler::handleError(1, 'Maximum executi...', '/shared/website...', 618, Array)
#2 lib/Cake/Core/App.php(929): call_user_func('ErrorHandler::h...', 1, 'Maximum executi...', '/shared/website...', 618, Array)
#3 lib/Cake/Core/App.php(902): App::_checkFatalError()
#4 [internal function]: App::shutdown()
#5 {main}

[simpsonw]

@jaronkk
That branch is related to a bug that was causing search results to either be duplicated or not show up at all. I have not encountered the issue you described, but it's possible the two things might be related. Am I correct in understanding that the issue presents itself after repeatedly saving the same tutorial over and over?

[simpsonw]

@jaronkk
Regarding your comment about where GotS uses Lucene, right now it's primarily being used in the UA Library theme, which is not part of the open source release. The bug I mentioned in the above comment is on our internal issue tracker, so you won't see it mentioned on Github. If we can get Lucene to work more reliably with GotS, we may look into making it a more prominent part of the open source release.

[jaronkk]

@simpsonw The issue presents itself when saving in general. I was able to recreate it by saving one tutorial after another, and also by saving the same tutorial over and over. Since we don't have a use case for using Lucene in our environment, I can't really justify spending time debugging the problem.

What if Lucene could be enabled/disabled via a configuration option? Something like this:

lucene:
  enabled: false

Since it's currently not used in the open source release, my preference would be to have it default to false.

If that seems like the right direction, I could go ahead and make a pull request with the change.

[simpsonw]

@jaronkk I think that's an interesting idea that's worth looking into. I think it should be fairly straighforward to implement, but I will have to take a look at the code. Out of curiosity, could you tell me which branch you have checked out that's having the problem?

[jaronkk]

We first encountered the problem when we set up a test instance of GotS using the 1.0-beta2 release. At that time we didn't spend time diagnosing the problem since we just had one librarian using it, and her changes still saved.

We just recently set up a production GotS instance. I have a hesburgh-master branch that is based on the latest ualibraries master. The plan is to periodically rebase off of the ualibraries master, so we only have a small number of commits that differ from the master branch.

I don't think the problem is related to GotS specifically. I found some comments on the Zend_Search_Lucene documentation page that indicate other people encounter this problem: "I don't know why i get this error if i only have one document". I'm also unable to reproduce it locally on my MacBook Pro - it only manifests on our web servers which are RHEL6 virtual machines.

[simpsonw]

@jaronkk, that's really puzzling. Given the difficulty to reproduce and the fact that, as you mention, the issue may be Lucene-realted, I think your idea of adding a configuration option might be the best way to go. The simplest way might be to just check the value of that option in the afterSave callback for the Tutorials model and only execute the Lucene index code (around line 504) if it's true.

If you have time to put that into a pull request, that would be great! Otherwise I can add it to the todo list here.

[jaronkk]

@simpsonw I haven't made the pull request, but here's the comparison: https://github.com/ndlib/Guide-on-the-Side/compare/ualibraries:master...ndlib:lucene-configuration

I think it might be easiest if you incorporated the change into your 569_lucene_bug branch since you're working with these files and there's no hurry from my end.

config.sample.yml:

• Added lucene.enabled config option

Tutorial.php:

• Moved lucene code into a new updateSearchIndex function (for readability). afterSave calls this function.
• Added a check inside updateSearchIndex to see if lucene.enabled is true.

[simpsonw]

@jaronkk The changes look good to me and I think this would be a useful option. The only problem is that since you didn't have the 569_lucene_bug_branch checked out when you made the changes, it makes the merge and diff kind of ugly since there are some changes to the afterSave function in Tutorial.php in that branch (I tried it locally).

Would you mind rebasing off of the 569_lucene_bug branch? Or perhaps I could just manually add the changes to that branch if you don't mind?

[simpsonw]

@jaronkk, did the configuration option from #102 fix the issue for you? I ask because I'm wondering if this task should still be open.

[michaelhagedon]

I'm going to assume yes, and we can reopen if @jaronkk reports otherwise.