Bug 849227 - Message load cancel not done immediately
Message load cancel not done immediately
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: evolution-ews (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-17 14:14 EDT by Mikhail
Modified: 2012-09-03 07:53 EDT (History)
3 users (show)

See Also:
Fixed In Version: evolution-ews-3.5.91
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-03 02:36:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
backtrace evolution (35.30 KB, text/plain)
2012-08-17 14:14 EDT, Mikhail
no flags Details
backtrace evolution (36.68 KB, text/plain)
2012-08-17 14:15 EDT, Mikhail
no flags Details
backtrace evolution (39.31 KB, text/plain)
2012-08-17 14:17 EDT, Mikhail
no flags Details
htop screenshot (100.23 KB, image/png)
2012-08-28 01:47 EDT, Mikhail
no flags Details
Evolution screenshot (87.62 KB, image/png)
2012-08-28 01:50 EDT, Mikhail
no flags Details
backtrace evolution (39.48 KB, text/plain)
2012-08-28 02:25 EDT, Mikhail
no flags Details
backtrace evolution (59.84 KB, text/plain)
2012-08-28 02:28 EDT, Mikhail
no flags Details
backtrace evolution (18.80 KB, text/plain)
2012-08-28 02:29 EDT, Mikhail
no flags Details
backtrace evolution (7.07 KB, text/plain)
2012-08-29 14:55 EDT, Mikhail
no flags Details

  None (edit)
Description Mikhail 2012-08-17 14:14:19 EDT
Created attachment 605246 [details]
backtrace evolution

Description of problem:
The process of displaying messages always waiting for the completion of processes of loading messages even when it is not necessary.

Demonstration video: https://docs.google.com/open?id=0B0nwzlfiB4aQbnhpTjFwbUU4YkE
Comment 1 Mikhail 2012-08-17 14:15:05 EDT
Created attachment 605247 [details]
backtrace evolution
Comment 2 Mikhail 2012-08-17 14:17:28 EDT
Created attachment 605248 [details]
backtrace evolution
Comment 3 Milan Crha 2012-08-20 12:13:58 EDT
Thanks for a bug report. I see in the video that you have pending quite few background operations (those activities in status bar at the bottom of the window), which seem to be, based on the backtraces, operations which are downloading your remote mails locally. Is this correct, aka do you have set to synchronize remote mails locally in your EWS account/folders?

One strange thing is that the evolution tries to synchronize mails locally in multiple threads for one folder, which is obviously wrong.

Also, if I understand your request properly, is this bug report about message load into preview panel, to show messages already downloaded locally immediately, regardless current operations being pending on the folder? It is doable, evolution-mapi uses in 3.4.x, thus I suppose it can be added to evolution-ews too.
Comment 4 Mikhail 2012-08-20 15:18:11 EDT
> I understand your request properly, is this bug report about message load into
> preview panel, to show messages already downloaded locally immediately,
> regardless current operations being pending on the folder?

Yes, also on 8 sec you can see that I switched to "Deleted Items" and on 16 sec return back again to "Inbox" in both cases none effect happens with message list.
Comment 5 Milan Crha 2012-08-20 16:29:06 EDT
Hmm, the message list is stuck due to other pending operations. I committed a change for 3.5.91 in evolution-ews, which adds behaviour to show messages quickly, if they are available locally. It doesn't influence change between folders, only between messages within currently selected folder.

I'm wondering, is evolution using high CPU when you get to state of no update of message list on folder change in UI? I've a feeling it is using it, which makes the folder change break.
Comment 6 Mikhail 2012-08-28 01:46:36 EDT
New video: https://docs.google.com/open?id=0B0nwzlfiB4aQc0JueDFmaUxKcVE

Again, starting from some critical number of processes stops responding interface. Not updated preview when a transition between messages and even the list is not updated when changing messages folder. So is impossible to cancel download new emails and close evolution.

As you can see from video evolution using CPU, but Xorg process in this time uses more CPU than evolution.
Comment 7 Mikhail 2012-08-28 01:47:16 EDT
Created attachment 607408 [details]
htop screenshot
Comment 8 Mikhail 2012-08-28 01:50:52 EDT
Created attachment 607409 [details]
Evolution screenshot
Comment 9 Mikhail 2012-08-28 02:25:56 EDT
Created attachment 607412 [details]
backtrace evolution
Comment 10 Mikhail 2012-08-28 02:28:10 EDT
Created attachment 607414 [details]
backtrace evolution
Comment 11 Mikhail 2012-08-28 02:29:47 EDT
Created attachment 607415 [details]
backtrace evolution
Comment 12 Milan Crha 2012-08-28 05:42:13 EDT
Thanks for the update. I consider couple things interesting in the backtraces, namely:
- the first backtrace shows quite few threads waiting for a chance to talk
  to the exchange server, which is indicated by "stuck" activities
  in evolution's status bar; it doesn't show anything in the main thread
- the second backtrace is similar to the first, only the main thread shows
  repaint of the window - I suppose the repaint makes the Xorg processor
  usage, when it tries to draw all the spinners at the status bar
- the third backtrace has most of the pending EWS operations done, thus
  it finally got a chance to talk to the server (or it was cancelled), and
  the main thread is still redrawing the window.

I think the folder change being stuck is caused by the higher CPU usage in the main thread, especially if the folder change is delivered to the message list on idle (the CPU usage in the main thread prevents application from the idle state), but I will investigate further to verify that.

It would be good to know the reason for operations being stuck for you, though I think it's due to your slow connection to the server, as you mentioned in another of your bugs. Do you see the same if you use reliable/quick connection?
Comment 13 Mikhail 2012-08-28 05:56:37 EDT
This happens on the laptop, where I rarely run the evolution, but when I run evolution, evolution loads all messages and they are very much. And yes my connection is LTE in this case.

Why I can't cancel loading messages and to close evolution?
Comment 14 Milan Crha 2012-08-28 09:53:06 EDT
OK, I can reproduce this if I cheat evolution-ews a bit, I put a sleep() call into e_ews_connection_get_items(), thus it's like in your backtrace. Whenever I select a message to be shown in the preview panel the sleep() simulates your slow network. Once I have there "enough" pending requests in the status bar evolution starts to eat CPU, with the same backtrace as that yours, in the Xorg calls and changing folder in folder tree on the left does nothing. It seems to me that Xorg has trouble drawing widgets which are out of view for some reason.

You are right that the message load should be cancelled, I do not know why it isn't (yet), as the code did exist in evolution for cancelling message load on change in message list. Fixing that may fix the problem, or half of it, at least.

By the way, on the other machine, with better connection, is evolution-ews finally reliable for you, after all the fixes which landed in 3.4.4?
Comment 15 Milan Crha 2012-08-28 12:55:15 EDT
I'm not sure whether this will help anyhow, but could you try with the test build I just finished [1], please? It doesn't do anything special, it only changes EWS_CONNECTION_MAX_REQUESTS to 1, instead of previously used 10, thus the libsoup's queue is not full of waiting requests. I guess it should do it, but as I'm not able to reproduce it here, then I'd prefer testing on your side. Thanks in advance.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4431094
Comment 16 Milan Crha 2012-08-28 13:37:23 EDT
I asked Dan Winship for his opinion and he came up with a change for libsoup. I made a test build of it for F17 here [1], thus if you could give it a try too. I'm wondering what would be the best way to test both patches, probably if you install that one for EWS, try whether anything changed, and then (regardless if yes or no), try also the libsoup package, whether it'll be better with it. Thanks in advance.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4431173
Comment 17 Mikhail 2012-08-29 14:54:06 EDT
I am updated both evolution-ews and libsoup, but this not solve problem.

New video: https://docs.google.com/open?id=0B0nwzlfiB4aQQnkxN3VhckszX1E
Comment 18 Mikhail 2012-08-29 14:55:10 EDT
Created attachment 607979 [details]
backtrace evolution
Comment 19 Milan Crha 2012-08-30 04:46:00 EDT
Thanks for the update and testing the package. I see the packages made it better, there are not left pending operations in the status bar, but the check for new messages got stuck. There is shown in the backtrace that the debuginfo doesn't match for evolution-ews for some reason, maybe its update failed? Nonetheless, the backtrace shows that there is not passed a cancellable to inner call on connection, thus the cancel you did in Send/Receive dialog wasn't propagated down to the libsoup, which means this will wait until timeout is reached or the request is satisfied. I'll add the cancellable into this call too.
Comment 20 Milan Crha 2012-08-30 05:50:54 EDT
I built a test package [1] with patch which I committed into EWS for 3.5.91. Please try it.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4437062
Comment 21 Mikhail 2012-09-02 13:00:42 EDT
Nice work. Tried to take accumulated messages within two days with last update, evolution not hung. Tried to break receiving messages and close, evolution also closed... Good.

I'll have to try more slow connection such as GPRS.
Comment 22 Milan Crha 2012-09-03 02:36:04 EDT
Thanks for the update. I committed both changes for evolution-ews-3.5.91, which is reaching Fedora this week, +/-. I'm closing this bug report as such.
Comment 23 Mikhail 2012-09-03 02:43:49 EDT
These patches will not be in the repository Fedora 17?
Comment 24 Mikhail 2012-09-03 02:46:10 EDT
> changes EWS_CONNECTION_MAX_REQUESTS to 1, instead of previously used 10
This change do not reduce the speed of receiving messages?
Comment 25 Milan Crha 2012-09-03 07:53:30 EDT
(In reply to comment #23)
> These patches will not be in the repository Fedora 17?

Nope, it'll be only part of the test package I built for you. The upstream focuses on 3.6.0 now, which is just behind the corner. Thus these final changes will be officially part of Fedora 18+.

(In reply to comment #24)
> > changes EWS_CONNECTION_MAX_REQUESTS to 1, instead of previously used 10
> This change do not reduce the speed of receiving messages?

No, the SoupSession has its internal limit to 1 live connection anyway, thus the code change doesn't change anything from connection point of view (as far as I can tell).

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