Bug 139352

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).

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.

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.

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.

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.

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.

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.

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.

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...

Development Management has reviewed and declined this request.  You may appeal this decision by reopening this request.