Solr StatusUpdaterBolt overwrites the status of a URL when it is discovered again

Đang mở
  • Có gì không ổn?
#2,304 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
backend, databases

Hướng nghiên cứu

Start with the Solr StatusUpdaterBolt and its status update path, then compare how the OpenSearch and SQL bolts handle DISCOVERED tuples for existing URLs. Reproduce the reported case with two bolt instances, including a topology restart, and check that an existing status record and its fetch metadata remain intact after the second DISCOVERED tuple.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug

The Solr StatusUpdaterBolt sends every status as a plain add, so a DISCOVERED tuple for a URL already in the status collection replaces its record. For DISCOVERED, the OpenSearch bolt uses create and the SQL one INSERT IGNORE, which keep what is there.

A test with two bolt instances, the second standing for a restarted topology, gives:

before: {"url":"https://www.url.net/missing.html","status":"FETCH_ERROR","metadata.fetch.error.count":["1"],"nextFetchDate":"2026-11-05T11:50:02Z",...}
after:  {"url":"https://www.url.net/missing.html","status":"DISCOVERED","nextFetchDate":"2026-11-05T09:50:03Z",...}

before: {"url":"https://www.url.net/denied.html","status":"ERROR","nextFetchDate":"2026-12-06T09:55:57Z",...}
after:  {"url":"https://www.url.net/denied.html","status":"DISCOVERED","nextFetchDate":"2026-11-05T09:55:58Z",...}

The test conf has no fetchInterval.error, hence the date in the ERROR record. The FETCH_ERROR test against the OpenSearch module keeps the record.

The status updater cache hides this as long as the URL is in it. After a topology restart, or once the entry has expired or been evicted, the DISCOVERED tuple reaches Solr. I first noticed this in a crawl with the Solr archetype: in a second crawl topology, the 8 outlinks of index.html were fetched again within a minute although none was due, and URLs that failed twice ended with fetch.error.count: 1.

From the code, an ERROR URL would also become due at once with fetchInterval.error: -1. For a URL denied by robots.txt the fetcher checks again, so the URL itself would get no request. The code at 3.7.0 sends the same add. I only ran this on main.

Solr's optimistic concurrency could give the same behaviour as OpenSearch: a negative _version_ means the document must not exist, and failOnVersionConflicts=false (SOLR-13320) lets the rest of a batch through. @mvolikas, would that fit the async batches of SolrConnection? I can open a PR with the test.

Separately, the bolt acks right after addAsync, before the update reaches Solr, which is why the test has to wait for the record to appear.

Ngôn ngữ chính
Java
Star
1k
Fork
297
Merge trung bình
1 ngày 11 giờ
Pull request đã merge (30 ngày)
61

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/stormcrawler

Tất cả issue của apache/stormcrawler

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.