From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/45130 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: Faster nnimap: nnimap-retrieve-groups-asynchronous Date: Thu, 06 Jun 2002 15:07:35 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1023369034 13854 127.0.0.1 (6 Jun 2002 13:10:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 6 Jun 2002 13:10:34 +0000 (UTC) Cc: ding@gnus.org Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17Fx2A-0003bD-00 for ; Thu, 06 Jun 2002 15:10:34 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17Fwzj-00027b-00; Thu, 06 Jun 2002 08:08:04 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 06 Jun 2002 08:08:21 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id IAA07533 for ; Thu, 6 Jun 2002 08:08:08 -0500 (CDT) Original-Received: (qmail 794 invoked by alias); 6 Jun 2002 13:07:46 -0000 Original-Received: (qmail 789 invoked from network); 6 Jun 2002 13:07:45 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by gnus.org with SMTP; 6 Jun 2002 13:07:45 -0000 Original-Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.4/8.12.4) with ESMTP id g56D7YXq015838; Thu, 6 Jun 2002 15:07:37 +0200 Original-To: =?iso-8859-1?q?Bj=F8rn?= Mork Mail-Copies-To: nobody In-Reply-To: =?iso-8859-1?q?(Bj=F8rn?= Mork's message of "Thu, 06 Jun 2002 13:56:46 +0200") Original-Lines: 106 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:45130 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:45130 Bjørn Mork writes: > Simon Josefsson writes: > >> I tried to speed up new mail checking (`g') on IMAP groups. Startup >> uses old technique, but subsequent `g' can be faster. The speedup >> depends on how many groups usually receives new mail each time you >> press `g' (the p below). It might depend on the server as well. For >> me, it is faster against Cyrus IMAPD -- results from other servers >> would be interesting. > > This speeded up mail checking noticably on all my imap servers, but > unfortunately it's causing a problem with one of them. I could of > course turn it off, but then I lose the performance gain... So I'm > hoping the problem can be fixed. > > I currently use three imap servers: > a) IMAP4 server (InterMail vM.4.01.03.23 201-229-121-123-20010418) > b) Courier-IMAP ready. Copyright 1998-2001 Double Precision, Inc. > c) Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc. I suspect the same problem as Ilpo reported, also Courier IMAPD from what I recall. I haven't debug that yet though. > The problem is that Gnus doesn't detect new mail split into a folder > on b) when pressing 'g'. Doing a 'M-g' on the folder will however show > the new mail. The funny thing is that everything works fine on server > a) and c). So it looks like a combination of a Courier server and > client side splitting is causing the problem, unless there is a > specific problem with the Courier version running on b). Can you find out the server versions used on server a and b? Ilpo was not using client side splitting from what I recall. > 95 EXAMINE "INBOX.Trash" > * FLAGS (\Answered \Flagged \Deleted \Seen \Recent) > * OK [PERMANENTFLAGS ()] No permanent flags permitted > * 0 EXISTS > * 0 RECENT > * OK [UIDVALIDITY 979914089] Ok > 95 OK [READ-ONLY] Ok > [..] > 128 STATUS "INBOX.Trash" (uidnext) > * STATUS "INBOX.Trash" (UIDNEXT 1) > 128 OK STATUS Completed. > [..] > 170 UID FETCH 370 BODY.PEEK[HEADER] > * 131 FETCH (UID 370 BODY[HEADER] {1628} > [snip mail] > 170 OK FETCH completed. > 171 UID COPY 370 "INBOX.Trash" > 171 OK COPY completed. > 172 UID STORE 370 +FLAGS (\Seen \Deleted) > * 131 FETCH (FLAGS (\Seen \Deleted)) > 172 OK STORE completed. > 173 EXPUNGE > * 131 EXPUNGE > * 130 EXISTS > * 0 RECENT > 173 OK EXPUNGE completed > 174 CLOSE > 174 OK mailbox closed. > 175 STATUS "INBOX.Trash" (uidnext) > * STATUS "INBOX.Trash" (UIDNEXT 1) > 175 OK STATUS Completed. > > Hmm, definitely looks like a server problem when I'm looking at it > now. Shouldn't the UIDNEXT value change between command 128 and 175? Hm. At first glance, it looks like it, but it could be valid behaviour if UIDVALIDITY changed. Could you try running with this patch? Does the UIDVALIDITY change between 128- and 175-like commands then? Nnimap is buggy, it should look at UIDVALIDITY as well here. I'll fix it. --- nnimap.el.~6.36.~ Sat May 25 16:16:03 2002 +++ nnimap.el Thu Jun 6 15:05:15 2002 @@ -975,7 +975,8 @@ 'asyncgroups 'slowgroups) (list group (imap-mailbox-status-asynch - group 'uidnext nnimap-server-buffer)))) + group '(uidnext uidvalidity) + nnimap-server-buffer)))) (dolist (asyncgroup asyncgroups) (let ((group (nth 0 asyncgroup)) (tag (nth 1 asyncgroup)) @@ -984,7 +985,8 @@ (if (nnimap-string-lessp-numerical (car (gnus-gethash (concat server group) nnimap-mailbox-info)) - (imap-mailbox-get 'uidnext group nnimap-server-buffer)) + (imap-mailbox-get '(uidnext uidvalidity) + group nnimap-server-buffer)) (push (list group) slowgroups) (insert (cdr (gnus-gethash (concat server group) nnimap-mailbox-info)))))))) > Is this a known problem with the Courier server? No, but there are other known problems with it. The workaround is to disable nnimap-retrieve-groups-asynchronous for the server.