Re: [Evolution] Huge delays when creating appointments

["John A. Sullivan III" <jsullivan opensourcedevel com>]

On Tue, 2010-05-11 at 11:21 +0200, Milan Crha wrote:
> On Mon, 2010-05-10 at 20:06 -0400, John A. Sullivan III wrote:
> > It seems like the overall process is Evolution sends a DAV PUT, Zimbra
> > replies with a redirect to a more accurate (?) URI.  Evolution does a
> > DAV PUT to this URI.  Zimbra creates the appointment.  75 second delay.
> > Evolution does a DAV GET for the appointment (I assume to verify it has
> > been created).  Evolution returns control to the user.
>
>       Hi,
> with calendar, the destination server can change the appointment, thus
> on a successful PUT response it asks for it and updates internal cache,
> with a real calendar event stored on the server.
>
> Install debug information for evolution and evolution-data-server, get
> to the state of "waiting 75 seconds on Zzzimbra server", and get the
> backtrace of evolution-data-server
> (e-calendar-factory/e-addressbook-factory) process, to see that one of
> running threads is waiting for a response from the server, on the new
> URL, as returned by the server in the redirection response.
>
> I agree that there can be some misunderstanding of a redirection
> response on the PUT request, so yes, we can try to find out what is
> going wrong here, and why is Zzzimbra returning a redirection when
> nothing like that would be needed.
>       Bye,
<snip>
The redirection on the PUT request doesn't seem to be a problem.  The
PUTs work perfectly well other than closing the last PUT.  Perhaps that
is what you mean.  I'll send you the packet capture off list (as it
contains real email addresses).

As mentioned, I'm not a developer at all.  How exactly would I do the
backtrace.  I am only roughly familiar with running gdb.  Do I somehow
attach it to a running process? How does it find the code for debugging
(or is that what the debugging symbols provide)? If you would kindly
provide a step by step, I'll gladly do it.  Thanks - John