noffle-devel Mailing List for Noffle - news server (Page 7)
Brought to you by:
bears
Menu
▾
▴
noffle-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(17) |
Jul
(53) |
Aug
(14) |
Sep
(8) |
Oct
(16) |
Nov
(7) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(5) |
Feb
(4) |
Mar
(2) |
Apr
|
May
(22) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(23) |
Dec
(1) |
| 2002 |
Jan
(4) |
Feb
(1) |
Mar
(20) |
Apr
(7) |
May
(8) |
Jun
(9) |
Jul
(7) |
Aug
(4) |
Sep
|
Oct
(11) |
Nov
(2) |
Dec
(6) |
| 2003 |
Jan
(5) |
Feb
(11) |
Mar
(11) |
Apr
|
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(4) |
| 2006 |
Jan
(3) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(9) |
Jun
(26) |
Jul
(11) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Markus E. <me...@ma...> - 2001-10-21 16:20:45
|
On Sun, Oct 21, 2001 at 12:05:05PM +0100, Jim Hague wrote: > Much simpler to just change the auto-unsubscribe criteria to unsubscribe if > time of arrival of last article is threshold days later than time of last group > access. So I've done that. Simple and a perfect solution to the problem :) - Markus |
|
From: Jim H. <jim...@ac...> - 2001-10-21 11:05:12
|
On 20-Oct-2001 I wrote: > In an attempt to do something about this (insipired by a recent comment in > the leafnode mailing list), I've just checked in a change that tracks the > last time an article arrived in a group. If a group hits the expiry > threshold, then if there have been no new articles in that time I touch the > last access time instead of unsubscribing. Duh. Not the right answer at all. Much simpler to just change the auto-unsubscribe criteria to unsubscribe if time of arrival of last article is threshold days later than time of last group access. So I've done that. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: Jim H. <jim...@ac...> - 2001-10-20 14:35:31
|
I am subscribed to a couple of internal newsgroups at work that are seriously low traffic. They regularly get unsubscribed because I haven't access them for the prescribed duration; but the reason for that is because there have been no new articles in that time. In an attempt to do something about this (insipired by a recent comment in the leafnode mailing list), I've just checked in a change that tracks the last time an article arrived in a group. If a group hits the expiry threshold, then if there have been no new articles in that time I touch the last access time instead of unsubscribing. This scheme isn't perfect. I'm wondering if I should also be touching the last access time if a new post arrives and the previous post time was over the threshold. That way, you avoid the situation where you get unsubscribed because a new post arrives just before the expire run. Any further ideas? Next mini-project: on posting, verify message IDs against the RFC2822 spec and replace if not compliant. Then remove the 'always replace message ID' flag. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: Jim H. <jim...@ac...> - 2001-08-08 15:09:48
|
FYI, I've checked in a change to main which makes logging selectable from noffle.conf. Logging is always available, regardless of build type, so I've rationalised the build types to simply with/without debug info. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: Markus E. <me...@ma...> - 2001-06-19 19:49:24
|
On Tue, Jun 19, 2001 at 06:32:14PM +0200, Alberto Mardegan wrote: > ... I was thinking of subscribing to a free newsserver and let noffle > get the articles from it. But I wanted to know if this could lead to > some corruption in the noffle's article database, or if I'll get > duplicate messages when (hopefully soon) my ISP's server will come back > to normal. Hello Alberto, duplicated or missing articles can occur (it depends on the max-fetch option in noffle.conf what is more likely), but no corruption should happen. See you - Markus |
|
From: Alberto M. <ama...@io...> - 2001-06-19 16:29:31
|
... I was thinking of subscribing to a free newsserver and let noffle
get the articles from it. But I wanted to know if this could lead to
some corruption in the noffle's article database, or if I'll get
duplicate messages when (hopefully soon) my ISP's server will come back
to normal.
TIA.
--
Saluti,
Mardy
|
|
From: Markus E. <me...@ma...> - 2001-05-14 06:57:54
|
On Sun, May 13, 2001 at 10:09:40PM +0200, Alberto Mardegan wrote: > Ehm, no: I tried to go online and... > > Fetch from 'news.iol.it' > Bad server stat 503 > Could not connect to news.iol.it > Fetch from 'inn.qnx.com' > Bad server stat 503 > Could not connect to inn.qnx.com > Fetch from 'news.freshmeat.net' > Bad server stat 503 > Could not connect to news.freshmeat.net oops, there seems to be a small bug in my latest changes. I will look into it and send you a corrected version. Sorry - Markus |
|
From: Alberto M. <ama...@io...> - 2001-05-13 20:07:20
|
On Sun, May 13, 2001 at 08:53:24PM +0200, Alberto Mardegan wrote: > I jus wanted to make sure I did the right thing: > ./configure > make > > I didn't launch "make install", since I have a Debian and I didn't want > to mess up the system: I just copied the src/noffle file to > /usr/bin/noffle . > I had to copy the old file /etc/noffle/conf to /etc/noffle.conf > since I was too lazy to recompile noffle with the right compile option. > :-) > > Anyway, everything looks ok. Ehm, no: I tried to go online and... Fetch from 'news.iol.it' Bad server stat 503 Could not connect to news.iol.it Fetch from 'inn.qnx.com' Bad server stat 503 Could not connect to inn.qnx.com Fetch from 'news.freshmeat.net' Bad server stat 503 Could not connect to news.freshmeat.net -- Saluti, Mardy |
|
From: Alberto M. <ama...@io...> - 2001-05-13 18:57:05
|
I jus wanted to make sure I did the right thing:
./configure
make
I didn't launch "make install", since I have a Debian and I didn't want
to mess up the system: I just copied the src/noffle file to
/usr/bin/noffle .
I had to copy the old file /etc/noffle/conf to /etc/noffle.conf
since I was too lazy to recompile noffle with the right compile option.
:-)
Anyway, everything looks ok.
--
Saluti,
Mardy
|
|
From: Alberto M. <ama...@io...> - 2001-05-12 15:19:38
|
On Sat, May 12, 2001 at 11:00:24AM +0200, Markus Enzenberger wrote:
> I can send you a tar file with the present state of this branch,
> if you are not experienced with using CVS.
Yes, it would be the wisest thing. :-)
--
Saluti,
Mardy
|
|
From: Markus E. <me...@ma...> - 2001-05-12 09:01:10
|
On Fri, May 11, 2001 at 06:42:47PM +0200, Alberto Mardegan wrote: > > Any volunteers for testing the release-1-0 line, > > before I make a new maintainance release (version 1.0.1)? > > Yes, but please tell me a complete URL: I don't understand the > versioning convention, if 1-0 is different from main, or not. Thanks for helping. The bug-fix line for version 1.0 is the branch "release-1-0" in CVS. I can send you a tar file with the present state of this branch, if you are not experienced with using CVS. - Markus |
|
From: Alberto M. <ama...@io...> - 2001-05-11 16:41:02
|
On Thu, May 10, 2001 at 10:06:47PM +0200, Markus Enzenberger wrote:
>
> Any volunteers for testing the release-1-0 line,
> before I make a new maintainance release (version 1.0.1)?
Yes, but please tell me a complete URL: I don't understand the
versioning convention, if 1-0 is different from main, or not.
--
Saluti,
Mardy
|
|
From: Markus E. <me...@ma...> - 2001-05-11 07:56:52
|
On Thu, May 10, 2001 at 09:37:45PM +0100, Jim Hague wrote: > jim@mail:~/src$ telnet localhost nntp > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > 200 NNTP server NOFFLE 1.1-unstable-develop > group uk.comp.os.linux > 211 3747 95091 98837 uk.comp.os.linux selected > head 100 > 423 No such article number > head <xy...@fo...> > 430 No such article > quit > 205 Goodbye > Connection closed by foreign host. I was wrong, the different status numbers do work in the main Noffle line. Sorry. > > This is not as clean as using the return values for fatal errors conistently > > and stop the loop in fetch.c, but it is easier and safer to add, > > a cheap optimization without the danger of introducing new bugs > > in the release-1-0 line. > > For the 1.0 line, I agree. Much safer. As you'll have seen, I'm attempting to > do it 'properly' in the main line. I'm not really happy about one part at > present; Client_postArt now uses the return value to indicate 'transaction > complete without connection error' and relies on finding a non-empty error > string to indicate posting refused by the server. But looking again, maybe it's > not that bad. ;-) The idea was, that the return values in client.c always indicate whether a fatal error occurred (a loss of the connection) and no other functions in client.c for this connection should be called if one function returns FALSE. But why not use such a flag anyway for safety? The bug that occurred when the higher level code continued to call functions in client.c and got wrong server responses was quite severe and there is always some danger, that such things happen. See you - Markus |
|
From: Jim H. <jim...@ac...> - 2001-05-10 20:37:50
|
On 10-May-2001 Markus Enzenberger wrote: > I already fixed it in the release-1-0 line. > Jim, it seems that your patch to the main line now always returns 423. Really? What did you do? jim@mail:~/src$ telnet localhost nntp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 200 NNTP server NOFFLE 1.1-unstable-develop group uk.comp.os.linux 211 3747 95091 98837 uk.comp.os.linux selected head 100 423 No such article number head <xy...@fo...> 430 No such article quit 205 Goodbye Connection closed by foreign host. > I also did a bugfix for the timeout problem in the release-1-0 branch, > using a flag in client.c, so that if a read fails once, it will > also fail on subsequent reads. Yes, that approach did occur to me too. > Maybe I use this flag for more functions in client.c, > so that Noffle stops the fetching earlier on a breakdown of > the connection. > This is not as clean as using the return values for fatal errors conistently > and stop the loop in fetch.c, but it is easier and safer to add, > a cheap optimization without the danger of introducing new bugs > in the release-1-0 line. For the 1.0 line, I agree. Much safer. As you'll have seen, I'm attempting to do it 'properly' in the main line. I'm not really happy about one part at present; Client_postArt now uses the return value to indicate 'transaction complete without connection error' and relies on finding a non-empty error string to indicate posting refused by the server. But looking again, maybe it's not that bad. ;-) > Any volunteers for testing the release-1-0 line, > before I make a new maintainance release (version 1.0.1)? -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: Markus E. <me...@ma...> - 2001-05-10 20:07:59
|
On Wed, May 09, 2001 at 08:36:27PM +0100, Jim Hague wrote: > Hmm. INN, Typhoon and NNTPcache all give 423 for no article number and 430 for > no article ID. > > I'll fix it in the main line. I already fixed it in the release-1-0 line. Jim, it seems that your patch to the main line now always returns 423. I also did a bugfix for the timeout problem in the release-1-0 branch, using a flag in client.c, so that if a read fails once, it will also fail on subsequent reads. Maybe I use this flag for more functions in client.c, so that Noffle stops the fetching earlier on a breakdown of the connection. This is not as clean as using the return values for fatal errors conistently and stop the loop in fetch.c, but it is easier and safer to add, a cheap optimization without the danger of introducing new bugs in the release-1-0 line. Any volunteers for testing the release-1-0 line, before I make a new maintainance release (version 1.0.1)? See you - Markus |
|
From: Jim H. <jim...@ac...> - 2001-05-09 19:36:33
|
On 09-May-2001 Alberto Mardegan wrote: > 200 NNTP server NOFFLE 1.0pre8 > article <u9m...@4a...> > 423 No such article > quit > 205 Goodbye > Connection closed by foreign host. > > Were you wrong, or is this a bug of noffle? Well spotted! It could be the NNTP draft I'm working from is out of date and this has changed, but it does look like bug in Noffle to me, abeit not a hugely serious one. I'll double check... Hmm. INN, Typhoon and NNTPcache all give 423 for no article number and 430 for no article ID. I'll fix it in the main line. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: Alberto M. <ama...@io...> - 2001-05-09 17:27:21
|
On Wed, May 09, 2001 at 09:25:58AM +0100, Jim Hague wrote:
> I strongly suspect this is behind the weirdness that Alberto is seeing as well.
> Alberto, if you look above the troublesome points in your logs do you find any
> 'Connection to remote server lost' messages?
Yes, every time I've had problems, I found that message.
--
Saluti,
Mardy
|
|
From: Alberto M. <ama...@io...> - 2001-05-09 17:27:18
|
On Tue, May 08, 2001 at 03:39:03PM +0100, Jim Hague wrote:
> 430 is the response when trying to retrieve an article by article ID. 423
> should be given when trying to retrieve by article number.
I just tried:
pupilla:~$ telnet localhost 119
Trying 127.0.0.1...
Connected to pupilla.
Escape character is '^]'.
200 NNTP server NOFFLE 1.0pre8
article <u9m...@4a...>
423 No such article
quit
205 Goodbye
Connection closed by foreign host.
Were you wrong, or is this a bug of noffle?
--
Saluti,
Mardy
|
|
From: Markus E. <me...@ma...> - 2001-05-09 14:12:48
|
At 09:25 09.05.2001 +0100, Jim Hague wrote: >It might be possible to reproduce by setting the connection timeout really >short. > >May 8 00:02:01 ginetta noffle[16701]: Reading /var/spool/noffle/fetchlist >May 8 00:02:01 ginetta noffle[16701]: [S] GROUP alt.oxford.talk >May 8 00:02:01 ginetta noffle[16701]: [S FLUSH] >May 8 00:02:31 ginetta noffle[16701]: Connection to remote server lost >(article numbers could be inconsistent) >May 8 00:02:31 ginetta noffle[16701]: Could not change to group thanks for tracking the bug, Jim. From the time info you can see, that a timeout (default==30sec) caused Noffle to think that the connection broke down. But because Noffle continues to send command and the answer from the server was still on its way, Noffle receives and interprets answers to wrong commands. This is an urgent bug and I will fix it in the release-1-0 line soon. BTW the config option should better be named "timeout" instead of "connect_timeout", because it is also used for receiving answers. Alberto, you can increase "connect-timeout" in "noffle.conf" meanwhile, this should avoid this bug. See you - Markus |
|
From: Jim H. <jim...@ac...> - 2001-05-09 11:35:16
|
On 09-May-2001 Jim Hague wrote: > I've given it a limited test, and it does appear to bail out properly. I'll > check it into CVS as soon as I can - Sourceforge isn't talking to me right > now. OK, checked in. Wrong ssh permissions settings. BTW, my Noffle server with the incorrect postings is getting its news from a server running Typhoon - Typhoon also runs on Alberto's upstream server. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: Jim H. <jim...@ac...> - 2001-05-09 10:58:32
|
On 09-May-2001 Jim Hague wrote: >> * Make Noffle handle a connection break-down during a fetch more >> gracefully. >> At present it still continues to fetch articles, generating a >> retrieving failed article for each article left. >> >> Maybe we should move this to Urgent and even fix it in the release-1-0 >> branch also. > > Agreed on both points. If we lose the connection we MUST bail out of the > fetch straight away. We should also perhaps consider making the server > connection timeout a per-server configuration it. OK, that wasn't too bad. I have modified my copy of the main line to abort a connection if the connection appears lost or an unexpected response arrives. I've given it a limited test, and it does appear to bail out properly. I'll check it into CVS as soon as I can - Sourceforge isn't talking to me right now. I note we're perhaps a bit casual about checking the result of disc operations, but I'm not doing anything about that right now. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: Jim H. <jim...@ac...> - 2001-05-09 08:26:06
|
(Order of quoted article re-arranged) On 08-May-2001 Markus Enzenberger wrote: >> However, I also recently had an incident when a load of articles were dumped >> into the wrong group (this, admittedly, was on the CVS main line). I wonder >> if > > I have no explanation for the articles in wrong groups. > Is this another bug? Is it reproducible? I have managed to track down a complete log of the session during which old articles from netscape.public.mozilla.unix landed in rec.humor.funny. Check for commentary inserted below with ****!!!!!. It might be possible to reproduce by setting the connection timeout really short. May 8 00:02:01 ginetta noffle[16701]: Reading /var/spool/noffle/fetchlist May 8 00:02:01 ginetta noffle[16701]: [S] GROUP alt.oxford.talk May 8 00:02:01 ginetta noffle[16701]: [S FLUSH] May 8 00:02:31 ginetta noffle[16701]: Connection to remote server lost (article numbers could be inconsistent) May 8 00:02:31 ginetta noffle[16701]: Could not change to group ****!!!! We can't be sure from here which reply matches which command. alt.oxford.talkMay 8 00:02:31 ginetta noffle[16701]: [S] GROUP comp.os.linux.announce May 8 00:02:31 ginetta noffle[16701]: [S FLUSH] May 8 00:03:01 ginetta noffle[16701]: Connection to remote server lost (article numbers could be inconsistent) May 8 00:03:01 ginetta noffle[16701]: Could not change to group comp.os.linux.announce May 8 00:03:01 ginetta noffle[16701]: [S] GROUP comp.risks May 8 00:03:01 ginetta noffle[16701]: [S FLUSH] May 8 00:03:03 ginetta noffle[16701]: [R] 499 Try again later - remote server down? May 8 00:03:03 ginetta noffle[16701]: Could not change to group comp.risks May 8 00:03:03 ginetta noffle[16701]: [S] GROUP netscape.public.mozilla.nspr May 8 00:03:03 ginetta noffle[16701]: [S FLUSH] May 8 00:03:03 ginetta noffle[16701]: [R] 499 Try again later - remote server down? May 8 00:03:03 ginetta noffle[16701]: Could not change to group netscape.public.mozilla.nspr May 8 00:03:03 ginetta noffle[16701]: [S] GROUP netscape.public.mozilla.oji May 8 00:03:03 ginetta noffle[16701]: [S FLUSH] May 8 00:03:03 ginetta noffle[16701]: [R] 499 Try again later - remote server down? May 8 00:03:03 ginetta noffle[16701]: Could not change to group netscape.public.mozilla.oji May 8 00:03:03 ginetta noffle[16701]: [S] GROUP netscape.public.mozilla.unix May 8 00:03:03 ginetta noffle[16701]: [S FLUSH] May 8 00:03:10 ginetta noffle[16701]: [R] 211 1274 1 1393 netscape.public.mozilla.nspr ****!!!! Aarrgghh! That GROUP response is for netscape.public.mozilla.nspr but Noffle thinks it belongs to netscape.public.mozilla.unix. May 8 00:03:10 ginetta noffle[16701]: Reading /var/spool/noffle/overview/netscape.public.mozilla.unix May 8 00:03:10 ginetta noffle[16701]: Article number inconsistent (netscape.public.mozilla.unix rmt=1-1393, next=5902). Refetching from 1094 ****!!!! Noffle gets the wrong group info and starts an incorrect refetch. May 8 00:03:10 ginetta noffle[16701]: Preparing entry <200...@gi...> May 8 00:03:10 ginetta noffle[16701]: Store article <200...@gi...> May 8 00:03:10 ginetta noffle[16701]: Writing /var/spool/noffle/overview/netscape.public.mozilla.unix (374) May 8 00:03:10 ginetta noffle[16701]: Getting remote overviews 1094-1393 for group netscape.public.mozilla.unix May 8 00:03:10 ginetta noffle[16701]: [S] XOVER 1094-1393 May 8 00:03:10 ginetta noffle[16701]: [S FLUSH] May 8 00:03:11 ginetta noffle[16701]: [R] 211 545 1 602 netscape.public.mozilla.oji May 8 00:03:11 ginetta noffle[16701]: XOVER command failed: 211 545 1 602 netscape.public.mozilla.oji ****!!!! Another late reply causing confusion May 8 00:03:11 ginetta noffle[16701]: [S] GROUP rec.humor.funny May 8 00:03:11 ginetta noffle[16701]: [S FLUSH] May 8 00:03:11 ginetta noffle[16701]: [R] 211 5671 1 5902 netscape.public.mozilla.unix ****!!!! Here's the real reply for the GROUP netscape.public.mozilla.unix May 8 00:03:11 ginetta noffle[16701]: Reading /var/spool/noffle/overview/rec.humor.funny May 8 00:03:11 ginetta noffle[16701]: Getting remote overviews 5700-5902 for group rec.humor.funny May 8 00:03:11 ginetta noffle[16701]: [S] XOVER 5700-5902 May 8 00:03:11 ginetta noffle[16701]: [S FLUSH] May 8 00:03:11 ginetta noffle[16701]: [R] 224 data follows May 8 00:03:11 ginetta noffle[16701]: Requesting overview for remote 5700-5902 May 8 00:03:11 ginetta noffle[16701]: [R] 1094^ILinux/Optimized apprunner rendering blank^IChris McAfee <mc...@ne...>^IFri, 05 Mar 1999 01:54:56 -0800^I<36D...@ne...>^I<36D...@ui...> <36D...@ne...>^I1083^I16^I May 8 00:03:11 ginetta noffle[16701]: [R] 1095^IFYI - run-time-typing and exception handling cost on linux^I"Kipp E.B. Hickman" <ki...@ne...>^IFri, 05 Mar 1999 09:06:54 -0800^I<36E...@ne...>^I^I1354^I25^I ****!!!! And here go the overviews for netscape.public.mozilla.unix into rec.humor.funny. > Also it is a undesirable feature, that Noffle continues its fetch loop, > if the connection breaks down. > >>From the TODO file in the main CVS line: > > Later > ----- > > * Make Noffle handle a connection break-down during a fetch more gracefully. > At present it still continues to fetch articles, generating a > retrieving failed article for each article left. > > Maybe we should move this to Urgent and even fix it in the release-1-0 > branch also. Agreed on both points. If we lose the connection we MUST bail out of the fetch straight away. We should also perhaps consider making the server connection timeout a per-server configuration it. I strongly suspect this is behind the weirdness that Alberto is seeing as well. Alberto, if you look above the troublesome points in your logs do you find any 'Connection to remote server lost' messages? I'll take a look at it. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
|
From: Markus E. <me...@ma...> - 2001-05-08 19:10:46
|
On Tue, May 08, 2001 at 03:39:03PM +0100, Jim Hague wrote: > And that's just as bad - that's a line of response to a XOVER command. Article > number, subject, author, date, message-id, references, byte count, line count > and (here) Xref: header. > > Something rather nasty is going on here, and I'm at a bit of a loss to know > what at present. there was a bug in Noffle up to 1.0pre8: if the connection breaks down, the reson for failure ist the last status line from the server, which was from a different command like XOVER or GROUP. I fixed it in both CVS branches on Dec 10. Also it is a undesirable feature, that Noffle continues its fetch loop, if the connection breaks down. From the TODO file in the main CVS line: Later ----- * Make Noffle handle a connection break-down during a fetch more gracefully. At present it still continues to fetch articles, generating a retrieving failed article for each article left. Maybe we should move this to Urgent and even fix it in the release-1-0 branch also. > However, I also recently had an incident when a load of articles were dumped > into the wrong group (this, admittedly, was on the CVS main line). I wonder if I have no explanation for the articles in wrong groups. Is this another bug? Is it reproducible? See you - Markus |
|
From: Alberto M. <ama...@io...> - 2001-05-08 17:38:54
|
Hi!
On Tue, May 08, 2001 at 03:39:03PM +0100, Jim Hague wrote:
> On 07-May-2001 Alberto Mardegan wrote:
> > May 3 22:48:09 pupilla noffle[990]: Article number inconsistent
> > (free.it.citta.treviso rmt=229-249, next=798)
[...]
> So, it does look like the news server has renumbered. I find that the
> newservers I use at present have a tendency to renumber active groups
> frequently.
So, which would be the correct behaviour for noffle? I suppose it should
get the headers of messages from 229 to 249, and then download (by
message-id) only the ones it has not in the cache.
I don't know how usenet works, so maybe I'm totally wrong.
> 430 is the response when trying to retrieve an article by article ID. 423
> should be given when trying to retrieve by article number.
pupilla:~# grep '423 ' /var/log/news/news.err
Apr 3 19:36:24 pupilla noffle[471]: Retrieving of 1455 failed: 423 No Such Article In Group
Apr 4 18:54:37 pupilla noffle[1963]: Retrieving of 12 failed: 423 No Such Article In Group
I have only this, and the last mess happened less than a week ago...
> Something rather nasty is going on here, and I'm at a bit of a loss to know
> what at present.
My newsserver is probably the most used in Italy, and noone seems to
have reported such problems (which instead happen regularly to me); so I
can just suppose that the server is correct...
> However, I also recently had an incident when a load of articles were dumped
> into the wrong group (this, admittedly, was on the CVS main line). I wonder if
Yes, this happens too.
> this is something like a heavily loaded server taking too long to answer Noffle,
> Noffle times out, tries again and manages to follow replies for the first query
> to ultimate disaster....
>
> I'll try and see if I can see anything.
In the meantime, is there a "safer" version of noffle I can use? How is
the CVS branch?
--
Saluti,
Mardy
|
|
From: Markus E. <me...@ma...> - 2001-05-06 19:03:35
|
On Fri, May 04, 2001 at 07:59:59PM +0200, Alberto Mardegan wrote: > and looks like noffle doens't like that. About once per two weeks, I get > lots of errors from noffle: the warnings "Article counter inconsistent", > and then I see (if I start noffle from the console) that for most of > the messages it states "retrieving failed". Then, when I start slrn, I > see lots of old articles, some of them even in the wrong NG, some with > garbage content, and many whose header is unrelated to the body (that > is, they have been "mixed" up). This is really annoying, even if after > that things continue to go on normally (but I have to mark all articles > as read, since it's all a mess). > > Looks like that news.iol.it resets its article counter... > Is there a way to make noffle cohexist with this situation? Hello, I am not sure, what happens here. What information about the article counters is in the "Article counter inconsistent" message? It should be clear from there if the remote server has reset its article counter. What are the reasons in the "Retrieving failed" pseudo articles? Is it "423 No such article"? Also there should be more info about what Noffle tries to do and about the article counters in /var/log/news. Garbage content should not happen at all, have you tried other news clients to verify, that there is no problem with slrn involved? Until the problem is fixed, try to reduce the "max-fetch" number in /etc/noffle.conf, so that noffle does not fetch too many articles after a new subscription or an inconsistency in the article counters. See you - Markus |
65 messages has been excluded from this view by a project administrator.
