Bug 270691

Summary:	IMAP agent stops working after some time with Exchange Server
Product:	[Frameworks and Libraries] Akonadi	Reporter:	Thiago Macieira <thiago>
Component:	IMAP resource	Assignee:	Kevin Ottens <ervin>
Status:	RESOLVED WORKSFORME
Severity:	major	CC:	kdepim-bugs, vkrause, winter
Priority:	NOR
Version:	1.5.0
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Thiago Macieira 2011-04-11 16:35:03 UTC

Version: 1.5.0 (using Devel)
OS: Linux

After a while (about an hour or so), the IMAP agent connected to my Microsoft Exchange IMAP server stops synchronising. Pressing F5 on any folder from this IMAP server or using Ctrl+L or any method of synchronisation results in absolutely nothing happening. This includes using Akonadi Console (RMB > Synchronize > Synchronize All).

The only solution to getting synchronisation back is to use the Akonadi Console, right click on the agent and select Restart Agent. Sometimes, it requires restarting more than once.

This could be related to the KWallet password caching, but I have not been able to determine if this is connected to the wallet closing. I have changed my KWallet settings before to see if it made a difference and I could not make it work.

I should also point out that the Exchange Server IMAP is notorious for being broken. It disconnects the IDLE connection far too soon (simply drops the connection, with no IMAP commands) and it sometimes replies with BAD at unexpected times.

Reproducible: Sometimes

Steps to Reproduce:
1. Make sure that the agent is synchronising with Exchange
2. Wait some time (an hour or so, maybe more, maybe less, no clue what the real reason is)
3. Synchronise again (Ctrl+L, F5, Akonadi Console)

Actual Results:
*NOTHING* happens. No synchronisation is done. No IMAP traffic happens -- the agent is disconnected from the server (no TCP/IP connection established) and it doesn't try to connect.

Expected Results:
The agent should reconnect to the server and synchronise.

OS: Linux (i686) release 2.6.36.2-server-1mnb
Compiler: gcc

This account is configured for 15-minute interval checking.

Comment 1 Thiago Macieira 2011-04-11 16:35:24 UTC

Toggling online and offline does not help. The agent must be restarted.

Comment 2 Allen Winter 2011-04-11 16:38:50 UTC

adding as a showstopper

Comment 3 Thiago Macieira 2011-04-12 20:14:07 UTC

I should point out that once this starts happening, the agent *will* connect to the server, but it sends a NAMESPACE and CAPABILITY command only. It does not even try to log in.

Comment 4 Thiago Macieira 2011-04-12 20:15:28 UTC

akonadi_imap_resource_0(12784)/kdeui (Wallet) KWallet::Wallet::openWallet: Pass a valid window to KWallet::Wallet::openWallet().
akonadi_imap_resource_0(12784)/kdepimlibs (kimap) KIMAP::SessionThread::sslConnected: TLS negotiation done.
akonadi_imap_resource_0(12784)/kdepimlibs (kimap) KIMAP::LoginJob::handleResponse: Capabilities after STARTTLS:  ("IMAP4", "IMAP4rev1", "AUTH=NTLM", "AUTH=GSSAPI", "AUTH=PLAIN", "CHILDREN", "IDLE", "NAMESPACE", "LITERAL+")

Comment 5 Thiago Macieira 2011-05-16 14:06:13 UTC

The build I've just started running seems to have stopped having the problem.

If it returns, I'll let you know in this bug.

But I really think this is a showstopper that needs to be fixed.

Comment 6 Thiago Macieira 2011-05-18 10:57:28 UTC

3 days running without restarting the agent and counting.

Comment 7 Thiago Macieira 2011-05-19 18:27:03 UTC

Still counting on this machine. However, another one with the exact same build of Akonadi and KMail required the agent to be restarted twice today.

I'll restart the agent on this machine now and see if the problem returns. 

I'm proposing marking it as a blocker again, since the only way to get email flowing again is with Akonadi Console (which is a debug tool). Normal users will not know how to fix it, short of logging out and back in.

Comment 8 Thiago Macieira 2011-05-20 11:51:15 UTC

Restarting the agent did not bring the problems back.

Restarting the Akonadi server did.

Comment 9 Kevin Ottens 2011-09-17 17:05:08 UTC

Does this one still applies? I still have this issue of not being able to reproduce exchange related bugs.

Comment 10 Thiago Macieira 2011-09-17 17:22:31 UTC

I didn't have access to an Exchange server for several months. I do now. I'll pay attention during the week.

Comment 11 Thiago Macieira 2011-09-26 11:35:26 UTC

I could not reproduce the problem with Intel's Exchange 2010 server. That doesn't mean the problem is solved, since it's a different server with very different account configurations.

I should also note that unlike the Nokia installation, this one does not disconnect me all of the time due to the load-balancer losing contact with the backend.

So I recommend moving it to WORKSFORME for now.

Comment 12 Thiago Macieira 2011-12-14 10:07:56 UTC

I might be able to offer some more insight: this problem is related to authentication. It happens when the IMAP server rejects the AUTH command.

The way that IMAP on Exchange works, the IMAP front-end and the Exchange back-end might be different servers. If the two stop talking to each other for whatever reason, like a network problem, the IMAP front-end will be unable to authenticate and will reply with NO.

This happened quite often at Nokia due to the load balancing. It doesn't happen often at all at Intel, but it happened yesterday due to network outage. I didn't notice that the connection was stuck in "Connection established" state until this morning.