Created attachment 942922 [details] evolution backtrace Description of problem: evolution too slow Demonstration: https://drive.google.com/file/d/0B0nwzlfiB4aQWlVyaG0zd3lObFU/view?usp=sharing
Thanks for a bug report. It seems to me that Evolution lost a connection to your IMAP server (probably the Google server) for some reason. I see in one backtrace this: Error reading data from TLS socket: ..... which supports the guess. (Maybe it's a similar reason as bug #1148247.) The other backtraces show many ongoing operations, usually message download to offline, waiting to be served, which is also shown in the video (full status bar of ongoing activities). Why evolution doesn't respond to the desktop environment I do not see from the backtraces, they do not show anything UI/main-thread blocking. I also guess from the backtraces that the intermittent network outage moved the IMAPx account in a state where it left the ongoing operation waiting while it wasn't processing anything else, thus these operations are starving. I'm afraid there is no better option than to stop and run evolution again.
(In reply to Milan Crha from comment #1) > Thanks for a bug report. It seems to me that Evolution lost a connection to > your IMAP server (probably the Google server) for some reason. I see in one > backtrace this: > Error reading data from TLS socket: ..... > which supports the guess. (Maybe it's a similar reason as bug #1148247.) Different systems in #1148247 i described Fedora 21 x86_64, here Fedora 20 i686 > The other backtraces show many ongoing operations, usually message download > to offline, waiting to be served, which is also shown in the video (full > status bar of ongoing activities). Why evolution doesn't respond to the > desktop environment I do not see from the backtraces, they do not show > anything UI/main-thread blocking. Maybe UI blocking occurs in GTK layer? > I also guess from the backtraces that the intermittent network outage moved > the IMAPx account in a state where it left the ongoing operation waiting > while it wasn't processing anything else, thus these operations are > starving. I'm afraid there is no better option than to stop and run > evolution again. Too bad :(
I am reproduce this on more powerful computer Corei7 Haswell with Fedora 21 x64 Demo: https://drive.google.com/file/d/0B0nwzlfiB4aQMFVjZWZKNTA4dHM/view?usp=sharing Seems possible force update list of messages if click on list messages.
Created attachment 944105 [details] fresh backtraces
Thanks for the update. It looks like the same thing. There is an imapx_parser_thread() thread, but it is idling. More interesting would be to know what caused this state, aka what was happening before you've got here. Could it be an intermittent connection outage to a GMail server? I also noticed some GOA related warnings on the console. Both GMail and EWS accounts are configured through GOA?
(In reply to Milan Crha from comment #5) > Thanks for the update. It looks like the same thing. There is an > imapx_parser_thread() thread, but it is idling. More interesting would be to > know what caused this state, aka what was happening before you've got here. > Could it be an intermittent connection outage to a GMail server? This occurs when the evolution was not working for a long time. So at startup begins download a lot of letters. > I also noticed some GOA related warnings on the console. Both GMail and EWS > accounts are configured through GOA? Yes.
(In reply to Mikhail from comment #6) > This occurs when the evolution was not working for a long time. So at > startup begins download a lot of letters. Hmm, maybe that's it, maybe the GMail server doesn't like when there are opened too many connections and closes some of them on its own. How many concurrent connections do you have set in Edit->Preferences->Mail Accounts-><GMail Account>->Receiving Options tab? I would try to lower it, maybe down to 2 or 1. It'll make evolution move "synchronous" on requests, thus when it'll download one thing you'll not be able to see another thing until it's done, but if GMail server doesn't like the concurrent connections, then there is not much else to try.
Current value of concurrent connections is 3. But I have this issue when begin switching between mail folders and loading indicators at bottom panel became much more than 3.
Created attachment 945196 [details] Gmail Preferences
I see. The option means that "use only up to X connections to the server". If there are more operations pending then they are queue for a time when one of the connections will be free. I would try to set only one connection anyway. I think this bug [1] is about the same issue you face. I didn't see it myself yet, though. [1] https://bugzilla.gnome.org/show_bug.cgi?id=736838
*** Bug 1151187 has been marked as a duplicate of this bug. ***
(In reply to Milan Crha from comment #10) > I didn't see it myself yet, though. Actually, it happened once to me recently, but not again, I just cannot reproduce it. In case you are able to reproduce it easier than I can, could you try to grab an imapx log for the session, please? You may capture the log like this: $ CAMEL_DEBUG=imapx evolution &>log.txt but preferably disable any other IMAP accounts first, to not get mixed logging and rather do not upload it here, because it'll log all the communication between the server and the client, thus for example exposing the mails you might read. Please send it directly to me for examination (just mention the bug number/link in the message/subject). Also give me the backtrace of evolution in that state and name the folder in which the operation got stuck, thus I have something to focus on in the log. Thanks in advance. I suspect one place, but I currently do not know how to get to it. I'll investigate it regardless. I'll return back to you if I get anything.
I've made couple changes in the code for evolution-data-server 3.12.8+, beginning at [1] and ending at [2], which will address this issue. If there will be any pending operation on a dead connection, then it'll timeout within 90 seconds, instead of waiting forever. The other changes are there to better work with an offline mode, its detection, work in it and switch between online and offline as such. [1] https://git.gnome.org/browse/evolution-data-server/commit/?h=evolution-data-server-3-12&id=d5d4e2554 [2] https://git.gnome.org/browse/evolution-data-server/commit/?h=evolution-data-server-3-12&id=65d1428b7
*** Bug 1147121 has been marked as a duplicate of this bug. ***