Re: [Evolution] IMPAX RECEIVING PROBLEMS

["Dr. John H. Lauterbach" <john lauterbachandassociates net>]

On Tue, 2018-10-30 at 08:36 +0100, Milan Crha via evolution-list wrote:

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

Thank you for your help. I have isolated problem to one IMPAX account. Said account works fine in Outlook 365, but not in Evolution. Right now, Evolution is running two IMAPX.

john