"No messages found" error with courier imap

[rcubetrac]

Reported by maharaja on 27 May 2010 14:25 UTC as Trac ticket #1486761

there is a timeout issue when accessing a imap mailbox on a courier server.

what i noticed is:

rc 0.3 did 1 call to
/?_task=mail&_action=getunread&remote=1&=1273935378028&_unlock=0

rc 0.4 does 2 calls:
/?_task=mail&_action=list&_mbox=INBOX&_refresh=1&remote=1&=1273934080494&_unlock=1
/?_task=mail&_action=getunread&remote=1&=1273934080502&_unlock=0

(see rc-error.png)

another thing i noticed is that this error is more likely to occur when
both scripts run for several seconds. (rc-error2.png)

is there any way to test this two requests in a serial fashion?

thanks,
raoul
references:
thread start: http://lists.roundcube.net/mail-archive/dev/2010-04/0000107.html

http://lists.roundcube.net/mail-archive/dev/2010-05/0000011.html

Migrated-From: http://trac.roundcube.net/ticket/1486761

[rcubetrac]

Owner changed by maharaja on 27 May 2010 14:26 UTC

=> none

[rcubetrac]

Comment by @alecpl on 28 May 2010 06:09 UTC

I don't think we'll change this. Did you try to increase MAXDAEMONS and MAXPERIP settings in Courier config?

[rcubetrac]

Comment by maharaja on 28 May 2010 09:53 UTC

my setting already is reasonably high and i encounter no issues with multiple computers, each running multiple thunderbird accounts.

MAXDAEMONS=200
MAXPERIP=150

mysql as a backend allows 1000 concurrent connections. there currently are around 100 in use, so this shouldn't be an issue either.

there is no information regarding any maxdeamon hit.

of course, roundcube does not use persistent connections as thunderbird.
-> i will increase the MAX settings and will retry anyways.
-> maybe i will also take a look at imapproxy/nginx.

[rcubetrac]

Comment by @alecpl on 28 May 2010 09:58 UTC

How many active sessions have you got in Roundcube? Keep in mind that all Roundcube instances are using one IP. Imapproxy is a good solution.

[rcubetrac]

Comment by maharaja on 28 May 2010 13:38 UTC

not too many concurrent connetions and, as stated above, MAXPERIP=150.

there is nothing in the logfiles.

moreover, rc0.3 works flawlessly on the same machine.

[rcubetrac]

Comment by @alecpl on 28 May 2010 14:01 UTC

What if you increase the new imap_timeout option? Now I see, one request tooks more than 10 seconds, so it times out. For me the issue doesn't looks like concurrent sessions limit, but SLOW concurrent sessions. How long is running list request when you click on INBOX?

[rcubetrac]

Comment by maharaja on 28 May 2010 14:55 UTC

first of all, it seems to work when increasing the timeout. i have to test a little more though before i can say if the new option fixes this issue.

what i did:

1. set $rcmail_config['imap_timeout'] = 2500;
2. empty all caches on the mailserver: "sync; echo 3 > /proc/sys/vm/drop_caches"
3. open roundcube

refreshing the inbox takes 37.68 seconds but works. see rc-imap-timeout-2500s.png

thanks,
raoul

[rcubetrac]

Comment by maharaja on 28 May 2010 15:10 UTC

mhm - i did not test with a fresh export and therefore had a couple of leftovers from my patch, which would set imap_timeout to a default value of 10.

so it definitely seems to be a slow imap server.

but using the procedure as described above using rc 0.3.1 works fast.

wild guesses/suggestions:

• did you change something regarding the sorting?
• is it possible to test a reversed order of the two described ajax calls?
• is there anything else you can think of that might improve performance? e.g. cancel a call after hitting imap_timeout and instantly retrying - maybe this benefit in this case?

thanks,

[rcubetrac]

Comment by @alecpl on 28 May 2010 17:00 UTC

Enable imap_debug and you'll see what's changed. The getunread action will be probably extended in the future, also if you have more folders it will be more performance expensive. So, I don't think we can improve something here. Changing order of these ajax calls is not a solution.

[rcubetrac]

Status changed by @alecpl on 28 May 2010 17:00 UTC

new => closed

[rcubetrac]

Comment by @alecpl on 28 May 2010 17:02 UTC

If you're sorting messages by date try to set sorting by arrival date or by "None".

[rcubetrac]

Comment by maras on 27 Jun 2010 22:24 UTC

I experience exactly the same problem in 0.4 while 0.3 works perfectly. I use courier-imap.

[rcubetrac]

Status changed by maras on 27 Jun 2010 22:24 UTC

closed => reopened

[rcubetrac]

Severity changed by maras on 27 Jun 2010 22:24 UTC

normal => major

[rcubetrac]

Comment by @alecpl on 28 Jun 2010 05:58 UTC

@maras: please, do not reopen ticket without feedback info. You should at least try svn-trunk version.

[rcubetrac]

Status changed by @alecpl on 28 Jun 2010 05:58 UTC

reopened => closed