nnrpd issue

Alex Kiernan alexk at demon.net
Wed Jan 22 16:18:16 UTC 2003


Katsuhiro Kondou <Katsuhiro_Kondou at isc.org> writes:

> In article <72d6mqhapa.fsf at demon.net>,
> 	Alex Kiernan <alexk at demon.net> wrote;
> 
> } But I think the problem was later in the day with large CNFS buffers.
> 
> True.
> 
> } > } behaviour as before (i.e. the slow scan). Dropping in an if () {...} 
> } > } else {...} somewhere should help I think.
> 
> I gave it my thought on the problem for a while.  I
> think it's necessary to query article existence even
> if nnrpdcheckart is set to false to resolve the issue.
> It'd be done by verifying after OVsearch() in my patch.
> It will be continued until SMretrieve(RETR_STAT) returns
> true.  It should be fixed for cnfs.  As to tradspool,
> HISgetent() could be used instead of SMretrieve(), and
> this should minimize the response time for that storage
> method.  Any comments?

I guess thats really the question - should NEXT return the next
article which is really available or just the next from the overview
database.

-- 
Alex Kiernan, Principal Engineer, Development, THUS plc


More information about the inn-workers mailing list