We haven't found any specific bugs with lib-ssl-iostream so far, but we did find istream-multiplex bug that could cause hangs with doveadm-doveadm connections. Could be worth testing if it helps: https://github.com/dovecot/core/commit/bbe546bc637a6ac5c9e91fc8abefce62e4950...
On 30. Dec 2022, at 14.37, songliny songliny@synology.com wrote:
Hi All, We are using dovecot 2.3.19.1 We created a account with more than 1000 mail folders in Maildir format to reproduce the issue. After weeks of testing, we have found a logic that may cause dsync to encounter the error - no activity for 900 seconds.... The function, dsync_ibc_stream_input, is the callback function after some data are ready for be read. This is part of what it does. o_stream_cork(ibc->output); ibc->ibc.io_callback(ibc->ibc.io_context); o_stream_uncork(ibc->output); Normally, ibc->ibc.io_callback(ibc->ibc.io_context) reads some data and then processes it. But when dsync connects over tcps, it uses function implementations in lib-ssl-iostream to send and receive data. And this simplified call stack would result in some data are read when calling o_stream_uncork
o_stream_uncork => o_stream_flush => o_stream_ssl_flush_buffer => openssl_iostream_bio_sync => openssl_iostream_bio_input
If some data arrive after ibc->ibc.io_callback(ibc->ibc.io_context) and before o_stream_uncork, o_stream_uncork would read the data and then return. After o_stream_uncork returns, dsync then waits for new data to be read or written. But because the data had been read in o_stream_uncork, and there may be no new data to be read, dsync may then wait until timeout is met. It may happen, but it is hard to reproduce. If you also encounter this situation, you may try to use dsync over tcp connection. It does not read data when calling o_stream_uncork. As a result, it may not stuck. Back to the error itself, Maybe openssl-stream should not read data when doing uncork(flush)? Song-Lin Yang