GNOME Bugzilla – Bug 659873
wastes minutes chasing after dead IMAP connections
Last modified: 2012-05-18 15:01:58 UTC
Evolution should use Network Manager's D-Bus API to realise/decide when its IMAP connections will have been severed by a change in local IP or default route when a new interface comes up (not down - as they can come back with the same IP and TCP connections intact). Otherwise when you come back from suspend/resume or just move network, it sits for ages trying to talk down the old TCP connections, rendering the UI semi-useless until you manually toggle between offline/online (complete with the "do you want to synchronise?" dialog in between) or the TCP connections time out, leaving the user frustrated and confused at why their Internet connection isn't working.
Amen.
Well we already listen for "StateChanged" signals from Network Manager and respond accordingly. Are there other parts of Network Manager's D-Bus API that we should be listening to? The problem as I see it is that libcamel still rolls its own DNS resolver and network stream APIs, parts of which are not responsive to the cancellations that Evolution sends it when the network state changes.
I believe this may be my number one use for --force-shutdown. Unless there is another reason my exits tend to hang-up on expunge operations.
*** Bug 661138 has been marked as a duplicate of this bug. ***
*** Bug 661310 has been marked as a duplicate of this bug. ***
> Well we already listen for "StateChanged" signals from Network Manager and > respond accordingly. Are there other parts of Network Manager's D-Bus API that > we should be listening to? In my personal experience this doesn't seem to work well. Evolution doesn't show me that it is "Offline" when NetworkManager clearly shows it. It also seems to try to sync folders with the server even if the NM is offline. > The problem as I see it is that libcamel still rolls its own DNS resolver and > network stream APIs, parts of which are not responsive to the cancellations > that Evolution sends it when the network state changes. It probably shouldn't do that! Is there a reason for it or does it just do that because things like GSocket haven't been in place back then?
(In reply to comment #6) > > The problem as I see it is that libcamel still rolls its own DNS resolver and > > network stream APIs, parts of which are not responsive to the cancellations > > that Evolution sends it when the network state changes. > > It probably shouldn't do that! Is there a reason for it or does it just do that > because things like GSocket haven't been in place back then? Camel's stream APIs predate GSocket by a million years or so. Looking forward to dumping it just as soon as glib-networking supports NSS certificates...
> Camel's stream APIs predate GSocket by a million years or so. Yeah, the good old days where we believed in Bonobo/CORBA and grey was the color of choice for a desktop... > Looking forward to dumping it just as soon as glib-networking supports NSS > certificates... Is there a bug about it? I found some bugs related to TLS but nothing seems to mention NSS. Maybe it should be filed for reference?
(In reply to comment #8) > Is there a bug about it? I found some bugs related to TLS but nothing seems to > mention NSS. Maybe it should be filed for reference? I'm sure Dan Winship has bugs filed already, just don't have 'em handy. Last we spoke he thought I'd have something to work with by 3.5.
I think I may have made some progress on this today, quite by accident, having stumbled upon PR_Interrupt() for secure connections and figuring out how to make it work with GCancellable. Quite simple in the end, but I'm still on the NSS/NSPR learning curve. I had a situation where Evolution was blocked in a PR_Connect() call and didn't respond to cancellation requests. It now does. DNS lookup is still an issue, but that's a different beast. My changes today will ship in Evolution-Data-Server 3.3.2.
Similar downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=759735
*** This bug has been marked as a duplicate of bug 551788 ***