Subject: bug#43682: closed (Re: bug#43682: 28.0.50; Clean up nnimap server buffers?)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 12 Oct 2021 20:51:02 +0000

Your bug report

#43682: 28.0.50; Clean up nnimap server buffers?

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
43682: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43682
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#43682: 28.0.50; Clean up nnimap server buffers?
From: Eric Abrahamsen <[email-masked]>
To: Stefan Kangas <[email-masked]>
Cc: Lars Ingebrigtsen <[email-masked]>, [email-masked]
Date: Tue, 12 Oct 2021 13:50:17 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

On 10/11/21 05:53 AM, Stefan Kangas wrote:
> Eric Abrahamsen <[email-masked]> writes:
>
>> On 10/01/20 18:01 PM, Lars Ingebrigtsen wrote:
>>> Eric Abrahamsen <[email-masked]> writes:
>>>
>>>> It's possible (I'm not claiming to understand all the code) that all we
>>>> would need to do is fix `gnus-async-wait-for-article' to replace its
>>>> calls to `nntp-find-connection' and `nntp-accept-process-output' with
>>>> something generalized. Those two functions deal with directly with
>>>> `nntp-connection-alist', so we'd need something that would do the
>>>> equivalent with `nnimap-connection-alist'.
>>>
>>> Yup.
>>
>> This is something I wouldn't want to tackle until we have generic
>> functions.
>>
>>>> Anyway, in the interest of completing this far less ambitious patch: if
>>>> the nnimap connection has timed out, we should remove this connection
>>>> from `nnimap-connection-alist', so this version of the patch does that.
>>>> If async has opened a second connection, I guess we should leave that
>>>> alone, though I don't have too much confidence that the whole process
>>>> will recover gracefully from the main connection dying...
>>>
>>> Well, the connections are separate, and there's all kinds of reasons for
>>> the server to close a connection, so...
>>>
>>>> +	    (unless (memq (process-status (get-buffer-process buffer))
>>>> +			  '(open run))
>>>
>>> Aka `process-live-p'.
>>
>> I forgot we have that!
>>
>>> Otherwise looks fine to me (but I haven't tested the code).
>>
>> Okay, I'll run this for a bit, as well.
>
> Any news here?  Should the fix be installed?

Okay, I've pushed a commit that fixes nearly all of the issue. There are
still some mysterious circumstances under which a single dead imap
connection buffer remains in `nnimap-process-buffers', and I don't know
how it gets there. But it's better than 50+ dead connection buffers, so
I'm going to close this for now.

Subject: 28.0.50; Clean up nnimap server buffers?
From: Eric Abrahamsen <[email-masked]>
To: [email-masked]
Date: Mon, 28 Sep 2020 16:37:15 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

Someone noted on gnus.general that their imap connections are frequently
broken, and they end up with a lot of dead process buffers.

I'm talking to them about maybe making the keepalive timeout
configurable, but wouldn't also be tidy to clean up dead process
buffers? How does the attached patch look?

Eric

diff --git a/lisp/gnus/nnimap.el b/lisp/gnus/nnimap.el
index d797e893f5..7f2ebe279e 100644
--- a/lisp/gnus/nnimap.el
+++ b/lisp/gnus/nnimap.el
@@ -407,8 +407,15 @@ nnimap-keepalive
 		      (time-subtract
 		       now
 		       (nnimap-last-command-time nnimap-object))))
-            (ignore-errors              ;E.g. "buffer foo has no process".
-              (nnimap-send-command "NOOP"))))))))
+	    (condition-case err
+		(process-send-string "NOOP")
+	      (error
+	       (if (string-search "has no process" (cdr err))
+		   (let ((buf (current-buffer)))
+		     (setq nnimap-process-buffers
+			   (delq buf nnimap-process-buffers))
+		     (kill-buffer buf))
+		 (signal (car err) (cdr err)))))))))))
 
 (defun nnimap-open-connection (buffer)
   ;; Be backwards-compatible -- the earlier value of nnimap-stream was
@@ -1910,6 +1917,10 @@ nnimap-find-connection
 		     '(open run)))
 	  (get-buffer-process (cadr entry))
 	(setq nnimap-connection-alist (delq entry nnimap-connection-alist))
+	(setq nnimap-process-buffers
+	      (delq (cadr entry) nnimap-process-buffers))
+	(when (buffer-live-p (cadr entry))
+	  (kill-buffer (cadr entry)))
 	nil))))
 
 ;; Leave room for `open-network-stream' to issue a couple of IMAP