Qt network being unreliable establishing a connection
Bug #1413269 reported by
Thomas Strehl
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical System Image |
Fix Released
|
High
|
Unassigned | ||
qtbase-opensource-src (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
qtbase-opensource-src (Ubuntu RTM) |
New
|
Undecided
|
Unassigned |
Bug Description
Qt network manager is unreliable as it sometimes reports the device being not online when in fact it is. This manifest in bugs like bug #1409995 or some scopes querying online resources just being empty.
description: | updated |
description: | updated |
description: | updated |
Changed in canonical-devices-system-image: | |
milestone: | none → ww05-2015 |
status: | New → Confirmed |
Changed in canonical-devices-system-image: | |
status: | In Progress → Fix Committed |
Changed in canonical-devices-system-image: | |
status: | Fix Committed → Confirmed |
Changed in canonical-devices-system-image: | |
status: | Confirmed → Fix Released |
To post a comment you must log in.
Bug #1409995 affected our smartscopesproxy service, which starts with user session (keeps running in the background) and handles network requests by creating QNetworkAccessM anager instance with every new request. So, in theory, since QNAM was re-created for every request, it should not be affected by temporary network issue and should recover with another request, assuming network becomes available. What we observed however was a permanent failure: if the problem occurred after reboot, no network requests were passing through anymore. QNetworkAccessM anager / QNetworkReply signals wouldn't report any progress or error and were just stuck.
While reproducing that bug (which wasn't hard - it would happen every 2-3 reboots of the phone) I found out that it couldn't be reproduced if I just killed smartscopesproxy process and let upstart respawn it - I tried killing it around 20 times in a row, and every time it was serving network request correctly. That suggests the problem may have something to do with startup sequence.