In apachesolr.index.inc, function apachesolr_cron_check_node_table() checks if there are changes to the status field between the {node} table and the {apachesolr_search_node} table
We have the apachesolr settings for the index to APACHESOLR_READ_ONLY. We are have 300-400K nodes which have had the status changed. This causes the cron job to attempt the following two calls
apachesolr_nodeapi_mass_update($nodes)
apachesolr_nodeapi_mass_delete($nodes)
Inside those functions are checks for APACHESOLR_READ_ONLY, so the index is fine. But, before entering into the functions, the cron job throws watchdog warnings with the entire node list. This causes two problems
1. the same huge warnings will appear every cron run
2. we use a php script to mail watchdog warnings to the admin, and is throwing an out-of-memory
I propose the following patch, which will still leave the cron watchdog warning, but only enter the node list, if the update/delete was successful
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 1188824-7.patch | 711 bytes | pwolanin |
| #4 | apachesolr_cron_readonly_skip_1.5.patch | 658 bytes | craig_ |
| #2 | apachesolr_cron_readonly_skip_1.5.patch | 808 bytes | craig_ |
| apachesolr_cron_warning_split_1.5.patch | 1.98 KB | craig_ |
Comments
Comment #1
pwolanin commentedThe warning is there to tell you the 2 tables don't match. In your case, you don't care. You could, I think, force the table to be rebuilt by disabling and re-enabling the module
So, seems a bit like this logic needs to be further reworked for a read-only index.
Comment #2
craig_ commentedI'm not sure what you are recommending about rebuilding the table. If the index is in read-only mode, then drupal should never need this table. It could be that I've got an unusual use case, but I don't see where apachesolr_search_node is ever used in read-only mode.
But, I agree that with my initial patch, there are unnecessary db queries and warnings, for what should just be bypassed.
Am putting in a simpler approach in this patch. It checks for the read-only setting at the start of the cron check and returns, if true.
Does that line up with the behavior you would expect?
Comment #3
pwolanin commentedYes, or perhaps that check could be moved to the point where the function is called, rather than inside it?
Comment #4
craig_ commentedthat works. i hadn't seen any other cron behavior (specifically optimization), but it makes sense to just skip back out of cron, and do no update, delete, or optimize
new patch applies to apachesolr_cron, with the check at the beginning of the function
Comment #5
pwolanin commentedComment #6
pwolanin commentedcommitted to 6.x-1.x, but might need a similar fix in 7.x
Comment #7
pwolanin commentedthis does need to be ported - maybe like this?
Comment #8
nick_vhThis patch is looking good. Only problem I see when the module will be expanding and allowing multiple indexers this will need to be changed to get a list of all the 'active' environments who don't have read only.
Since this is not the case right now I'm marking as reviewed & tested
Comment #9
pwolanin commentedcommitted