On Tue, 04 Jul 2023 20:50:05 -0700 Eric Abrahamsen <e...@ericabrahamsen.net> wrote:
> Stephen Berman <stephen.ber...@gmx.net> writes: > >> On Tue, 04 Jul 2023 10:02:34 -0700 Eric Abrahamsen <e...@ericabrahamsen.net> >> wrote: >> >>> Stephen Berman <stephen.ber...@gmx.net> writes: > > [...] > >> This: >> >> (defun srb-gnus-group-get-new-news (&optional arg one-level) >> (interactive "P") >> (with-timeout (1 (kill-buffer (nntp-find-connection-buffer >> nntp-server-buffer)) >> (gnus-group-get-new-news)) >> (gnus-group-get-new-news arg one-level))) >> >> (define-key gnus-group-mode-map "g" 'srb-gnus-group-get-new-news) >> >>> Eric F is just describing the >>> unfortunate behavior of nntp-connection-timeout, which interrupts the >>> entire fetching process when it hits the timeout. >> >> Is that different than what the above function does with the kill-buffer >> sexp? (Not a rhetorical question, I know next to nothing about news >> servers and their connectivity issues.) > > The `nntp-connection-timeout' variable has different behavior in that > NNTP servers are allowed one "retry" if the connection fails. The code > around that is very confusing to me (which is why my earlier fix was > buggy). I don't follow you, but no need to elaborate further here. >>>>> Yeah, I'd put in a dumb fix for this that turned out to be buggy, so we >>>>> just recently reverted it. I have a more thorough fix in progress >>>>> somewhere here, that would report a server connection failure without >>>>> interrupting the rest of the servers, but it's not done yet. I've had >>>>> very little time for coding recently, but will get to it At Some Point. >>>>> >>>>> Glad it's at least better than it was. I wonder if we should have some >>>>> generous timeout set by default... >>>> >>>> It might make sense to continue this discussion in bug#52735. >>> >>> This doesn't seem like the same issue -- this problem is pretty well >>> understood. >> >> Hm, I had understood from both Prashant Tak and Eric Fraga that the >> problem they have is essentially the same as I do and what I reported in >> that bug. But that problem doesn't seem to be understood. If by the >> understood problem you mean the effect of nntp-connection-timeout, >> doesn't that just mean using it isn't a real fix for the hang the three >> of us (at least) are experiencing? That's why I thought other >> approaches need to be considered and bug#52735 seems like the >> appropriate venue for that. But I'm fine with continuing the discussion >> here instead. > > Oh I see what you mean. In your bug report I'd gotten the idea that > something was going wrong with accepting process output, and had a > missed-the-forest-for-the-trees moment around it simply being a dead > process. > > Using `nntp-connection-timeout' is the proper fix for this problem, it's > just got a bit of unfortunate behavior that needs to be remedied. I'd be > inclined to start a whole new bug report for a fix for that, because > it's really a new issue, with its own larger-reaching design decisions. > I suppose we could merge #52735 with that, though. Feel free to open a new bug for fixing nntp-connection-timeout. I don't know if I can help, other than trying out suggestions and providing feedback. In the meantime I'll keep using my workaround replacement function. But I wonder, could this issue have been triggered by some change in news.gmane.io around early to mid December 2021? Because that's when the problem start for me, and prior to that I don't recall ever having this problem (perhaps sporadically but not with such persistance). Steve Berman
