RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1204373 - Do not use GTask for CamelSession thread jobs
Summary: Do not use GTask for CamelSession thread jobs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: evolution-data-server
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Matthew Barnes
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1295396 1297830 1313485
TreeView+ depends on / blocked
 
Reported: 2015-03-21 13:06 UTC by Matěj Cepl
Modified: 2016-11-04 00:24 UTC (History)
5 users (show)

Fixed In Version: evolution-data-server-3.12.11-25.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-04 00:24:18 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
updating long unused account (225.84 KB, image/png)
2015-03-21 13:06 UTC, Matěj Cepl 		no flags Details
updating freshly set up email accounts (264.44 KB, image/png)
2015-03-21 13:07 UTC, Matěj Cepl 		no flags Details
gdb backtrace from frozen filters (100.97 KB, text/plain)
2015-05-30 13:58 UTC, Matěj Cepl 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 745545 0 None None None Never
Red Hat Product Errata RHBA-2016:2206 0 normal SHIPPED_LIVE evolution-data-server bug fix update 2016-11-03 13:23:16 UTC

Description Matěj Cepl 2015-03-21 13:06:28 UTC 
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)
Comment 1 Matěj Cepl 2015-03-21 13:07:08 UTC 
Created attachment 1004840 [details]
updating freshly set up email accounts
Comment 3 Matěj Cepl 2015-03-21 15:23:48 UTC 
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)
Comment 4 Milan Crha 2015-03-31 06:27:52 UTC 
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
Comment 5 Matěj Cepl 2015-05-30 13:58:46 UTC 
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
Comment 6 Milan Crha 2015-06-01 10:51:16 UTC 
(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
Comment 7 Matěj Cepl 2015-06-01 12:56:18 UTC 
(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
Comment 8 Milan Crha 2015-06-02 09:59:27 UTC 
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.
Comment 12 Matěj Cepl 2016-09-06 16:55:46 UTC 
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
Comment 13 Jiri Koten 2016-09-06 17:00:36 UTC 
Moving to verified based on c#12.
Comment 14 Matěj Cepl 2016-09-08 11:10:07 UTC 
(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!
Comment 16 errata-xmlrpc 2016-11-04 00:24:18 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.