Red Hat Bugzilla – Bug 1204373
Do not use GTask for CamelSession thread jobs
Last modified: 2016-11-03 20:24:18 EDT
Created attachment 1004839 [details] updating long unused account Description of problem: I made yet another attempt to start using Evolution seriously and given that I hadn’t used Evolution I expected long synchronization time. However, when the screen shown in the screenshot below has not changed for couple of (at least two) hours, I got a bit disappointed. I wouldn’t mind that much Evolution has to do a zillion or two tasks which take some time. However, the problem was that there is apparently no priority among individual tasks (I believe each task is a separate thread, right?). So, all those synchronization tasks are not running somewhere in background with the lowest priority, but on the same level as every other one. So, the important of the screenshot is that I couldn’t read that particular message 658655 for all those two hours (and knowing Evolution is a very sensitive to other clients accessing the same IMAP server, I couldn’t get to it even with some other client on the side). So, I have decided that it must be my long period of inactivity which made the situation for Evolution too difficult to reconcile its local state with the remote IMAP servers. I have removed all email accounts and add them again. There was not much improvement (see the following screenshot). Evolution fall again to the same state of zillion running synchronizations and user-initiated actions are postponed for hours (!!!) before completion. It is not completely endless (so after an hour or so, the dialog disappears), but it is completely useless nevertheless. There is apparently not a complete hangup. When looking at top, evolution is still in some reasonable numbers of CPU activity (20~30% max) and system load is generally very low as well. Version-Release number of selected component (if applicable): evolution-ews-3.12.8-1.el7.x86_64 evolution-data-server-debuginfo-3.12.10-1.el7.x86_64 evolution-debuginfo-3.12.8-1.el7.x86_64 evolution-data-server-3.12.10-1.el7.x86_64 evolution-help-3.12.8-1.el7.noarch evolution-mapi-3.12.8-1.el7.x86_64 evolution-3.12.8-1.el7.x86_64 How reproducible: 100% (2 out of 2 attempts see above)
Created attachment 1004840 [details] updating freshly set up email accounts
I have not filled in Expected beahvior and it is a mistake. Sorry. So, what I would like to happen? I am not asking for the general speedup: first it depends on too many other factors (bandwidth and speed of the Internet connection, for example), second even the substantial speed up here wouldn't help me. Shortening of the whole process from many hours to less hours wouldn't help. What do I do ask for is introducing some kind of priorities among individual tasks. So that tasks which directly influence UI or reading of the message to be shown in the GUI should have priority over synchronizing some other folder which can happen later. (I have tried to created a backtrace of Evolution in the moment but gdb crashes on me)
Let's wait with this on an upstream bug [1], which may enhance the user experience. With that a follow-up work (or done together with it) to use one connection for probably-UI jobs would help with this. Of course, the overall outcome depends on the enabled concurrent connections. If there will be only one, then nothing will be noticed by the user. I do not know how many concurrent connects you've enabled. Check Receiving Options in the account Preferences. [1] https://bugzilla.gnome.org/show_bug.cgi?id=745545
Created attachment 1032484 [details] gdb backtrace from frozen filters I am not sure whether it is related to this bug, but it feels quite similar. When checking email (after some time using Thunderbird, so Evo had a lot of work to do), Evo got stuck with bunch of "Filtering folder [name]". Even after tens of minutes of waiting it was there, so I have captured backtrace of the moment. Does it make any sense? evolution-3.12.11-2.el7.x86_64 evolution-data-server-3.12.11-5.el7.x86_64
(In reply to Matěj Cepl from comment #5) > I am not sure whether it is related to this bug, but it feels quite similar. It is not related to this bug report, it is [1]. Please open a separate bug report for it, then I'll backport the upstream changes. There were done changes in both evolution-data-server and evolution (thus two bugs please). [1] https://bugzilla.gnome.org/show_bug.cgi?id=746276
(In reply to Milan Crha from comment #6) > changes in both evolution-data-server and evolution (thus two bugs please). bug 1226924 and bug 1226925
I would add this upstream change into the evolution-data-server: https://git.gnome.org/browse/evolution-data-server/commit/?id=b735ca9d69170c2 That will help a bit to avoid using of the GTask limitation (only 10 running threads), which can cause starving of the requests. Otherwise there are priorities in the IMAPx jobs, but there can run only one job at the moment (IMAPx has it set as such). You might want to enable concurrent connections, while the default is to use up to 3 of them.
Yes, this seems to help. Even after restarting Evolution after a long time of not using it (I use Thunderbird for my normal needs), it behaved rather reasonably. Thank you. Using evolution-debuginfo-3.12.11-22.el7.x86_64 evolution-data-server-3.12.11-36.el7.x86_64 evolution-perl-3.12.11-22.el7.x86_64 evolution-3.12.11-22.el7.x86_64 evolution-help-3.12.11-22.el7.noarch evolution-data-server-debuginfo-3.12.11-36.el7.x86_64 evolution-data-server-devel-3.12.11-36.el7.x86_64
Moving to verified based on c#12.
(In reply to Matěj Cepl from comment #12) > Yes, this seems to help. Even after restarting Evolution after a long time > of not using it (I use Thunderbird for my normal needs), it behaved rather > reasonably. Thank you. Actually, to be exact, it behaves absolutely perfect. After many many years I have started to contemplate switching to Evolution as my main MUA. Thank you!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2206.html