From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/45128 Path: main.gmane.org!not-for-mail From: =?iso-8859-1?q?Bj=F8rn?= Mork Newsgroups: gmane.emacs.gnus.general Subject: Re: Faster nnimap: nnimap-retrieve-groups-asynchronous Date: Thu, 06 Jun 2002 13:56:46 +0200 Organization: Debt orbiting Drooling 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 1023364707 5632 127.0.0.1 (6 Jun 2002 11:58:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 6 Jun 2002 11:58:27 +0000 (UTC) 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 17FvuN-0001Sd-00 for ; Thu, 06 Jun 2002 13:58:27 +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 17Fvt5-0001oi-00; Thu, 06 Jun 2002 06:57:07 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 06 Jun 2002 06:57:24 -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 GAA07400 for ; Thu, 6 Jun 2002 06:57:11 -0500 (CDT) Original-Received: (qmail 23331 invoked by alias); 6 Jun 2002 11:56:49 -0000 Original-Received: (qmail 23326 invoked from network); 6 Jun 2002 11:56:49 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by gnus.org with SMTP; 6 Jun 2002 11:56:49 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 17FwDw-0002Tk-00 for ; Thu, 06 Jun 2002 14:18:40 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 84 Original-NNTP-Posting-Host: 148.122.193.18.dhcp.nextra.no Original-X-Trace: quimby.gnus.org 1023365920 9531 148.122.193.18 (6 Jun 2002 12:18:40 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 6 Jun 2002 12:18:40 GMT User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) Cancel-Lock: sha1:5NCMhpv1cd1ZSwAqU6VVh8T4a+I= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:45128 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:45128 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 can't do server side splitting on a) and b), so I'm using a nnimap-split-rule on them. c) is doing server side splitting using procmail. 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). This is a small extract of the imap-log on server b): 91 EXAMINE "INBOX" * FLAGS (\Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS ()] No permanent flags permitted * 131 EXISTS * 1 RECENT * OK [UIDVALIDITY 979914089] Ok 91 OK [READ-ONLY] Ok [..] 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? Is this a known problem with the Courier server? Maybe I should do some experiments with client side splitting on my c) server, too. Bjørn -- So, your ten-incher is great?