Bug 983964 - e-calendar-factory performs network io for caldav in the main thread
e-calendar-factory performs network io for caldav in the main thread
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: evolution-data-server (Show other bugs)
6.5
Unspecified Unspecified
unspecified Severity medium
: beta
: ---
Assigned To: Milan Crha
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-12 07:57 EDT by David Jaša
Modified: 2014-01-02 04:12 EST (History)
3 users (show)

See Also:
Fixed In Version: evolution-data-server-2.32.3-10.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-20 23:54:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed eds patch (1013 bytes, patch)
2013-07-15 11:19 EDT, Milan Crha
no flags Details | Diff
(correct) eds patch (23.57 KB, patch)
2013-07-26 14:04 EDT, Milan Crha
no flags Details | Diff

  None (edit)
Description David Jaša 2013-07-12 07:57:49 EDT
Description of problem:
e-calendar-factory performs network io for caldav in the main thread

Version-Release number of selected component (if applicable):
evolution-data-server-2.32.3-7.2.el6.x86_64 (and earlied 2.32 builds)

How reproducible:
always

Steps to Reproduce:
0. configure a caldav calendar
1.
  a) open an unread invitation in evolution mail
  b) open gnome clock applet
2.

Actual results:
email message (or clock applet details respectively) open only after e-c-f checks all the caldav calendars; e-c-f backtrace shows that IO is performed in the main thread

Expected results:
e-c-f returns reply right away to calling application
network io is handled in the separate thread

Additional info:
Comment 1 Matthew Barnes 2013-07-12 08:03:06 EDT
We've gone to great lengths to fix this sort of thing in the years since 2.32 was released.  It's not something we can easily fix in such an old version.  We're gonna have to just live with it in RHEL 6.
Comment 2 David Jaša 2013-07-12 08:10:21 EDT
Matthew,

I may have been too nice at reporting. The 2.28 didn't suffer from this problem and it causes serious usability issues all over the place - such as not responding clock applet being displayed on top of all windows for _minutes_ till the caldav timeout kicks in...

I'll attach backtraces for both cases.
Comment 5 Milan Crha 2013-07-12 08:58:53 EDT
I will try to cook something semi-hackish, and we'll see. I had a chat with David before he filled this bug report, thus it's fine I'll take care of it.
Comment 6 Milan Crha 2013-07-15 11:19:10 EDT
Created attachment 773814 [details]
proposed eds patch

for evolution-data-server;

This adds a thread pool into EDataCal, which calls (almost) each request in a separate thread, basically like the EDataBook does it. It helps in many cases, because the calendars are not opened in a serial way, but in a parallel, though it doesn't help always, like with MAPI, which is completely single-threaded currently, also between different instances. It's because the libraries used by it are not thread safe.

Here's [1] a test build of evolution-data-server-2.32.3-8.1.el6 with it included. It contains test patches for this bug, bug #979722 and bug #950005.

[1] https://brewweb.devel.redhat.com/taskinfo?taskID=6036568
Comment 7 David Jaša 2013-07-15 11:32:38 EDT
Quick question before I actually try the build - will it change CardDAV contacts as well?
Comment 8 Milan Crha 2013-07-15 13:03:23 EDT
(In reply to David Jaša from comment #7)
> Quick question before I actually try the build - will it change CardDAV
> contacts as well?

No, the change is for calendar part only. Addressbook part has this pool implemented already. Do you see the same lags in addressbook part as well? Maybe it's just the part which cannot be fixed, I'm afraid.
Comment 9 David Jaša 2013-07-24 11:30:00 EDT
I wasn't able to induce longish UI waits when trying to mimick network unavailability with iptables -j DROP, the longest was about 3-4 seconds and I couldn't repeat it. So the bug is indeed fixed.

I'm not sure about CardDAV, I reenabled autocompletion on one such calendar so let's see if it will hang the UI when typing addresses...
Comment 10 Milan Crha 2013-07-25 00:47:50 EDT
Thanks for the testing. I'll commit this by tomorrow, when you finish testing of the other bugs.
Comment 11 Milan Crha 2013-07-26 14:04:19 EDT
Created attachment 778848 [details]
(correct) eds patch

for evolution-data-server;

Oops, I attached a wrong eds patch, this is the correct one.
Comment 14 errata-xmlrpc 2013-11-20 23:54:23 EST
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.

http://rhn.redhat.com/errata/RHSA-2013-1540.html

Note You need to log in before you can comment on or make changes to this bug.