Bug 338370

I downgraded to KDE 4.13.3, and removed,recreated the gmail account. The issue has become much less frequent. Here's some output from netstat:

With the "too many simultaneous connections, enterpassword/try again/cancel" alert still open:

> netstat -aeepW | fgrep imap
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 patux:57979             wi-in-f109.1e100.net:imaps ESTABLISHED bertin     5617520     18352/akonadi_imap_
tcp        0      0 patux:57526             wi-in-f109.1e100.net:imaps ESTABLISHED bertin     5394945     18352/akonadi_imap_
unix  3      [ ]         STREAM     CONNECTED     5392495  18352/akonadi_imap_ 
unix  3      [ ]         STREAM     CONNECTED     5392357  18352/akonadi_imap_ 
unix  3      [ ]         STREAM     CONNECTED     5392742  18352/akonadi_imap_ 
unix  3      [ ]         STREAM     CONNECTED     5392270  18352/akonadi_imap_ 
unix  3      [ ]         STREAM     CONNECTED     5392192  18352/akonadi_imap_ 

After hitting cancel, causing kmail to take the account offline:

netstat -aeepW | fgrep imap
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 patux:57526             wi-in-f109.1e100.net:imaps TIME_WAIT   root       0           -               
unix  3      [ ]         STREAM     CONNECTED     5392495  18352/akonadi_imap_ 
unix  3      [ ]         STREAM     CONNECTED     5392357  18352/akonadi_imap_ 
unix  3      [ ]         STREAM     CONNECTED     5392742  18352/akonadi_imap_ 
unix  3      [ ]         STREAM     CONNECTED     5392270  18352/akonadi_imap_ 
unix  3      [ ]         STREAM     CONNECTED     5392192  18352/akonadi_imap_ 

In other words, taking the account offline does not cause it to close all its connections to the server, something I'd expect.

Sending a SIGHUP to 18352 causes it to exit, and immediately thereafter I can online the account in kmail with success.That would appear to offer at least a suggestion for a workaround solution. The restart command in the akonadiconsole does NOT have that effect (in fact, it rarely appears to do anything with imap accounts ... unless they're working properly?!) but it'd be much more convenient NOT to have to launch a separate application to correct an issue that's apparent in kmail.

Something else: given how gmail and kmail/akonadi all support IMAP IDLE, is it still necessary to poll explicitly at regular intervals - and would NOT doing so improve things?

Googling for akonadi imap IdleRidPath gave multiple hits for multiple IDLE paths (which I guess I'd need) but also mentions a GUI for configuring those ... and I don't seem to have that. Has that feature ever been implemented and committed?

Some feedback:
I am currently testing a configuration without explicit, timed check for new mail in my gmail inbox, relying instead on the IDLE feature for being notified about incoming mail in that mailbox (since the IDLE feature cannot be deactivated anyway).

Since configuring things that way, I have had no more errors about too many simultaneous connections on that account. I do get kwallet unlock request for reading the credentials to the account from time to time (the wallet is set to close after 2min). (Personally I'd store an encrypted copy of the password in RAM to prevent that, but that's a different issue.)

Note that this is after downgrading to KDE 4.13.3, which reduced but did not eliminate the simult. connections lock-out issue.

Curiously, I also no longer get a dialog for entering the actual gmail password anew. I used to get that after the kwallet dialog had gone undetected for too long (?), as if there's a timeout on the request. I haven't had time to confirm, but it seems that this (always?) preceded the lock-out issue.
I think I still observed that behaviour in KDE 4.13.3, so after downgrading but before removing the timed poll from the gmail inbox.

Reassigning to IMAP resource which this bug report is against (the native GMail resource was not shipped in stable yet).

Note that IDLE only works on the INBOX folder: it won't update your other folders, if GMail automatically files an email there (due to filters for instance).

For performance reasons the IMAP resource keeps the connections open as long as possible, so it should not matter whether you enable/disable interval check.

> Note that IDLE only works on the INBOX folder: it won't update your other
> folders, if GMail automatically files an email there (due to filters for
> instance).

I saw work somewhere online that would add IDLE support for other folders, but it's possible that'd be at the cost of 1 connection per folder ...

> For performance reasons the IMAP resource keeps the connections open as long
> as possible, so it should not matter whether you enable/disable interval
> check.

I have a hunch that performance is more hampered by the fact that messages are downloaded systematically even when right-clicked to be deleted or when part of a multiple selection (I am not downloading offline copies) than by reconnecting to the server. Provided each reconnect isn't going to present a wallet unlock request, of course.

Would it be a thought to close the connections if the server replies with the (unambiguous) error message?

This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.