--- Begin Message ---
|
Subject: |
28.0.50; Clean up nnimap server buffers? |
|
Date: |
Mon, 28 Sep 2020 16:37:15 -0700 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
Description: Text Data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#43682: 28.0.50; Clean up nnimap server buffers? |
|
Date: |
Tue, 12 Oct 2021 13:50:17 -0700 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
On 10/11/21 05:53 AM, Stefan Kangas wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> On 10/01/20 18:01 PM, Lars Ingebrigtsen wrote:
>>> Eric Abrahamsen <eric@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.
--- End Message ---