Nutch urlflter regex

Question

Кажется, я слишком глуп, чтобы правильно использовать исключение регулярных выражений. Я хочу отфильтровать URL-адреса домена: http://0.gravatar.com/. Мой regex-urlfilter.txt содержит следующее:

- http://0.gravatar.com (. *) - ^ http://0.gravatar.com. [a-zA-Z0-9 . \ S] + $

, но URL-адрес все еще обрабатывается, что приводит к ошибке:

java.lang.Exception: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://localhost:8983/solr/cdp: Server error writing document id http://0.gravatar.com/.. to the index
at org.apache.hadoop.mapred.LocalJobRunner$Job.runTasks(LocalJobRunner.java:491)
at org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:558)
Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://localhost:8983/solr/cdp: Server error writing document id http://0.gravatar.com/.. to the index
at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at org.apache.nutch.indexwriter.solr.SolrIndexWriter.push(SolrIndexWriter.java:247)
at org.apache.nutch.indexwriter.solr.SolrIndexWriter.commit(SolrIndexWriter.java:214)
at org.apache.nutch.indexer.IndexWriters.commit(IndexWriters.java:264)
at org.apache.nutch.indexer.IndexerOutputFormat$1.close(IndexerOutputFormat.java:54)
at org.apache.hadoop.mapred.ReduceTask$NewTrackingRecordWriter.close(ReduceTask.java:550)
at org.apache.hadoop.mapred.ReduceTask.runNewReducer(ReduceTask.java:629)
at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:389)
at org.apache.hadoop.mapred.LocalJobRunner$Job$ReduceTaskRunnable.run(LocalJobRunner.java:346)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

В качестве альтернативы: Могу ли я изменить код, чтобы ошибка была обнаружена и проанализирован URL-адрес контент просто пропускается. Или есть параметр, позволяющий просто пропустить вместо сбоя?

ОБНОВЛЕНИЕ: Спасибо за ответ, но это не изменило поведение краулера. Я поставил -^https?://0\.gravatar\.com and -^https?://1\.gravatar\.com вверху regex-urlfilter.txt. Но URL-адреса с 0.gravatar.com и 1.gravatar.com все еще извлекаются, анализируются и индексируются. И это по-прежнему приводит к тому же сообщению об ошибке выше. Может быть, эти URL-адреса уже введены и больше не проверяются url-фильтром?

Я нашел это описание проблемы: https://lucene.472066.n3.nabble.com/regex-urlfilter-test-shows-negative-but-URL-still-crawled-td4081480.html и нашел ответ относительно потраченного впустую процессора разумного. Поэтому я бы предпочел просто пропустить документ при возникновении ошибки индексации.

Answer 1

Это правило должно исключать все URL-адреса из 0.gravatar.com.

-^https?://0\.gravatar\.com

Нет необходимости сопоставлять весь URL-адрес заданным регулярным выражением. Каждая строка должна содержать одно правило. Обратите внимание, что существуют другие фильтры URL-адресов (префикс, домен), которые проще использовать для такого рода исключений.

Answer 2

Я наконец разобрался. Это была целая череда ошибок, но причиной root была нехватка места в куче для Solr. Запуск Solr с solr.cmd start -m 4g решил проблему. Я бы никогда об этом не догадался, так как уже несколько недель сканирую миллионы проиндексированных страниц. Но похоже, что индексация не удалась не по определенному URL, а на определенном этапе процесса индексации. Весь URL-квест был лишь предшественником. Как только я понял, что введенные URL-адреса больше не тестируются, и мне нужно было удалить флаг -noFilter (см. Ссылку в моем обновлении), стало ясно, что ошибка распространяется через URL-адреса и ошибка должна быть где-то еще. Что, опять же, было очень удивительно, учитывая этап моего сканирования.