dpol1 opened a new pull request, #1973: URL: https://github.com/apache/stormcrawler/pull/1973
Closes #784. On an HTTP 429 or 503 response, `FetcherBolt` parses the `Retry-After` header (delta-seconds or IMF-fixdate), caps it via the new `fetcher.max.retry.after` setting (default 24h) and emits `(key, blockUntil)` on a new `hostinfo` stream. A new `HostBlockBolt` in the urlfrontier module consumes the stream and calls `blockQueueUntil`, so the frontier stops handing out URLs for that host until the requested time. This follows the conclusion of the discussion in #1944: the fetch pipeline itself never delays or holds tuples — enforcement lives with the queue owner. It implements the host-info stream described in #867 for the rate-limit case. The header parsing and the `fetcher.max.retry.after` cap reuse the groundwork @rzo1 laid in #1944; what changes is the enforcement side. A few design decisions worth calling out for review: - The back-off key is derived with `URLPartitioner` from `partition.url.mode` (the setting the frontier keys its queues by), not from the fetcher's internal `fetcher.queue.mode` — the two can differ, and a block on the wrong key would be a silent no-op. - Only 429 and 503 are considered. `Retry-After` on a 3xx is deliberately ignored (not a host-pressure signal). - The HTTP-date form accepts IMF-fixdate only, which is what servers produce in practice; the obsolete RFC 850/asctime forms are rejected. - The gRPC call is fire-and-forget: a missed block costs one extra fetch and the next 429 re-emits the signal. - Topologies that don't wire a consumer are unaffected: tuples emitted on a stream without subscribers are simply discarded. Two scope questions before this leaves draft: 1. **Internal queue backlog.** URLs already sitting in the fetcher's internal queues for the blocked host are still fetched; the frontier block only stops new hand-outs. @jnioche suggested purging the queue in #1944 — would you want that here (re-emitting the pending items on the status stream, not as `Status.ERROR`), or as a follow-up? 2. **#867 scope.** Should this close #867 as well, or should it stay open for a future robots-delay signal on the same stream? Follow-up planned: adaptive back-off for 429/503 *without* a `Retry-After` header (the common case) plus repeated fetch exceptions, along the lines of [NUTCH-2946](https://issues.apache.org/jira/browse/NUTCH-2946) but with the state kept frontier-side — relates to #1106. I'll post the design on #867 for discussion before writing code. ### For all changes - [x] Is there a issue associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with `#XXXX` where `XXXX` is the issue number you are trying to resolve? - [x] Has your PR been rebased against the latest commit within the target branch (typically main)? - [x] Is your initial contribution a single, squashed commit? - [x] Is the code properly formatted with `mvn git-code-format:format-code -Dgcf.globPattern="**/*" -Dskip.format.code=false`? ### For code changes - [x] Have you ensured that the full suite of tests is executed via `mvn clean verify`? - [x] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? *(no new dependencies)* - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file? *(n/a)* - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file? *(n/a)* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
