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