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