Re: [htdig3-dev] Transport code broken

Subject: Re: [htdig3-dev] Transport code broken
From: Geoff Hutchison (
Date: Fri Feb 11 2000 - 06:13:31 PST

At 10:29 AM +0100 2/11/00, Gabriele Bartolini wrote:
> >So I'd set the default to 1. This is probably what it should be anyway,
> >but the code should be setting retry_value to a nonzero value elsewhere.
>Can you explain me how retry_value works? It's different, I suppose, from
>the "max_retries" configuration value and it's not tied with it, I guess.
>As far as I am concerned, I think we manage the number of retries on a
>higher level (that is to say on the code that wants to retry for a
>document, isn't it?).

>If we use "max_retries" probably "retry_value" is a logical duplication and
>so it's unuseful (I think it should alway be always 1 ...). But probably, I
>repeat, I need more explanations about this.

The retry_value was a suggestion from a user--he was often getting
error values from the socket code that the socket was unavailable.
It's supposed to be tied to the max_retry attribute, but somehow that
code wasn't committed.

I'm not sure we don't want *both* types of retries. I can see why you
might want a retry down at the bottom--if there's a slight problem it
will quickly try again. The higher-level retry is fine, but it has to
go through a bit more before it does a retry. Of course the
higher-level retry will fix problems if, say Apache is swamped and
the HTTP request is rejected, while the lower-level one can't.

It's obviously open for suggestion. I like the lower-level retry in
there--I think it will help performance on busy servers.

>Anyway, the actual code seems to work ... even if I don't know why
>"timeout" value is not always respected. We need to go over the Connection
>code, but I don't think to be very keen on it !!! (can I use this
>expression??? - to be keen on ...)

If timeout isn't respected now, then the Connection code needs a very
careful examination. Another bug report found that the connect()
library call did not have any sort of alarm() set to make it timeout.
Granted, it should have been set through other means, but this was a
good suggestion--the alarm will be respected no matter what.

So to reiterate--if it doesn't work now, speak up.


To unsubscribe from the htdig3-dev mailing list, send a message to
You will receive a message to confirm this.

This archive was generated by hypermail 2b28 : Fri Feb 11 2000 - 06:24:22 PST