Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"No messages found" error with courier imap #2870

Closed
rcubetrac opened this issue May 27, 2010 · 16 comments

Comments

@rcubetrac
Copy link

commented May 27, 2010

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

This comment has been minimized.

Copy link
Author

commented May 27, 2010

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

=> none

@rcubetrac

This comment has been minimized.

Copy link
Author

commented May 28, 2010

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

This comment has been minimized.

Copy link
Author

commented May 28, 2010

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

This comment has been minimized.

Copy link
Author

commented May 28, 2010

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

This comment has been minimized.

Copy link
Author

commented May 28, 2010

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

This comment has been minimized.

Copy link
Author

commented May 28, 2010

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

This comment has been minimized.

Copy link
Author

commented May 28, 2010

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

This comment has been minimized.

Copy link
Author

commented May 28, 2010

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

This comment has been minimized.

Copy link
Author

commented May 28, 2010

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

This comment has been minimized.

Copy link
Author

commented May 28, 2010

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

new => closed

@rcubetrac

This comment has been minimized.

Copy link
Author

commented May 28, 2010

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

This comment has been minimized.

Copy link
Author

commented Jun 27, 2010

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

This comment has been minimized.

Copy link
Author

commented Jun 27, 2010

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

closed => reopened

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jun 27, 2010

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

normal => major

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jun 28, 2010

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

This comment has been minimized.

Copy link
Author

commented Jun 28, 2010

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

reopened => closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.