Re: [Evolution] Huge delays when creating appointments

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

On Mon, 2010-05-10 at 06:09 -0400, John A. Sullivan III wrote:
> On Mon, 2010-05-10 at 10:09 +0200, Milan Crha wrote:
> > On Fri, 2010-05-07 at 18:18 -0400, John A. Sullivan III wrote:
> > > Hello, all.  We almost have Evolution working with Zimbra after patching
> > > the webdav Contact code.  The last big problem we have is an enormous
> > > (almost a minute) delay when creating appointments.
> >
> >     Hi,
> > my last tests with Zzzimbra server is the same, evolution-data-server
> > (or in newer (2.30+) versions e-calendar-factory/e-addressbook-factory)
> > is waiting for a response from the server. It takes then so long on
> > writing for some reason only they (Zzzimbra developers) probably know.
> >
> > With respect of icons, try install/update gnome-icon-theme. What is your
> > exact version of evolution/evolution-data-server?
> >     Bye,
> >     Milan
> I think I'm getting close to understanding why we have the delay but
> need to do a little more testing this morning.  We see Evolution do the
> DAV PUT and there is an immediate create response from Zimbra.  However,
> Zimbra then waits 75 seconds before issuing a FIN to close the TCP
> session.  Only then does Evolution do a DAV GET (I assume to confirm
> creation).
>
> In the meantime, we see the Evolution client trying to issue a FIN to
> the Zimbra server but it is for a seemingly different connection
> (different ACK and SEQ numbers).  In fact, we see Evolution issue this
> FIN,ACK before it starts creating the appointment.  I do not know if it
> is related.  In the meantime, we see the Zimbra server trying to issue
> RST for these ACKs as it has no associated TCP connection (I assume).
> Since we have a firewall between the users and the Zimbra server, these
> resets are being dropped as they are not associated with any existing
> TCP connection.  I'm going to allow that traffic in a few minutes and
> see if it eliminates the delay.  I don't know where these stray FIN
> packets are coming from but they seem consistent.
>
> Regarding Evolution versions, here's what I have:
>
> evolution     2.28.3-1+b1
> evolution-common   2.28.3-1
> evolution-data-server    2.28.3.1-1.3
> evolution-data-server-common     2.28.3.1-1.3
>
> I have gnome-icon-theme 2.30.1-1.
<snip>
Now that we have the patch to get the correct URI for contacts (thank
you very, very much), we see the same behavior when creating contacts as
when creating appointments - an exactly 75 second delay.  We allowed the
RST through the firewall which has eliminated the flood of FIN packets
but has not solved the problem.

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.

We have traced the packet exchange simultaneously from both Zimbra and
Evolution.  There are no dropped packets.  We see the same thing on both
sides.  Zimbra responds with a 201 created message indicating it has
added the appointment and Evolution ACKs the packet.  Then everyone
waits.  75 seconds later, Zimbra sends a FIN packet to close the
connection.  After the connection closes, Evolution sends the DAV GET,
Zibmra responds, and all is good.

Either Zimbra is sitting around for 75 seconds doing nothing or Zimbra
has realized there has been no traffic on the TCP connection and
initiates a close after a timeout period.  I think the latter is more
likely and would indicate a bug in Evolution where it does not close the
initial session once the DAV PUT is successful.  If we could get it to
close the session, it could then continue with the DAV GET and creation
would appear to be almost instantaneous.

Can anyone who understands the code verify this hypothesis before I open
this as a bug? Thanks - John