~ubuntu-branches/ubuntu/maverick/postfix/maverick-security

feedback algorithm are a) the option of less-than-1 positive feedback

per delivery to avoid overwhelming servers, b) the option of

less-than-1 negative feedback per delivery to avoid giving up too

"reverse" hysteresis cycle for negative feedback, so that it can

correct for overload quickly.  </p>

 

                concurrency = 1

</pre>

 

 

<p> Discussions about the concurrency scheduler redesign started

early 2004, when the primary goal was to find alternatives that did

 

<h4> Impact of active server concurrency limiter </h4>

 

SMTP connections don't time out, but are rejected immediately with

the Postfix server's <a href="postconf.5.html#smtpd_client_connection_count_limit">smtpd_client_connection_count_limit</a> feature

(the server replies with a 421 status and disconnects immediately).

 

</blockquote>

 

 

<p> All results in the previous sections are based on the first

delivery runs only; they do not include any second etc. delivery

or handshake failure </td> </tr>

 

<tr> <td> <a href="postconf.5.html#default_destination_concurrency_negative_feedback">default_destination_concurrency_negative_feedback</a><br>

<td align="center"> 2.5<br> 2.5 </td> <td> Per-destination negative

feedback amount, per delivery that fails with connection or handshake

failure </td> </tr>

up the message </a> - how it is assigned to transports, jobs, peers,

entries

 

 

are chosen to preempt them

 

<li> <a href="#<tt>nqmgr</tt>_concurrency"> How destination concurrency

 

</p>

 

 

<p>

 

 

</p>

 

 

<p>

 

by default. This is the k from the paragraph above. Each time k

entries of the job are selected for delivery, this counter is

incremented by one. Once there are some slots accumulated, job which

can preempt this job.

 

</p>

(remember a job can be preempted several times). In either case,

we know how many are accumulated and how many are left to deliver,

so we know how many it may yet accumulate at maximum. Every other

valid candidate for preemption. How do we choose among them?

 

</p>

 

Now let's recap the previous two paragraphs. Isn't it too complicated?

Why don't the candidates come only among the jobs which can be

accumulated? Why do we need to estimate how much it has yet to

accumulate? If you found out the answer, congratulate yourself. If

we did it this simple way, we would always choose the candidate

<a href="postconf.5.html#default_delivery_slot_discount">default_delivery_slot_discount</a> and <a href="postconf.5.html#default_delivery_slot_loan">default_delivery_slot_loan</a>, whose

values are by default 50 and 3, respectively). The discount (resp.

loan) specifies how many percent (resp. how many slots) one "gets

accumulated so far.

 

</p>