Class 'Zend_Search_Lucene_Exception' not found

The error occurs on the same placeā€¦

I donā€™t have anything customized.

Which place is that? What exactly are you doing when this occurs?

You might benefit from trying a re-index of AOD search:

Basicaly when I try to Search, create an case, an client, etc, edit something or delete something the error occurs.

Sorry but the information youā€™re providing just doesnā€™t add up inmy mind. I donā€™t see how those actions would provoke a FATAL in MassUpdate code, and much less can I relate that to the searchā€¦

You need to dig in and do your own diagnosis.

Is there anything found within the log files themselves?

Nope, anything appears thereā€¦

I can send u the crm folder and the db if you wantā€¦

Will you also send me your salary? :stuck_out_tongue:

Sorry, as much as I like a good debugging challenge, I donā€™t have time to give that level of support here on the forumsā€¦

The problem is with the application and I have to debug it?

That donā€™t make senseā€¦

Actually, that might make sense - this is an open-source project, it belongs to a community, youā€™re part of it.

And I am just a regular member of the community like you.

Anyway, please try the Reindexing (see link above). I am not convinced that this is a problem with the application, it might be a problem in your installation. Those features work fine for most people.

Hi all, hi @pgr,

thanks for helping us SuiteCRM users, this is a great project.

I am new to this community and ran into the same problem as @Fairydx. The funny part is I didnā€™t experienced this error when running SuiteCRM on a local install (based on OS X MAMP) on my own machine.

Everything ran smoothly, no Uncaught Error: Class 'Zend_Search_Lucene_Exception' not found whatsoever.

A few days ago I decided to go with a hosted service (SiteGround). After installing this, properly setting file permissions etc. I did an import of my data and then bam! I got this

Disabling AOD through the Admin panel somehow fixes the import. But then, bam! again, I get the error when editing a field and saving. Note however that the edit of the field gets saved.

Now, looking at what @Fairydx reported 22 days ago, the error is probably exactly what it sounds like ā€“ the server has more files open than the kernel is configured to handle. I guess that the fact that I am running on a shared server does not help.

I might track the error to see how/why the app tries to access this file. Iā€™ll report it if I make any porgress.

Cheers,
Guy

2 Likes

Thanks for the details.

Note that Zend can take a long time (and I mean a looooong time) to index your data, especially after large imports. Or it can also neglect to index data that is imported via the database directly. Any write operation to the index, while itā€™s busy indexing loads of stuff, might be causing some bug and corrupting the index.

So I would definitely recommend a full reindex of these systems with errors, and then leaving it many hours (overnight) to reindex successfully.

Another possible cause is file permissions. Specifically, if your cron jobs are running with different ownerships (user name) than your web server, that causes problems. If you see the index directory with strange ownerships, that explains it.

More on this issue here:

Thanks @pgr for your reply,

I waited a bit before coming back to see whether things had been fixed after I deactivated AOD as suggested in this thread (since SuiteCRM uses ElasticSearch).

The problem might indeed be the (re)indexing delay youā€™re pointing at. I still do get the error message after I have imported bulk data. But I no longer get the error when I search or edit a field (unless itā€™s a few moments after the import).

Just in case: may I later run into problems if AOD is indeed turned off?

if you turn off AOD the only thing you lose is the Advanced (Lucene) search. There are two other search methods available: Basic and ElasticSearch.

Recommended permissions are here, in the beginning:

The actual user name (www-data) may vary, it depends on your installation. You can check it in Admin / Schedulers, in the crontab instructions below the table.

If you canā€™t set permissions properly yourself, then you can try asking siteground to do it for you.

This error started to occur when I cleaned up loose data inside the database.