You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Allan Edwards <ak...@raleigh.ibm.com> on 2000/06/20 19:23:18 UTC
default timeout values
Anyone know what the reason was for upping the
values of DEFAULT_KEEPALIVE_TIMEOUT from 15 to
300 and DEFAULT_TIMEOUT from 300 to 120000 in
httpd.h last August? I couldn't find any discussion
in the new-httpd archives. If this is intentional
then the docs need updating.
Incidentally, this DEFAULT_TIMEOUT causes unix_setopt()
(win32_setopt)to overflow the value of 'ap_int32_t on'
that is passed to ap_setsocketopt when setting timeout.
To fix, either:
a) use ap_setsocketopt( ap_socket_t *sock,
ap_int32_t opt,
ap_int64_t on);
b) pass the value in seconds rather that microseconds.
I think I prefer b)
Allan
)
Re: default timeout values
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
+1 on Ryan's reply.
>
> > > Let's just store in seconds and do the conversion in setopt. This
> > > probably makes more sense in the long run. Plus, people are used to
> > > seeing things in seconds, not usecs.
> > >
> >
> > This is getting ugly fast. If we are going to store timeouts
> > in microseconds then we also have to fix things like
> > ap_interval_time_t (which is ap_int32_t) in ap_socket_t.
>
> I guess I am confused here. Didn't we say that we would store values in
> seconds within Apache, and convert to usecs for APR? Yes, APR will need
> to store things in usecs.
>
> > Also, ap_set_pipe_timeout, ap_sleep, ap_poll have the same
> > potential overflow problem and will need fixing unless we
> > decide to limit time intervals to < 30mins.
>
> I don't think limiting to < 30 mins is a bad thing. We are talking about
> APR. Although APR's design should allow it to work for any type of
> program, the fact is that the current version is really being designed for
> servers. If there are any servers out there that need to set timeouts for
> > 30 mins, and they want to use APR v1.0, they may need to play some
> games. I don't think that is a bad thing.
>
> > Are people likely to want to make Timout & KeepaliveTimeout
> > greater that 30 mins?? (that's an Apache question). The more
> > significant question however is whether APR users in general
> > would want to live with that restriction - almost certainly not.
> >
> > Looks like we need to redefine ap_interval_time_t to ap_int64_t
> > unless you want to recant and standardize on seconds??
>
> We do not want to standardize in seconds. If you look back to what Dean
> did with the time stuff, the time_t is in usecs for a reason, it makes
> sense. He used a 64-bit integer for the ap_time_t type. We took the idea
> for our timing code from NSPR, and they used a 32-bit value for interval
> times. The limit to < 35 mins was actually brought up before we made this
> change.
>
> I personally say leave the interval times at 32-bits. If this becomes an
> issue later, we can easily change the type to a 64-bit value in version 2
> or 3 of APR.
>
> Ryan
RE: default timeout values
Posted by rb...@covalent.net.
> > Let's just store in seconds and do the conversion in setopt. This
> > probably makes more sense in the long run. Plus, people are used to
> > seeing things in seconds, not usecs.
> >
>
> This is getting ugly fast. If we are going to store timeouts
> in microseconds then we also have to fix things like
> ap_interval_time_t (which is ap_int32_t) in ap_socket_t.
I guess I am confused here. Didn't we say that we would store values in
seconds within Apache, and convert to usecs for APR? Yes, APR will need
to store things in usecs.
> Also, ap_set_pipe_timeout, ap_sleep, ap_poll have the same
> potential overflow problem and will need fixing unless we
> decide to limit time intervals to < 30mins.
I don't think limiting to < 30 mins is a bad thing. We are talking about
APR. Although APR's design should allow it to work for any type of
program, the fact is that the current version is really being designed for
servers. If there are any servers out there that need to set timeouts for
> 30 mins, and they want to use APR v1.0, they may need to play some
games. I don't think that is a bad thing.
> Are people likely to want to make Timout & KeepaliveTimeout
> greater that 30 mins?? (that's an Apache question). The more
> significant question however is whether APR users in general
> would want to live with that restriction - almost certainly not.
>
> Looks like we need to redefine ap_interval_time_t to ap_int64_t
> unless you want to recant and standardize on seconds??
We do not want to standardize in seconds. If you look back to what Dean
did with the time stuff, the time_t is in usecs for a reason, it makes
sense. He used a 64-bit integer for the ap_time_t type. We took the idea
for our timing code from NSPR, and they used a 32-bit value for interval
times. The limit to < 35 mins was actually brought up before we made this
change.
I personally say leave the interval times at 32-bits. If this becomes an
issue later, we can easily change the type to a 64-bit value in version 2
or 3 of APR.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: default timeout values
Posted by rb...@covalent.net.
> > > Comments on changing this type name for clarity? (I just propose
> > > delta instead of interval since it's a shorter word, that's all.)
> >
> > I really don't think this helps clarity any, sorry. :-} I also don't
> > mind replying to messages on the list with:
> >
> > "This topic has been discussed before, please see the archives for Jun
> > 2000, and search for interval_time."
>
> Fair enough, but I'd suggest that if 3 coders notice this 'bug' (we are
> up to two already), that we have a doc problem or clarity problem. Let's
> not waste everyone's time unwinding the same restriction.
You're right. Let's just document it in the header file. :-)
> > I really think we are fine the way things are now. If we want room to
> > grow into the future, I think we can just change the def of
> > ap_interval_time_t. All this requires is a recompile to move
> > from 32 -> 64 bit values.
>
> Here I disagree. 32 bits is a good thing for optimization, IMHO. If we
> ever did extend to hours or days, that would and should be a different
> type. Declaring it now tells the new coder to APR that we did think
> this through, and these functions are all in short time intervals.
How about we put this option in the comment too, and delay this discussion
until it is really necessary. Who knows, by the time this is necessary,
we could all be on 64-bit machines. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: default timeout values
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Friday, June 23, 2000 12:52 PM
>
> > +1 on Ryan's reply and design to use usecs.
> >
> > Now, I have a -new- proposal that we adopt:
> >
> > ap_time_short_delta_t
> >
> > Comments on changing this type name for clarity? (I just propose
> > delta instead of interval since it's a shorter word, that's all.)
>
> I really don't think this helps clarity any, sorry. :-} I also don't
> mind replying to messages on the list with:
>
> "This topic has been discussed before, please see the archives for Jun
> 2000, and search for interval_time."
Fair enough, but I'd suggest that if 3 coders notice this 'bug' (we are
up to two already), that we have a doc problem or clarity problem. Let's
not waste everyone's time unwinding the same restriction.
> I really think we are fine the way things are now. If we want room to
> grow into the future, I think we can just change the def of
> ap_interval_time_t. All this requires is a recompile to move
> from 32 -> 64 bit values.
Here I disagree. 32 bits is a good thing for optimization, IMHO. If we
ever did extend to hours or days, that would and should be a different
type. Declaring it now tells the new coder to APR that we did think
this through, and these functions are all in short time intervals.
Bill
RE: default timeout values
Posted by rb...@covalent.net.
> +1 on Ryan's reply and design to use usecs.
>
> Now, I have a -new- proposal that we adopt:
>
> ap_time_short_delta_t
>
> (3 characters longer than ap_time_interval_t) to replace that type,
> and offer ap_time_long_delta_t as an int64 type for future growth.
>
> This will resolve the issue that each coder in APR 'discovers' this
> issue on their own and it reemerges on the list every two months.
> I am -not- proposing any functions to accept ap_time_long_delta_t,
> since Apache Server has no requirements to play long time games. In
> file and connection timeouts we will (probably) never need it. The
> compare times patch I wrote some time ago gracefully set >35 min to
> 35 min and <-35 min to -35 min, so that solved that issue.
>
> Comments on changing this type name for clarity? (I just propose
> delta instead of interval since it's a shorter word, that's all.)
I really don't think this helps clarity any, sorry. :-} I also don't
mind replying to messages on the list with:
"This topic has been discussed before, please see the archives for Jun
2000, and search for interval_time."
I really think we are fine the way things are now. If we want room to
grow into the future, I think we can just change the def of
ap_interval_time_t. All this requires is a recompile to move from 23 ->
64 bit values.
Ryan
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: default timeout values
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
+1 on Ryan's reply and design to use usecs.
Now, I have a -new- proposal that we adopt:
ap_time_short_delta_t
(3 characters longer than ap_time_interval_t) to replace that type,
and offer ap_time_long_delta_t as an int64 type for future growth.
This will resolve the issue that each coder in APR 'discovers' this
issue on their own and it reemerges on the list every two months.
I am -not- proposing any functions to accept ap_time_long_delta_t,
since Apache Server has no requirements to play long time games. In
file and connection timeouts we will (probably) never need it. The
compare times patch I wrote some time ago gracefully set >35 min to
35 min and <-35 min to -35 min, so that solved that issue.
Comments on changing this type name for clarity? (I just propose
delta instead of interval since it's a shorter word, that's all.)
Bill
> -----Original Message-----
> From: Bill Stoddard [mailto:stoddard@raleigh.ibm.com]
> Sent: Friday, June 23, 2000 9:23 AM
> To: new-httpd@apache.org
> Subject: Re: default timeout values
>
>
> > > If we're hard & fast on the decision to use usec then
> > > either we go with ap_int64_t everywhere, or duplicate long &
> > > short versions of certain calls (we can probably get away with
> > > just the short versions for Apache).
> >
> > We are hard and fast on the decision to use usecs. And the
> 35 minute
> > limit is not a big deal. I do not believe we need both
> long and short
> > versions of these functions, yet. Apache just cares about the short
> > version, and APR v1 is being written for Apache.
> >
> > Ryan
>
> Agree on decision to use usecs.
>
Re: default timeout values
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
> > If we're hard & fast on the decision to use usec then
> > either we go with ap_int64_t everywhere, or duplicate long &
> > short versions of certain calls (we can probably get away with
> > just the short versions for Apache).
>
> We are hard and fast on the decision to use usecs. And the 35 minute
> limit is not a big deal. I do not believe we need both long and short
> versions of these functions, yet. Apache just cares about the short
> version, and APR v1 is being written for Apache.
>
> Ryan
Agree on decision to use usecs.
RE: default timeout values
Posted by rb...@covalent.net.
> If we're hard & fast on the decision to use usec then
> either we go with ap_int64_t everywhere, or duplicate long &
> short versions of certain calls (we can probably get away with
> just the short versions for Apache).
We are hard and fast on the decision to use usecs. And the 35 minute
limit is not a big deal. I do not believe we need both long and short
versions of these functions, yet. Apache just cares about the short
version, and APR v1 is being written for Apache.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: default timeout values
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Allan Edwards [mailto:ake@raleigh.ibm.com]
> Sent: Thursday, June 22, 2000 11:03 PM
>
> > > Yes, this exact option crosed my mind also. However, it boils
> > > down to a
> > > question of complexity and, to some extent,
> performance(multiplying
> > > and dividing by 1M when converting to/from native unix types).
> >
> > If you are concerned about performance, then I strongly suggest we
> > adopt an APR_TICKS_PER_SEC that is native to the OS. Unix can play
> > with seconds. We'll play with 100ns units over here on NT.
>
> I don't get your point. My point is if, for example, sockopt uses int
> to specify some unit, why not have ap_setsocketopt do the
> same (assuming we have fairly uniform mappings across platforms).
Then we assume the coder is mapping correctly between ap_this() and
ap_that(), which I don't care for. Take the smallest common denominator
between system file stamps, system clock resolution and timeouts, and
that should be it. I just don't know that it's worth it to have the
platform specific bugs we once fought - at least now we are dealing in
a common denominator. The smallest significant time in tcp/ip coding
is probably 10ms, so 1ms increments is great for Apache..
RE: default timeout values
Posted by rb...@covalent.net.
> > If you are concerned about performance, then I strongly suggest we
> > adopt an APR_TICKS_PER_SEC that is native to the OS. Unix can play
> > with seconds. We'll play with 100ns units over here on NT.
>
> I don't get your point. My point is if, for example, sockopt uses int
> to specify some unit, why not have ap_setsocketopt do the same (assuming
> we have fairly uniform mappings across platforms).
ap_setsocketopt uses microseconds for all time values. In fact, APR uses
usecs throughout for all time values. If you find a piece of code that
doesn't, that is a bug. Please change it to use usecs. The reason for
these bugs is that APR started out using secs not usecs.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: default timeout values
Posted by Allan Edwards <ak...@raleigh.ibm.com>.
> > Yes, this exact option crosed my mind also. However, it boils
> > down to a
> > question of complexity and, to some extent, performance(multiplying
> > and dividing by 1M when converting to/from native unix types).
>
> Ok... stop there.
>
> If you are concerned about performance, then I strongly suggest we
> adopt an APR_TICKS_PER_SEC that is native to the OS. Unix can play
> with seconds. We'll play with 100ns units over here on NT.
I don't get your point. My point is if, for example, sockopt uses int
to specify some unit, why not have ap_setsocketopt do the same (assuming
we have fairly uniform mappings across platforms).
gotta go for today...
> But I think the inherent complexity is overkill. Integer mult/div
> is fast enough now that I think it's probably mute. But let's
> ask the experts... is Dean in the house?
RE: default timeout values
Posted by rb...@covalent.net.
> > > I shared your sentiment months ago, until I considered that 90%
> > > of our applications are 35 minutes or less. I'd suggest something
> > > less dramatic, two types:
> > >
> > > ap_short_interval_t
> > > ap_long_interval_t
> >
> > Yes, this exact option crosed my mind also. However, it boils
> > down to a
> > question of complexity and, to some extent, performance(multiplying
> > and dividing by 1M when converting to/from native unix types).
>
> Ok... stop there.
>
> If you are concerned about performance, then I strongly suggest we
> adopt an APR_TICKS_PER_SEC that is native to the OS. Unix can play
> with seconds. We'll play with 100ns units over here on NT.
>
> But I think the inherent complexity is overkill. Integer mult/div
> is fast enough now that I think it's probably mute. But let's
> ask the experts... is Dean in the house?
This is actually what NSPR did, so we have officially gone full
circle. Since Dean is probably the biggest fan of NSPR on this list, I
know that he knows NSPR did this. The fact that he made the concious
decision to not go this complex with APR should say something.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: default timeout values
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Allan Edwards [mailto:ake@raleigh.ibm.com]
> Sent: Thursday, June 22, 2000 10:15 PM
>
> > I shared your sentiment months ago, until I considered that 90%
> > of our applications are 35 minutes or less. I'd suggest something
> > less dramatic, two types:
> >
> > ap_short_interval_t
> > ap_long_interval_t
>
> Yes, this exact option crosed my mind also. However, it boils
> down to a
> question of complexity and, to some extent, performance(multiplying
> and dividing by 1M when converting to/from native unix types).
Ok... stop there.
If you are concerned about performance, then I strongly suggest we
adopt an APR_TICKS_PER_SEC that is native to the OS. Unix can play
with seconds. We'll play with 100ns units over here on NT.
But I think the inherent complexity is overkill. Integer mult/div
is fast enough now that I think it's probably mute. But let's
ask the experts... is Dean in the house?
RE: default timeout values
Posted by Allan Edwards <ak...@raleigh.ibm.com>.
> > Looks like we need to redefine ap_interval_time_t to ap_int64_t
> > unless you want to recant and standardize on seconds??
>
> Never retreat :)
>
> I shared your sentiment months ago, until I considered that 90%
> of our applications are 35 minutes or less. I'd suggest something
> less dramatic, two types:
>
> ap_short_interval_t
> ap_long_interval_t
Yes, this exact option crosed my mind also. However, it boils down to a
question of complexity and, to some extent, performance(multiplying
and dividing by 1M when converting to/from native unix types).
Standardizing everywhere with microseconds to some extent simplifies
life for the APR user - no need to think 'what are the time units
for this API call'. However if the alternative is having duplicates
of each call that uses time interval I'm not sure that is achieving
the desired goal.
If we're hard & fast on the decision to use usec then
either we go with ap_int64_t everywhere, or duplicate long &
short versions of certain calls (we can probably get away with
just the short versions for Apache).
Otherwise we need to look at each of the calls in detail and the
underlying native types used to determine what makes best sense.
Personally I think it's worth looking into.
Allan
RE: default timeout values
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> > Let's just store in seconds and do the conversion in setopt. This
> > probably makes more sense in the long run. Plus, people are used to
> > seeing things in seconds, not usecs.
> >
>
> This is getting ugly fast. If we are going to store timeouts
> in microseconds then we also have to fix things like
> ap_interval_time_t (which is ap_int32_t) in ap_socket_t.
>
> Also, ap_set_pipe_timeout, ap_sleep, ap_poll have the same
> potential overflow problem and will need fixing unless we
> decide to limit time intervals to < 30mins.
>
> Are people likely to want to make Timout & KeepaliveTimeout
> greater that 30 mins?? (that's an Apache question). The more
> significant question however is whether APR users in general
> would want to live with that restriction - almost certainly not.
>
> Looks like we need to redefine ap_interval_time_t to ap_int64_t
> unless you want to recant and standardize on seconds??
Never retreat :)
I shared your sentiment months ago, until I considered that 90%
of our applications are 35 minutes or less. I'd suggest something
less dramatic, two types:
ap_short_interval_t
ap_long_interval_t
Meaning, respectively, +-35 min, or several milleneia, at the
programmers choice. Have two implementations of ap_time_diff()
or whatever, one short, one long. Nearly every APR function
needs to deal in minutes, not days. For httpd and other users,
provide both types.
RE: default timeout values
Posted by Allan Edwards <ak...@raleigh.ibm.com>.
> Let's just store in seconds and do the conversion in setopt. This
> probably makes more sense in the long run. Plus, people are used to
> seeing things in seconds, not usecs.
>
This is getting ugly fast. If we are going to store timeouts
in microseconds then we also have to fix things like
ap_interval_time_t (which is ap_int32_t) in ap_socket_t.
Also, ap_set_pipe_timeout, ap_sleep, ap_poll have the same
potential overflow problem and will need fixing unless we
decide to limit time intervals to < 30mins.
Are people likely to want to make Timout & KeepaliveTimeout
greater that 30 mins?? (that's an Apache question). The more
significant question however is whether APR users in general
would want to live with that restriction - almost certainly not.
Looks like we need to redefine ap_interval_time_t to ap_int64_t
unless you want to recant and standardize on seconds??
Allan
RE: default timeout values
Posted by rb...@covalent.net.
> > We changed from seconds to microseconds. The math seems
> > really screwy to
> > me though.
>
> The way it is right now, the code assumes timeout
> directives are in seconds and stores them that way in
> server_rec keep_alive_timeout/timeout. The conversion
> to microseconds is done in unix_setopt/win32_setopt.
>
> So.... do we want to keep storing timeout and
> keep_alive_timeout values in seconds or change them to
> microseconds?
>
> If we change to storing microseconds, the int's in server_rec
> will need to be changed to ap_int64_t and MMN bumped.
>
> Either way DEFAULT_TIMEOUT/KEEPALIVE_TIMEOUT needs fixing.
Let's just store in seconds and do the conversion in setopt. This
probably makes more sense in the long run. Plus, people are used to
seeing things in seconds, not usecs.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: default timeout values
Posted by Allan Edwards <ak...@raleigh.ibm.com>.
>
> We changed from seconds to microseconds. The math seems
> really screwy to
> me though.
The way it is right now, the code assumes timeout
directives are in seconds and stores them that way in
server_rec keep_alive_timeout/timeout. The conversion
to microseconds is done in unix_setopt/win32_setopt.
So.... do we want to keep storing timeout and
keep_alive_timeout values in seconds or change them to
microseconds?
If we change to storing microseconds, the int's in server_rec
will need to be changed to ap_int64_t and MMN bumped.
Either way DEFAULT_TIMEOUT/KEEPALIVE_TIMEOUT needs fixing.
Allan
Re: default timeout values
Posted by rb...@covalent.net.
> Anyone know what the reason was for upping the
> values of DEFAULT_KEEPALIVE_TIMEOUT from 15 to
> 300 and DEFAULT_TIMEOUT from 300 to 120000 in
> httpd.h last August? I couldn't find any discussion
> in the new-httpd archives. If this is intentional
> then the docs need updating.
We changed from seconds to microseconds. The math seems really screwy to
me though.
> Incidentally, this DEFAULT_TIMEOUT causes unix_setopt()
> (win32_setopt)to overflow the value of 'ap_int32_t on'
> that is passed to ap_setsocketopt when setting timeout.
> To fix, either:
>
> a) use ap_setsocketopt( ap_socket_t *sock,
> ap_int32_t opt,
> ap_int64_t on);
>
> b) pass the value in seconds rather that microseconds.
Everything is done in microseconds now. IMNSHO, the proper approach is
to use a.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------