Solr not automatically re-indexing

[namimody]

Problem

Solr indexing doesn't seem to be happening automatically When just checking there were~200 items that needed to be indexed, This should automatically happen every hour, or to anything that's new

OG ticket

Correct image sizes are uploaded on the back end for Less Stress Text: https://www.dosomething.org/node/6114/edit?build_cache_id=entityconnect-form-ZmJgDLH2xTBUxpijIgjbhzRx9gaihuQDHSE42WmB9AI&child=1

but /camapigns view shows a broken image:

Image in Header, solr search result, and homepage appear fine.

[angaither]

it's not referencing that image you linked. that's called freddie says relax and this is looking for CampaignSquare4

[namimody]

Is that because the image was changed while the campaign was live @angaither?

[angaither]

perhaps, it's probably just a solr index problem

[namimody]

happening now for Yo Teach

[namimody]

@blisteringherb do you have thoughts on this? Noticed that the Yo Teach photo is not showing up on /campaigns, and it was changed at least a couple of hours ago, so Solr should have reindexed at least once? Thanks!

[angaither]

@blisteringherb and I were looking at this on thor today.

• it seems 267 items consistently remain unindexed
• queue all, reindex, it goes down to 0, then back up to 267
• tried deleting the index, down to 0, then back to 267

[angaither]

prod is doing the same thing, though the index there remains at 269

[angaither]

it seems every time cron runs it has that number (267) of things remaining unindexed.

[mshmsh5000]

Here's what the syslog looks like on the Thor web server during cron -- and a sample of the Solr log during a cron run.

https://gist.github.com/mshmsh5000/a7b7ab69dd852254ac6b

So, Drupal is indexing things and then deleting a lot of them. I wonder if these get queued up again. The numbers don't match up (Thor deletes 112 nodes, not 267), so I don't want to go too far down the rabbit hole. But, just to look through the stuff:

SELECT * FROM node WHERE nid IN
(12, 13, 24, 34, 45, 49, 64, 69, 243, 582, 842, 1036, 1108, 1358, 1403, 1525, 1536, 1605, 2017, 2039, 2173, 2212, 2224, 2282, 2288, 2289, 2291, 2306, 2352, 2356, 2366, 2415, 2527, 2547, 2602, 2639, 2688, 2691, 2712, 2805, 2902, 2926, 2931, 2941, 3540, 3562, 3576, 3618, 3690, 3691, 3717, 3878, 3969, 4126, 4446, 4486, 4581, 4916, 4941, 4975, 4999, 5000, 5001, 5002, 5003, 5004, 5005, 5006, 5007, 5051, 5052, 5058, 5060, 5069, 5257, 5261, 5275, 5309, 5432, 5436, 5455, 5463, 5496, 5503, 5594, 5615, 5622, 5640, 5646, 5661, 5676, 5677, 5686, 5689, 5693, 5694, 5710, 5712, 5757, 5772, 5822, 5833, 5852, 6031, 6067, 6079, 6123, 6130, 6619, 6634, 6661, 6669);

Results: https://gist.github.com/mshmsh5000/3c6c6fe634a199db93f0

[blisteringherb]

Thanks for this @mshmsh5000. I think it might be this patch that I put against the apachesolr multilingual module. The reason I put it in was because unpublished translations were showing up in the finder and in search. The trick now is to figure out if Solr is just reporting the wrong number or if this patch needs to be removed and I need a different solution to the issue.

[blisteringherb]

Solr is indexing appropriately, the issue is that the number being reported as "not indexed" is actually the number of unpublished translations where the node itself is published. The patch I included removes unpublished translations from the index, but the Apachesolr module just looks at whether the node is published, not the translation publish state.

[angaither]

@blisteringherb still seeing quite a few instances of the search not updating titles correctly

for instance elephant task force was chanced to elephant tusk force on the 26th and the results still show the old title. https://www.dosomething.org/us/campaigns/elephant-tusk-force https://www.dosomething.org/us/search/apachesolr_search/elephant