Change Details

On Windows the underlying implementation of QLocalSocket behaves differently, it seems to trigger the QLocalSocket::readyRead() signal then anticipated. Prior to this patch this was not handled gracefully. BEFORE: Let's have a look at what happens on Windows inside Akonadi's Conneciton class: - Akonadi data sends Hello cmd => 91 bytes - Akonadi resource receives data - QLocalSocket::readyReady() signal fires - Triggers Connection::handleIncomingData via signal-slot connection - On Windows, QLocalSocket::bytesAvailable() is just 8 bytes - Only the first 8 bytes are read, into the `qint64 tag` variable - Protocol::deserialize(...) is called - Internally calls waitForData(...) (=> waitForReadyRead()) a few times - QLocalSocket::readyRead() signal fires again - Connection::handleIncomingData re-entered => BUG Problematic end result: ``` [10972] org.kde.pim.akonadicore: tag: -1099511627647 [10972] org.kde.pim.akonadicore: Invalid command, the world is going to end! [10972] org.kde.pim.akonadicore: State changed: QLocalSocket::ClosingState [10972] org.kde.pim.akonadicore: State changed: QLocalSocket::UnconnectedState ``` => Resource attempts reconnection to server, just to fail again afterwards. AFTER: The fix is to temporarily disconnect from the readyRead() signal while attempting to wait for data to deserialize commands. This in order to never re-enter Connection::handleIncomingData() while doing so.

On Windows the underlying implementation of QLocalSocket behaves differently, it seems to trigger the QLocalSocket::readyRead() signal earlier than anticipated (as on Linux). Prior to this patch this was not handled gracefully. Kudos to David Faure for actually figuring this out by just looking at the code and my debug output on Windows. :) BEFORE: Let's have a look at what happens on Windows inside Akonadi's Conneciton class: - Akonadi data sends Hello cmd => 91 bytes - Akonadi resource receives data - QLocalSocket::readyReady() signal fires - Triggers Connection::handleIncomingData via signal-slot connection - On Windows, QLocalSocket::bytesAvailable() is just 8 bytes - Only the first 8 bytes are read, into the `qint64 tag` variable - Protocol::deserialize(...) is called - Internally calls waitForData(...) (=> waitForReadyRead()) a few times - QLocalSocket::readyRead() signal fires again - Connection::handleIncomingData re-entered => BUG Problematic end result: ``` [10972] org.kde.pim.akonadicore: tag: -1099511627647 [10972] org.kde.pim.akonadicore: Invalid command, the world is going to end! [10972] org.kde.pim.akonadicore: State changed: QLocalSocket::ClosingState [10972] org.kde.pim.akonadicore: State changed: QLocalSocket::UnconnectedState ``` => Resource attempts reconnection to server, just to fail again afterwards. AFTER: The fix is to temporarily disconnect from the readyRead() signal while attempting to wait for data to deserialize commands. This in order to never re-enter Connection::handleIncomingData() while doing so.

On Windows the underlying implementation of QLocalSocket behaves differently, it seems to trigger the QLocalSocket::readyRead() signal then anticipatedearlier than anticipated (as on Linux). Prior to this patch this was not handled gracefully. Kudos to David Faure for actually figuring this out by just looking at the code and my debug output on Windows. Prior to this patch this was not handled gracefully.:) BEFORE: Let's have a look at what happens on Windows inside Akonadi's Conneciton class: - Akonadi data sends Hello cmd => 91 bytes - Akonadi resource receives data - QLocalSocket::readyReady() signal fires - Triggers Connection::handleIncomingData via signal-slot connection - On Windows, QLocalSocket::bytesAvailable() is just 8 bytes - Only the first 8 bytes are read, into the `qint64 tag` variable - Protocol::deserialize(...) is called - Internally calls waitForData(...) (=> waitForReadyRead()) a few times - QLocalSocket::readyRead() signal fires again - Connection::handleIncomingData re-entered => BUG Problematic end result: ``` [10972] org.kde.pim.akonadicore: tag: -1099511627647 [10972] org.kde.pim.akonadicore: Invalid command, the world is going to end! [10972] org.kde.pim.akonadicore: State changed: QLocalSocket::ClosingState [10972] org.kde.pim.akonadicore: State changed: QLocalSocket::UnconnectedState ``` => Resource attempts reconnection to server, just to fail again afterwards. AFTER: The fix is to temporarily disconnect from the readyRead() signal while attempting to wait for data to deserialize commands. This in order to never re-enter Connection::handleIncomingData() while doing so.