Hi：
Thanks very much.
But I think we can use listener_full instead of limit_listener if we want
wake up the listener when there’s a connection closed. Like in the
beginning of listener_accept:
if (unlikely(l->nbconn >= l->maxconn)) {
listener_full(l);
return;
}
WHY not using listener_full ?
Thanks,
zhou
在 15/11/10 下午3:30， "Willy Tarreau" <w...@1wt.eu> 写入:
>Hi,
>
>On Mon, Nov 09, 2015 at 12:46:57PM +0000, Zhou,Qingzhi wrote:
>> if (unlikely(actconn >= global.maxconn) && !(l->options &
>>LI_O_UNLIMITED)) {
>> limit_listener(l, &global_listener_queue);
>> task_schedule(global_listener_queue_task, tick_add(now_ms, 1000)); /*
>>try again in 1 second */
>> return;
>> }
>>
>> if (unlikely(p && p->feconn >= p->maxconn)) {
>> limit_listener(l, &p->listener_queue); <??????here is my question.
>> return;
>> }
>>
>> My question is why the task_schedule is not called again here? Any
>>purpose?
>> In my knowledge, if the upper limit is reached, we should re-schedule
>>the
>> task with expire time, and the listener will wake up when the task is
>>ran.
>
>No because if we're limited by the frontend itself, after we disable the
>listener, we will automatically be woken up once a connection is released
>there. It's when the global maxconn is reached that we want to reschedule
>because there are some situations where we cannot reliably detect if
>certain connections impacting global.maxconn have been released (eg:
>outgoing peers connections and Lua cosockets count here).
>
>Regards,
>Willy
>
