Without the change to ensure that valuePortion is nonnegative, duration
might become negative, which it's not allowed to be. Without this
change, this can happen when a transition starts off moving into
negative value space, which happens when y1 in the timing function is
negative. The result that we want should come from using the absolute
value (rather than clamping to zero): if we reverse the transition when
it's in this negative space, we want the same movement we'd get if it
were the same distance into positive value space, just in the opposite
direction.
Additionally, I'm clamping valuePortion to be at most 1. This affects
"bouncy" transitions where the timing function's y2 is greater than
one. This is less critical, but ensures the invariant that a transition
will never take longer than its specified time, which seems like a good
thing to ensure.
I believe doing this computation at this stage is preferable to doing it
before the multiplication by oldPT.mReversePortion, since we should be
clamping the value within the range of the complete transition, not just
relative to the most recent reverse.
Bug 614677 - Connection is reset message appears intermittently
Bug 614950 - Connections stall occasionally after 592284 landed
A couple of follow-on changes to 592284 rolled together to prevent
diff conflicts
1] Set the securitycallback information for unused speculative
connections in the connection manager to be the new cloned connection
rather than the one they originated on. (613977)
2] When adding unused speculative connections to the connection
manager, due so with a short timeout (<= 5 seconds) as some servers
get grumpy if they haven't seen a request in that time. Most will
close the connection, but some will just sit there quietly and RST
things when the connection is used - so if you don't use the
connection quickly don't use it at all. This is probably a L4 load
balancer issue, actually. Mozillazine illustrates the
problem. Connections are made in bursts anyhow, so the reuse optimization is
likely still quite useful. (614677 and 614950)
3] mark every connection in the connection manager persistent
conneciton pool as "reused". This allows the transaction to be
restarted if a RST is recvd upon sending the requests (see #2) - with
the conservative timeout this is now a rare event, but still possible
so recovery is the right thing to do. (614677 and 614950)
4] obtain an nshttpconnection object from the connection manager,
subject to the max connection constraints, at the same time as
starting the backup conneciton. If we defer that until recycling time
the exceeded limits of the SocketService can cause problems for other
connections.
also re-enables the syn retry feature by default.
r+ honzab
