You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #1737 an issue related to how we retry openssl write retries was introduced.
The issue was related to the fact that retried write requests in openssl should always point to the same data with at least the same size length as the previouse blocked write attempt on the socket (see https://docs.openssl.org/master/man3/SSL_write for details)
In #1737 we correctly handled the regular case of a blocked write while writing some data stream on the socket.
However, there are cases were application will try to write "out-of-band" data on the stream which was blocked before while writing the regular data stream. For example this could happen when the primary is writing a keepalive indication to the replication stream while is was blocked with some pending data not yet sent and is still pending in the openssl lib buffers.
For this reason a debugAssert planned to be introduced as part of #1737 to cause assertion when an attempt to send data with smaller size than the pending not written data was not included in the fix (some information in this thread).
The target of this issue is to solve the existing known cases of sending out-of-band data while socket is blocked with pending unwritten data and re-introduce the debugAssert to prevent new code from falling to the same pitfall.
Example approach would be to make sure to flush all replication pending data before we start the fullsync in the replication primary flow.
The text was updated successfully, but these errors were encountered:
In #1737 an issue related to how we retry openssl write retries was introduced.
The issue was related to the fact that retried write requests in openssl should always point to the same data with at least the same size length as the previouse blocked write attempt on the socket (see https://docs.openssl.org/master/man3/SSL_write for details)
In #1737 we correctly handled the regular case of a blocked write while writing some data stream on the socket.
However, there are cases were application will try to write "out-of-band" data on the stream which was blocked before while writing the regular data stream. For example this could happen when the primary is writing a keepalive indication to the replication stream while is was blocked with some pending data not yet sent and is still pending in the openssl lib buffers.
For this reason a debugAssert planned to be introduced as part of #1737 to cause assertion when an attempt to send data with smaller size than the pending not written data was not included in the fix (some information in this thread).
The target of this issue is to solve the existing known cases of sending out-of-band data while socket is blocked with pending unwritten data and re-introduce the debugAssert to prevent new code from falling to the same pitfall.
Example approach would be to make sure to flush all replication pending data before we start the fullsync in the replication primary flow.
The text was updated successfully, but these errors were encountered: