csaf_downloader - memory leak#743
Conversation
…nloader-for-memory-leaks Limit downloader memory retention
|
@adulau Thank you for the contribution. We are currently addressing the issues around the memory leaks in other branches and PRs. We need to consolidate them first before we can merge this PR. |
|
You're welcome. It could be related but we only seen the issue on Do you think this could be merged in the next release? It's becoming a major issue for the large CSAF feeds. Thank you very much. |
Yes, we plan memory consumption improvements for the next release and actively work on it.
If you have some specific testcases for us (best in a new issues if it does not fit #718) we can consider them during the development and in testing before the release. The one from the BSI for instance? |
|
I think a good test case is the one from RedHat. It's pretty large. |
Yes, certainly is. BTW, you know that many CSAF files from Redhat are invalid (last time I've looked), https://redhat.atlassian.net/browse/SECDATA-1167 |
|
Even from the download perspective, we have many failing for RedHat: It's hard to do it right ;-) |
Quite a few larger CSAF providers will throttle someone who requests many things either too fast or in parallel. Redhat maybe one of them. ;-) |
Improve CSAF downloader resource management by limiting memory retention and closing HTTP response bodies on failed requests. Advisory data is now buffered locally for each download, preventing long-running workers from retaining the largest previously processed advisory in memory. This reduces memory pressure during large or continuous feed synchronisations and improves cleanup of network resources on error paths.