From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/65054 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.general Subject: Re: closing all inactive server connections Date: Thu, 16 Aug 2007 16:18:20 +0900 Organization: Emacsen advocacy group Message-ID: References: <87zm0tyr2r.fsf@mocca.josefsson.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: sea.gmane.org 1187248802 17867 80.91.229.12 (16 Aug 2007 07:20:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2007 07:20:02 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M13564@lists.math.uh.edu Thu Aug 16 09:20:00 2007 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1ILZeA-0000Hr-Ho for ding-account@gmane.org; Thu, 16 Aug 2007 09:19:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1ILZdK-0004mG-W0; Thu, 16 Aug 2007 02:19:07 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1ILZdI-0004lw-VH for ding@lists.math.uh.edu; Thu, 16 Aug 2007 02:19:04 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.67) (envelope-from ) id 1ILZdH-00056I-4E for ding@lists.math.uh.edu; Thu, 16 Aug 2007 02:19:04 -0500 Original-Received: from orlando.hostforweb.net ([216.246.45.90]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ILZdF-0002If-00 for ; Thu, 16 Aug 2007 09:19:02 +0200 Original-Received: from [66.225.201.151] (port=42807 helo=mail.jpl.org) by orlando.hostforweb.net with esmtpa (Exim 4.63) (envelope-from ) id 1ILZce-0001ry-Ic for ding@gnus.org; Thu, 16 Aug 2007 02:18:25 -0500 X-Hashcash: 1:20:070816:ding@gnus.org::mSSyzSk+oBU2GxLO:000002so X-Face: #kKnN,xUnmKia.'[pp`;Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu;B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1.50 (gnu/linux) Cancel-Lock: sha1:hRH5KHyVDKsNA/3QCuSYububw58= X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - orlando.hostforweb.net X-AntiAbuse: Original Domain - gnus.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.4 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:65054 Archived-At: --=-=-= >>>>> Simon Josefsson wrote: > Katsumi Yamaoka writes: >> (while (and (memq (process-status PROCESS) '(open run)) >> (wait-for-a-string-that-the-PROCESS-returns)) >> (accept-process-output PROCESS 1) >> (sit-for 1)) >> >> This can be an infinite loop if the process-status keeps `open' >> or `run' even though the connection has actually died. > Can that happen? Wouldn't that be an emacs bug? Shouldn't > process-status return exit or closed if a connect/process has gone away? I meant that the /connection/ is the one between the frontend of Ted Zlatanov's local network (i.e., VPN) and the IMAP server (see http://article.gmane.org/gmane.emacs.gnus.general/64906). In his case, the connection between Emacs and the frontend seems to be alive even after the connection between the frontend and the IMAP server dies. So, ideally, what needs to be fixed should be the VPN program, not be Emacs or Gnus, I think, and the plan I proposed was no more than a workaround. But I thought it was not necessarily a bad idea even if the problem in the VPN program can be solved soon, because people in the VPN networks might not necessarily be able to ask the administrators to replace the program with the corrected one. >> In particular, the `imap-wait-for-tag' function can be the cause of >> the hanging since it sends the LOGOUT command to the dead server and >> waits for the response. So, I tried modifying it so as to quit in a >> certain time. The patch to imap.el is below. Anyway, it needs to be >> reviewed by someone who is skilled in IMAP. The default value of >> `imap-timeout-seconds' might be too small for slow connections. [...] > This is a bad idea even for fast servers -- some operations (such as > deleting or renaming a mailabox) can take several minutes. Gnus > shouldn't assume the server isn't responding in this (and other) cases. Ok, but I didn't know it. > Ted Zlatanov writes: >> Maybe it should be generalized, however, to an IMAP timeout per (server, >> group name, command) combination (as a regex or a function), so you can >> assign "LOGOUT" a longer timeout with a slower server. This could also >> be a server tuning parameter for nnimap instead of an imap.el parameter. > Having the timeout be restricted to just LOGOUT seems to make more sense > to me. If the server doesn't respond to a LOGOUT within a short period > of time, one might as well disconnect. I see. It looks sufficient for Ted. >>>>> Reiner Steib wrote: > On Tue, Jul 31 2007, Katsumi Yamaoka wrote: >> +(defvar imap-timeout-seconds 1 >> + "*Number of seconds in which `imap-close' gives up working.") > Nitpick: Either the "*" should be removed or it should be a defcustom. > Shouldn't it? I agree to making it use defcustom. In addition, a good default will probably be the value meaning there's no timeout. Anyway I use neither nnimap nor VPN at all, and I can neither reproduce the problem nor verify this workaround. So, I wish Simon and Ted to take on this. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment Content-Description: Patch for imap.el --=-=-=--