Re: How to handle when a server is down?

Re: How to handle when a server is down?

[Vasily Korytov]

>>>>> "DM" == David Masterson writes:

 DM> I have subscribed to several newsgroups on my primary news server as
 DM> well as a few foreign newsgroups on a couple of other news servers.
 DM> Occasionally, although my primary server is up, one of the other news
 DM> servers is down temporarily.  Therefore, when I start 'gnus', it hangs
 DM> waiting for this server to answer the NNTP request.  What's the best
 DM> way to work around this?

 DM> * I know I could use 'gnus-no-server', but then only the foreign
 DM> newsgroups are visible in the Group buffer.

 DM> * The 'gnus-fetch-group' seems to be the long-winded way around this,
 DM> but I'd have to remember the list of groups I'm interested in.

 DM> Is there a better way?

I'd install a local news server. Say, leafnode. (Some people also say,
nntpcache is a good alternative, but I haven't tried it; As for Windows,
I'm aware of similar program called Hamster.)

-- 
                     With respect, Vasily Korytov

PGP key fingerprint: A4FE 4665 A720 687F 4ECC 1474 7C16 C498 BAAB C999

Re: How to handle when a server is down?

[David Carlton]

In article <m3znvfvj0t.fsf@localhost.localdomain>, Bob Babcock <wssddc@gis.net> writes:

> I've been told that this isn't the way gnus is supposed to be used,
> but here's how I deal with this problem: you can have different
> .newsrc files for different servers if you name them
> .newsrc-servername.  So I have one for each news server I use.  I
> switch between them using commands of the form:

> (defun news-earthlink ()
>   (interactive)
>   (setq gnus-select-method '(nntp "news.earthlink.net")))

> .newsrc-news.earthlink.net and .newsrc-news.earthlink.net.eld then
> track only earthlink newsgroups.  You need to quit from one server
> before switching to another or else you'll still use the .newsrc
> file for the first server after the switch.  (I don't consider this
> a bug.  It's useful if your isp has multiple news servers with
> articles numbered the same and some of those servers are down or
> overloaded.)

I was just browsing through my .emacs file (well, actually my
.xemacs/init.el file), and I noticed the following commented-out code,
dating from maybe 3 or 5 years ago:

;(defun sfrt-gnus ()
;  (interactive)
;  (let ((gnus-nntp-server "news.sfrt.com"))
;    (gnus)))

As with the above poster, I had a special .newsrc file,
.newsrc-news.sfrt.com.  This uses a semi-obsolete variable; probably
better would be

(defun sfrt-gnus ()
  (interactive)
  (let ((gnus-select-method '(nntp "news.sfrt.com")))
    (gnus)))

The point here is that Emacs-lisp is dynamically scoped rather than
lexically scoped, so during the above call to gnus, whenever some
piece of code refers to the variable gnus-select-method, it will get
your local gnus-select-method rather than the global
gnus-select-method.  So as long as Gnus only refers to
gnus-select-method during the inital call to gnus (as opposed to when
you, say, enter a newsgroup to read its messages), this suggestion is
like the above poster's suggestion with the advantage that, if you do
sfrt-gnus, then quit from it, and then do gnus, you'll get back to
your old familiar news settings, which I don't think is the case with
the above poster's suggestion.

But, like I said, this worked several years ago, and for all I know
the design of Gnus has changed enough in the interim that it won't
work any more.  Whether this suggestion or the above poster's
suggestion is better depends on how widely Gnus refers to the
gnus-select-method variable and on how transient you want your
changing of news servers to be.

Good luck...

David Carlton
carlton@math.stanford.edu

Re: How to handle when a server is down?

[David Masterson]

>>>>> Kai Großjohann writes:

> David Masterson <dmaster@synopsys.com> writes:
>> There must be a better way than this!  All I want to do is tell Gnus
>> to skip accessing a particular foreign news server this time around
>> and continue accessing the other news servers.

> You can just hit C-g...

Does that "skip" the current server or does it just stop accessing the
services all together?  To me, it seems to be the latter.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: How to handle when a server is down?

[Mark Triggs]

prj@po.cwru.edu (Paul Jarc) writes:
> C-u 1 M-x gnus RET will start Gnus, but only contacting servers that
> have level 1 groups. I think. So set the levels for all your groups
> appropriately, and then if you want to see groups with levels up to,
> say, 3, do C-u 3 M-x gnus RET. See C-h f gnus RET and the "Group
> Levels" node in the manual.

I've had similar problems when accessing groups whose server might be
down. One slight complication with using group levels to solve the
problem is that if the server for groups on level 3 is down, and you're
interested in checking the groups on level 4, hitting '4g' still suffers
from the delay as it also checks groups on level 3.

I'm not sure if the numeric argument for running gnus would behave in
the same way, but I've got a feeling it would. Unfortunately, I don't
know if there's any better way than using group levels as Paul
describes. If you've only got one server which is occasionally down,
this isn't an issue anyway, and you can ignore everything I've written
:o)

If anyone has figured out a different workaround for having multiple
servers which may or may not be down, I'd be keen to hear them.

Cheers,

Mark

-- 
Mark Triggs
<mst@dishevelled.net>

Re: How to handle when a server is down?

[David Masterson]

>>>>> Kai Großjohann writes:

> Recent Oorts see that the server is down and ask me whether I want to
> switch that server to offline mode.  

How does it determine that it's down?  Via the timeout?

> This seems to do just what you need: the server isn't accessed in
> that session.  Switching servers into online mode can be done from
> the *Server* buffer.

This sounds like what I'm after.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA