"No messages found" error with courier imap

[maharaja]

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

[alec]

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

[maharaja]

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.

[alec]

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.

[maharaja]

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.

[alec]

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?

[maharaja]

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_configimap_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

[maharaja]

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,

[alec]

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.

[alec]

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

[maras]

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

[alec]

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