Bug 215550 - first file deletion takes several minutes
Summary: first file deletion takes several minutes
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution-connector
Version: 8
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-14 16:56 UTC by David L.
Modified: 2018-04-11 08:07 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-08-28 20:54:22 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David L. 2006-11-14 16:56:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061027 Fedora/1.5.0.7-8.fc6 Firefox/1.5.0.7

Description of problem:
When connected through my company's VPN, when I try to delete the first file of a session, it takes several minutes to complete the operation during which time evolution is unresponsive.  Subsequent deletes are fast.  I don't know why it's related to going through the VPN connection, but when I do the same thing from work, it works fine.  The VPN connection is quite responsive during the time that evolution is hung.  In fact, I can use a web browser evolution interface to delete a different file while evolution is hung.  This problem is not new with fc6... it happened in fc5 too.


Version-Release number of selected component (if applicable):
evolution-connector-2.8.1-1.fc6

How reproducible:
Always


Steps to Reproduce:
1.Start evoltion with an exchange account accessed through a pptp vpm connection
2.Open an exchange folder and delete a file
3.

Actual Results:
It takes several minutes to delete the first file.

Expected Results:
It should be as fast as deleting it through the web interface.

Additional info:

Comment 1 David L. 2006-11-14 17:28:05 UTC
I don't know if this is related or a different bug, but sometimes when I click
send/receive, the send/receive mail window pops up and says it is waiting on the
exchange for a really long time (forever?).  Again, this only happens through my
VPN connection and again the web interface to the exchange server is perfectly
responsive during this period.  If I cancel, the send/receive mail window, I
receive new emails but all sent emails stay in my outbox until I force-shutdown
evolution and restart it.

Comment 2 David L. 2006-11-23 00:30:34 UTC
This happens not only through VPN, but when I specify my comany's webmail page
as the "OWA URL" (eg: http://webmail.somecomany.com/exchange/).  It also seems
to happen in evolution 2.8 under Ubuntu 6.10.  It doesn't happen when I am at
work but it always happens when I remotely access my work email either through
VPN or the external webmail address.


Comment 3 Matthew Barnes 2007-10-02 18:10:25 UTC
Is this problem still present on Fedora 8 Test 2 or later?

Comment 4 David L. 2007-10-03 00:46:49 UTC
I will test with f8t3 or f8.  The problem is actually better for me right now
under f7, but I'm not sure if this is due to a change in evolution or a cleaned
up inbox.  I think the delay might scale with the number of messages in the
exchange folder.

Comment 5 Matthew Barnes 2007-10-03 12:00:14 UTC
The delay sounds like a socket timeout.

Comment 6 David L. 2007-10-06 00:11:16 UTC
(In reply to comment #3)
> Is this problem still present on Fedora 8 Test 2 or later?

I think the problem is still there in f8t3.  I just deleted two files from my
exchange inbox... the first one took about 10 seconds, the second one about 1. 
As I said in comment #4, I think the first deletion takes a time that scales
with the number of messages in the inbox.  When I reported the problem, I had ~
1 year worth of emails... now I have about 2 months worth.

Comment 7 Matthew Barnes 2007-10-06 01:49:00 UTC
Okay, thanks for the info.

Comment 8 Matthew Barnes 2008-07-10 02:57:40 UTC
Significant performance improvements were made in Fedora 9, and I believe this
should be addressed now.  Can you please confirm?

Comment 9 Matěj Cepl 2008-08-28 20:54:22 UTC
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as INSUFFICIENT_DATA.


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