> I think this is intentional, but there are probably cases where you
> would want wait_xact_lmt to behave differently. The original design
> had a simple goal: prevent memory exhaustion by dropping requests when
> the queue gets too long. Under that design, we wanted to get back to
> configured request rate as soon as possible. Thus, we left extra
> launch level unchanged so that the traffic on the wire picks up to the
> configured level as soon as the queue is drained (e.g., when excessive
> queuing was caused by a temporary problem).
>
> Would you like wait_xact_lmt to do something else instead?
I see. What I am doing is using wait_xact_lmt to approximate what might
happen if the network is too slow to keep up with the specified request
rate. So the robot would adapt its load to the network capacity by
dropping requests when the network can't keep up. It's not obvious to me
whether or not the dropped embedded object requests should be counted
against the target request rate.
-- public key: finger mukesh@cs.cmu.edu fingerprint: BDAB AB7A ADFB 9229 1BD8 45FD BE21 850C E36C D4AA
This archive was generated by hypermail 2b29 : Mon Feb 06 2006 - 12:00:22 MST