Open mrname opened 3 years ago
We are observing a similar issue, where python-clamd sends an incomplete INSTREAM
chunk at some point (in one case it was chunk no #1012). Once that happens, the chunks get misaligned, the clamd service parses the next chunk's length from the wrong bytes and all sorts of entertaining nonsense ensues.
We are also using gevent, so this is a hot candidate for causing our issue.
Regarding max_chunk_size
:
If I understand the clamd protocol correctly, then StreamMaxLength
is the maximum total length of all chunks together, not of the individual chunks. So what is the disadvantage of sending the whole buffer in a single chunk anyway, regardless of size?
@graingert - do you have any space to look at this PR? The change-set fixes what is (for us) a major and intermittent bug, and it would be great to be using master
release version, rather than a branch :)
Although a few forks have been created (https://pypi.org/project/pyClamd/, https://github.com/ranguli/clammy), they now seem unmaintained (last one was archived recently).
I've made yet another fork here: https://github.com/Viicos/clamdpy. Improvements from this PR have been included, and type hints are included. Credit goes to https://github.com/graingert/python-clamd/
A few bugfixes and improvements:
send
tosendall
. This ensures that the entire message is pushed in the socket call. In our use case, NOT usingsendall
caused an issue when usingclamd
in association withgevent
, since each socket message may or may not have pushed the full chunk, and they are working cooperatively. Aside from this use case, it also proved to be a more efficient way to send the socket messages.