Current emacs version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.14.8, Xaw3d scroll bars) of 2020-09-25 However, I have this same problem whatever the version. Trying to keep the problem simple here, so just saying that for months and months, I'm constantly plagued with gmane.io being unresponsive. It goes like this: Start gnus, enter a newsgroup, maybe read a while and then post a message. By the time I've read 5-6 minutes, my attempt to post a message just gets the busy cursor forever. That is, the server never accepts my message, it seems to have gone dead. I've been doing this to get the server responsive again. Go to server buffer (`^') find the server. It appears normal and running. But I have to click `C' to close it, then `O' to open it. The opening part usually takes 10-15 seconds. Then I can go back to newsgroup and send my message (if I hurry). If I decide another messages is in order then the same process has to be done again. Almost like being unplugged. I'm not seeing other evidence that my internet connection is bad or slow. Other things seem to work as expected. Any ideas how I can do this in some better way. As it is its quite time consuming ... not to mention aggravating to use gnus. And I've used gnus for a very long time. Seems there might be a bit of code I could call instead of going thru the steps in server buffer. Or maybe something more direct to server to keep it alive. Hopefully the cause is some user idiocy or other that can be fixed.
Harry Putnam <reader@newsguy.com> wrote: > […] > Go to server buffer (`^') find the server. It appears normal and > running. But I have to click `C' to close it, then `O' to open it. > The opening part usually takes 10-15 seconds. Then I can go back to > newsgroup and send my message (if I hurry). If I decide another > messages is in order then the same process has to be done again. > […] > Seems there might be a bit of code I could call instead of going thru > the steps in server buffer. > Or maybe something more direct to server to keep it alive. > Hopefully the cause is some user idiocy or other that can be fixed. I know the pain :-) (but it has not been that much of a problem for more in the recent past). One minor improve- ment: You do not have to open the server again (with O); Gnus will do that automatically. Also there is M-c to close all servers (which, again, is benign as Gnus will automati- cally open those that it needs to). I never researched whether one could (or should) call gnus-server-close-all-servers from outside the *Server* buffer. Tim
Tim Landscheidt <tim@tim-landscheidt.de> writes: > Harry Putnam <reader@newsguy.com> wrote: > >> […] > >> Go to server buffer (`^') find the server. It appears normal and >> running. But I have to click `C' to close it, then `O' to open it. >> The opening part usually takes 10-15 seconds. Then I can go back to >> newsgroup and send my message (if I hurry). If I decide another >> messages is in order then the same process has to be done again. > >> […] > >> Seems there might be a bit of code I could call instead of going thru >> the steps in server buffer. > >> Or maybe something more direct to server to keep it alive. > >> Hopefully the cause is some user idiocy or other that can be fixed. > > I know the pain :-) (but it has not been that much of a > problem for more in the recent past). One minor improve- > ment: You do not have to open the server again (with O); > Gnus will do that automatically. Also there is M-c to close > all servers (which, again, is benign as Gnus will automati- > cally open those that it needs to). Over here, M-c is bound to `gnus-group-clear-data', which is a bit of a dangerous function! I think this has been a perennial problem for all of us. I recently added some dbus-related code so that, if you're using a laptop and putting it to sleep, Gnus will close all its servers first, so they get re-opened when the machine wakes. That's not quite the same problem, obviously. I know of two solutions, neither of them perfect. The first is to manually close the server(s) when you suspect they've been open too long. I've gotten in the habit of hitting "z" (gnus-group-suspend) when I haven't touched Gnus for a while. Suspend also clears out windows, which might be overkill. Really all that's necessary is this bit of code: (dolist (elem gnus-opened-servers) (gnus-close-server (car elem))) Or, probably: (gnus-close-server '(nntp "news.gmane.io")) The other solution is to set `nntp-connection-timeout' to a number of seconds. When you try to connect to the server and get no response before those number of seconds, Gnus signals `quit'. This isn't great because 1) you have to wait for the timeout even when it's obvious the connection is dead, and 2) the quit interrupts everything you're doing. It would be better if it gave you a message and skipped the operation, or even better, restarted the operation. NNTP doesn't support any kind of keepalive/ack protocol, from what I gather, so the only other solution would probably be to start a timer from the last successful command response, and then just silently close the connection when the timer is up. > I never researched whether one could (or should) call > gnus-server-close-all-servers from outside the *Server* > buffer. From a brief look at the code, it seems like it ought to work. I've never tried it either, though. Eric
Eric writes:
> I think this has been a perennial problem for all of us.
Hm, I don't see this problem.
I wonder if it is because I am network-wise close to the server
(Denmark → Germany, I believe).
Or because I've configured Gnus to check for news every 5 minutes when
Emacs is idle (and I run an Emacs for Gnus only), so the connection is
kept alive that way.
Hm!?
Just another data point,
Adam
--
"Här kommer rädslan, gamle vän Adam Sjøgren
När alla fjärilar i magen vaknar upp asjo@koldfront.dk
Viskar välkommen hem"
I added this to my .gnus some years ago: (defun jimc-group-select-group-with-fresh-imapd (&optional all) "select the group with a fresh imapd process." (interactive "P") (gnus-server-close-server "nnimap:MYSERVER") (when (and (eobp) (not (gnus-group-group-name))) (forward-line -1)) (gnus-group-read-group all t)) (add-hook 'gnus-group-mode-hook (lambda () (local-set-key "\C-ci" 'jimc-group-select-group-with-fresh-imapd))) as one can see it is specific for my needs; s// MYSERVER with your nnimap server name... -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Adam Sjøgren <asjo@koldfront.dk> writes:
> Eric writes:
>
>> I think this has been a perennial problem for all of us.
>
> Hm, I don't see this problem.
>
> I wonder if it is because I am network-wise close to the server
> (Denmark → Germany, I believe).
>
> Or because I've configured Gnus to check for news every 5 minutes when
> Emacs is idle (and I run an Emacs for Gnus only), so the connection is
> kept alive that way.
I would guess this is the answer. Kind of a manual, heavyweight
keepalive. My feeling is that, when the connection dies, I've usually
left it alone for ~10 minutes or more.
Eric writes: > Adam Sjøgren <asjo@koldfront.dk> writes: >> I wonder if it is because I am network-wise close to the server >> (Denmark → Germany, I believe). >> >> Or because I've configured Gnus to check for news every 5 minutes when >> Emacs is idle (and I run an Emacs for Gnus only), so the connection is >> kept alive that way. > > I would guess this is the answer. Kind of a manual, heavyweight > keepalive. My feeling is that, when the connection dies, I've usually > left it alone for ~10 minutes or more. Dunno about "manual", it's very hands off :-) In case somebody wants to test, this is what I've got in .gnus: ; Demon to fetch email/news every 5 minutes when Emacs has been idle for 5 minutes: (gnus-demon-add-handler 'gnus-demon-scan-news 5 5) (gnus-demon-init) Best regards, Adam -- "You're not Superman you know." Adam Sjøgren asjo@koldfront.dk