Bug 139352 - Exchange Calendar load crashes evolution
Exchange Calendar load crashes evolution
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: evolution-connector (Show other bugs)
4.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Matthew Barnes
RHEL4U3NAK
: Desktop
Depends On:
Blocks: 170416
  Show dependency treegraph
 
Reported: 2004-11-15 09:56 EST by Anonymous
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-21 12:29:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anonymous 2004-11-15 09:56:27 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020

Description of problem:
I am attempting to use an Exchange 2003 account via evolution.  The
mail portion works fine, but when I attempt to view my calendar, the
app starts downloading data and eventually stops responding altogether.
I have removed most of the meetings from my calendar at this point,
and I'm still having no luck.

Version-Release number of selected component (if applicable):
2.0.2-1

How reproducible:
Always

Steps to Reproduce:
1.  Setup an exchange account in evolution.
2.  Check exchange inbox to make sure mail portion works (type
password when prompted)
3.  click on Calendar button
4.  Check the checkbox for your exchange account

Actual Results:  At this point, evolution becomes unresponsive, and
must be killed with "killev"

Expected Results:  Exchange meetings/appointments should appear on the
evolution calendar.

Additional info:
Comment 2 Dave Malcolm 2004-11-16 11:39:51 EST
Please can you see if there is there a "cache.ics" file, located here:
~/.evolution/exchange/NAME_OF_ACCOUNT/personal/subfolders/Calendar/cache.ics

and if, so, how large is it?

If it's unreasonably large then I suspect this is a duplicate of bug
#135531  (by "unreasonably large", I'm thinking more than about 50k or
so, though this is a guesstimate).

Comment 3 Anonymous 2004-11-23 12:09:54 EST
I eventually deleted all but two or three simple meetings from my
calendar, and it started working.  I'm still having some trouble with
accepting some meeting requests taking up to several minutes, but the
crashes don't seem to be happening anymore.  I checked the size of the
cache.ics file, and it's about 30k right now.
Comment 4 Dave Malcolm 2004-11-29 18:01:28 EST
What was the content of your calendar before you purged it (as
discussed in comment #3)?  How many appointments?  What proportion of
these were recurring appointments, and which wre unique?

I've been trying to reproduce this, with an Exchange 2003 account,
creating various appointments, but I haven't succeeded so far.

In comment #3, you mention long delays when accepting meeting
requests,  Does evolution become unresponsive during these delays? 
Can you still reproduce these long delays?  If so, please can you
determine the process IDs of evolution, of evolution-data-server-1.0,
and  of evolution-exchange-storage (by typing "ps ax | grep
NAME-OF-PROCESS") and run "strace -p <PROCESS-ID>" on each and see if
that shows up what the delay is.
Comment 5 Dave Malcolm 2004-11-29 18:56:42 EST
Current status: Unable to reproduce.  I plan to spend a chunk of time
working through the source code for this tomorrow.

I believe the calendar backend is sending emails back to the organiser
of the meeting, and I've seen problems where the emails bounce (due to
me giving the wrong email address when configuring the Exchange
account within Evolution).  I've not yet established whether this
could cause the problems reported in comment #3.


Comment 6 Dave Malcolm 2004-12-02 23:29:02 EST
This is possibly related to bug #141283 (general inefficiencies in the
calendar code, not specific to the Exchange connector).  My current
thinking is that the cache file problem seen there (see comment 5 of
that bug) is not seen here, as it caches its data in a different way.

It still looks like a duplicate of this upstream bug:
http://bugzilla.ximian.com/show_bug.cgi?id=64403

If this is the case, then we have a workaround for the main part of
this bug, leaving just the slowness in accepting a meeting request as
reported in comment #3.
Comment 8 Anonymous 2005-01-11 12:58:02 EST
I apologize for not having updated this bug.  I have not seen any
issues since cleaning out my calendar.  I still need to retest with
some long meeting requests.  In response to your questions:

Before I started purging meetings, I had several (5 to 7 maybe)
long-standing recurring meetings, a couple of which had no end date. 
I also had a large number of one-time meetings (probably several
dozen), dating back to late 2001.  Even after I removed everything in
the past, there were still problems.  I did not have time to determine
which meeting was the root of the problem.

When I have had problems with accepting meetings, evolution is
entirely unreponsive during the wait for the acceptance to go through.

I'll give more detail about what problems, if any, I am still
experiencing within the next week.  Again, sorry for the delayed response.
Comment 11 Anonymous 2005-05-18 13:52:03 EDT
Several months later... we have had our ups and downs with the connector.  At
one point things were running smoothly until the Exchange guys put in an
Intrusion Protection System (which shall remain nameless).  After relaxing some
of the IPS rules, things started working okay.  Then they patched their servers
or something,  or possibly I got some unusually long calendar entries and
everything stopped working.  I ran some ethereal dumps to try to find some rhyme
or reason behind which meetings were hanging it up.  I did find that a
particularly large meeting request (one with a 44kB attachment) caused a hang,
but other simple ones did, too.  

This week, one of my coworkers decided to compile evolution-2.2.1.1 (along with
gal-2.4.1, gtkhtml-3.6.1, libsoup-2.2.3, and ximian-connector-2.2.1 as
dependencies), and it works.   It's not 100% stable, but is much more functional
than 2.0.2. 

So I decided to take a look at the difference between the actual WebDAV requests
being made between evo-2.0.2 and evo-2.2.1 ... EUREKA!  It seems that up until a
certain date, our meetings were in Exchange in one format, retrievable via HTTP
GET requests.  Afer that certain date, the format changed, and now evo-2.2.1
uses a "PROPFIND" request followed by a "SEARCH" request to retrieve entries.  I
can pass along more detailed data as necessary.
Comment 12 Dave Malcolm 2005-05-18 16:24:33 EDT
Thanks - this is great feedback.

Did the format of all meetings change at once (including the already-existing
ones?)  That suggests to me an upgrade or configuration change on the Exchange
server.
Comment 13 Anonymous 2005-05-18 19:47:07 EDT
Okay, this is getting weirder.  There was a single meeting on my calendar
generating all of the BPROPFIND/PROPFIND/SEARCH calls... 268 of them to be
exact.  After removing that meeting, all I saw were GET requests after the
initial calendar SEARCH.  I diff'ed the GETs that 2.0.2 performed before
freezing against the ones 2.2 performed, and archived the next meeting I thought
to be a problem.  After doing this, evo 2.2 actually downloaded MORE MEETINGS on
the next run!  I removed a couple more meetings on educated guesses, and now
both version download the same number of meetings.  2.0.2 just fails to display
anything.  More data coming soon...
Comment 22 RHEL Product and Program Management 2006-07-21 12:29:55 EDT
Development Management has reviewed and declined this request.  You may appeal this decision by reopening this request.

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