Commit 9acda8e4 authored by Luca Beltrame's avatar Luca Beltrame
Browse files

Increase timeout for reading data from resources to 30 seconds

The introduction of LZMA compression for payloads can mean that when
handling already-compressed attachments, especially those in large
sizes, the default timeout of 10 seconds can be exceeded. This is
particularly evident for machines with rotational disks or full disk

This has particularly bad effects on item syncing:

1. The resource retrieves an item, and starts compressing the payload.
2. The compression takes more than 10 seconds, so the resource is
   disconnected from Akonadi due to the timeout.
3. Upon reconnection, there is an attempt to rollback the change, but
   the change did not actually take place, so a bunch of errors
   regarding transactions are logged.
4. The database for that resource and that collection is left in an
   inconsistent state.
5. This can cause the resource to ultimately get stuck on its jobs.

Fixing the actual problem is probably far more convoluted, but a quick
workaround would be to increase the timeout up to 30 seconds, to stay on
the safe side.

This change was tested on a laptop with FDE that could not sync
attachments larger than 5M: after the change, the syncing was performed
parent e52957ae
Pipeline #37789 failed with stage
in 60 minutes and 6 seconds
......@@ -484,7 +484,7 @@ void Connection::sendResponse(qint64 tag, const Protocol::CommandPtr &response)
Protocol::CommandPtr Connection::readCommand()
while (m_socket->bytesAvailable() < static_cast<int>(sizeof(qint64))) {
Protocol::DataStream::waitForData(m_socket.get(), 10000); // 10 seconds, just in case client is busy
Protocol::DataStream::waitForData(m_socket.get(), 30000); // 30 seconds, just in case client is busy
Protocol::DataStream stream(m_socket.get());
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment