Repository navigation
feat: improve NVD API & datafeed downloading to acknowledge and process downloads in order of completion - #8855
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Reversed executor pool sizes misapply the configured download limit and processing concurrency cap.
1 open issue
What changed in this PR
This PR refactors NVD datafeed updates to handle downloads in completion order, avoiding waits on earlier downloads while preserving modified-feed processing last.
Changes:
- Use completion services to coordinate downloads and processing.
- Separate downloading from processor submission.
- Sort feed scheduling and mark modified-feed processors for deferred execution.
| File | Description |
|---|---|
| core/src/main/java/org/owasp/dependencycheck/data/update/NvdApiDataSource.java | Coordinates completion-order handling and processes the modified feed last. |
| core/src/main/java/org/owasp/dependencycheck/data/update/nvd/api/NvdApiProcessor.java | Adds a flag identifying processors that should be delayed. |
| core/src/main/java/org/owasp/dependencycheck/data/update/nvd/api/DownloadTask.java | Returns an unsubmitted processor after downloading. |
Review effort: Balanced
ea1f822 to
4c61e02
Compare
b600d37 to
8bca5fd
Compare
04b8beb to
3122eb3
Compare
|
@chadlwilson mind fixing the conflicts? |
Ack, will do. |
3122eb3 to
9fee7ca
Compare
|
Unfortunately, the AI slop PR at #8819 made a mess of the logic here, and did overly complex things with the I've reworked it here. |
…ownloads as they complete Currently all downloads are processed only in the submitted order. There's no reason for this because each are for a separate year. We can acknowledge them and process them as they complete using a CompletionService, rather than using static ordering of Futures. Signed-off-by: Chad Wilson <29788154+chadlwilson@users.noreply.github.com>
9fee7ca to
2b2ae52
Compare
There was a problem hiding this comment.
🟡 Changes recommended
Executor shutdown can leave writes running as the database closes, and overlapping modified and yearly downloads can cause older CVE data to overwrite newer records.
2 open issues
1 resolved since last review
Review effort: Balanced



Description of Change
Currently all datafeed downloads are processed and awaited in the submitted order; and the submitted order is based on hash, not logical order.
There's no functional reason they need to be processed in submission order because each feed other than the
modifiedone is for a separate year and subset of CVEs, and the submission order is also currently not consistent. We can acknowledge them and dispatch them for processing one-by-one as they complete using a CompletionService, rather than using static ordering of Futures.The current behaviour causes really weird stuff like sitting there waiting for slow 2002 and 2003 downloads when the 2004 downloads have already failed, which is quite frustrating when you're trying to debug a problematic proxy or very slow NVD (as is the state right now).
This change
modified, processed at the end)Related issues
N/A
Have test cases been added to cover the new functionality?
yes