GNU bug report logs - #43682
28.0.50; Clean up nnimap server buffers?

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Subject: bug#43682: closed (Re: bug#43682: 28.0.50; Clean up nnimap server
 buffers?)
Date: Tue, 12 Oct 2021 20:51:02 +0000

[Message part 1 (text/plain, inline)]

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 43682 <at> debbugs.gnu.org.

-- 
43682: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43682
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 43682-done <at> debbugs.gnu.org
Subject: Re: bug#43682: 28.0.50; Clean up nnimap server buffers?
Date: Tue, 12 Oct 2021 13:50:17 -0700

On 10/11/21 05:53 AM, Stefan Kangas wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> On 10/01/20 18:01 PM, Lars Ingebrigtsen wrote:
>>> Eric Abrahamsen <eric <at> ericabrahamsen.net> 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.

[Message part 3 (message/rfc822, inline)]

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Clean up nnimap server buffers?
Date: Mon, 28 Sep 2020 16:37:15 -0700

[Message part 4 (text/plain, inline)]

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

[CleanupImapBuffers.diff (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.