search

apache / incubator-stormcrawler

A scalable, mature and versatile web crawler based on Apache Storm
https://stormcrawler.apache.org/
Apache License 2.0
887 stars 262 forks source link

Delete gone pages from index #253

Closed jnioche closed 7 years ago

jnioche commented 8 years ago

Conceptually it is not the same as an ERROR status - which occur for instance when a document is not parsable or has something wrong with it. A document could become GONE if it has had N consecutive FETCH_ERRORS or if the server returned a HTTP code 410. A GONE document could be revisited based on the scheduling but should be deleted in an index.

jnioche commented 8 years ago

An ERROR status would probably have a corresponding NEVER FETCH conventional value for the nextFetchDate (epoch 1/1/1970?) Such value would also be useful for FETCHED documents when we do not want to ever reprocess them. At the moment we just set a ridiculously large value like in 10 years time

jnioche commented 7 years ago

See SO discussion on http://stackoverflow.com/questions/42810272/tell-stormcrawler-to-delete-pages-from-es-index-after-they-have-been-deleted-on

In the meantime we could delete the ERROR status (even if most of them would not have been added to ES), the difficulty being that the indexing is done on the default stream i.e. docs which have been fetched and parsed whereas the status info gets sent to the status stream by the various bolts. We could have a bespoke bolt for deletions - it would just need the URL and nothing else: to use it we could modify AbstractStatusUpdaterBolt so that it emits the URLs to delete onto a special stream e.g. 'deletion' and connect our bespoke ES delete bolt to it. Does this make sense? Please feel free to contribute to the discussion on the link below. Thanks!

jnioche commented 7 years ago

Renamed the issue. Adding a separate status is probably not practical as the status is typically not carried through the topology. We could add a key value in the metadata to indicate when a page was successfully fetched or indexed last to delete only the ones that get ERRORed but had been fetched. As an initial step, deleting documents even though they never got fetched is not really a problem.

Having said that, we might need to track the canonical value so that we can delete the doc based on the same URL as was used while indexing. The trouble being that we could end up deleting the canonical representation of the page even though only one of the possible variations got lost. Tricky.