On Mon, 2018-10-29 at 21:47 +0000, Patrick O'Callaghan wrote:
> I even considered filing an RFE about it, suggesting there should be
> an option to just force-close an account without waiting (I don't
> remember if I ever got round to it).
Hi,
I do not recall seeing anything like that. I suppose you didn't see it
for some time now, did you? You can force disconnect by using
File->Work offline, and once it's fully offline (the plug at the
bottom-left part, in the status bar, is unplagged and no other
operations are showing in the status bar) use File->Work Online to
reconnect all the accounts. Whether it'll have the same effect as
quitting Evolution and starting it again I do not know. More
interesting would be to know the reason for the slowness. Would there
be any memory leaks involved? Who knows.
In any case, the UI itself is not supposed to be locked, all the
network operations are ran in their own threads, not in the main/UI
thread, thus for example the window repaints when other window is moved
above it.
Many (8-10+) accounts can cause some sort of starving, caused by glib:
https://gitlab.gnome.org/GNOME/glib/issues/1223
Evolution cannot do anything with it, even it uses its own facilities
on few places to have GTask free of some operations.
To John: how many accounts are we talking about, please? I used to have
enabled 7 IMAPx accounts at once, I've only 4 currently, plus one POP,
and I do not see this issue, even in 3.26/3.28. If your UI is also
frozen (the Evolution window doesn't repaint, menu cannot be clicked,
...), then it might be a different thing. If it paints and there is no
"close" button on the send/receive popup window, then just right-click
its title bar and pick Close. Some desktop environments have the close
button hidden for some reason. As had been said in other message in
this thread, there is no need to watch the window, it can be closed,
while the update itself will continue in the background.
The idea of concurrent connections is also valid, some servers do not
like it. That's why the option is in the UI.
You can see what evolution does (where it is stuck) when you install
debuginfo packages for evolution-data-server and evolution, then get it
to that stuck state and then get the backtrace of it. You can get the
backtrace with command like this:
$ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt
Please check the bt.txt for any private information, like passwords,
email address, server addresses,... I usually search for "pass" at
least (quotes for clarity only).
I suppose the evolution/IMAPx will be waiting for a response from the
server.
You can see what all of the IMAPx accounts do, the raw communications
between Evolution and the servers, when you run Evolution from a
terminal like this:
$ CAMEL_DEBUG=imapx:io evolution
The output doesn't tell much to regular users, but you can at least see
whether there's some progress/communication being done or not. As it's
from all enabled IMAPx accounts it's easy to overlook whether all of
the accounts are doing something or not. You can use Send/Receive for
respective accounts only, if it'll make any difference.
Bye,
Milan
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
