cancelling requests due to max_request_time
Frank Cusack
fcusack at fcusack.com
Tue Jan 16 01:16:33 CET 2007
On January 15, 2007 1:04:05 PM -0800 Frank Cusack <fcusack at fcusack.com>
wrote:
...
> That's good, but doesn't help, pthread_cancel() is still called
> for unresponsive threads. I just noticed this in radiusd.conf:
>
> # delete_blocked_requests: If the request takes MORE THAN
> 'max_request_time'
> # to be handled, then maybe the server should delete it.
> #
> # If you're running in threaded, or thread pool mode, this setting
> # should probably be 'no'. Setting it to 'yes' when using a threaded
> # server MAY cause the server to crash!
> #
> delete_blocked_requests = no
>
> Is that right? There are bugs there (besides pthread_cancel())? I see
> that if delete_block_requests is no, pthread_cancel() doesn't get
> called and instead STOP_NOW is set, so that looks good since usu. a
> request would be blocked on I/O, not compute, so waiting for a module
> to complete some I/O shouldn't be an issue.
...
> I would suggest simply removing the delete_blocked_requests option
> (always use "no"). The STOP_NOW flag looks good enuf.
Thought more about this. Maybe a global cancel handler which calls
into a new .cancel method of each module. If the module doesn't have
this function it won't be cancelable. Hey I like that a lot.
Just need to ensure delete_blocked_requests isn't actually buggy.
-frank
More information about the Freeradius-Devel
mailing list