mån 2012-12-03 klockan 22:25 -0700 skrev Alex Rousskov:
I disagree with this logic. Yes, sawActivity approach supports long
chains, but they are not the loop's fault! If some chain is too long,
the bug is in that chain's code and should be fixed there. If it cannot
be fixed there, then the
mån 2012-12-03 klockan 23:12 -0700 skrev Alex Rousskov:
BTW, once zero-delay events are removed from the code, the event queue
will no longer need to be a part of the wasActivity loop and the loop
will disappear.
Note: Legacy zero-delay addEvent events are meant to be called once per
comm
OK after long tests StoreID works for both mem and UFS store.
I solved and marked all mismatching tests and for now it seems to work
perfectrly:
The scenario I have been using is .ytimg.com domain.
It hosts many jpg pictures on different CDN's.
the examples are:
Hi all,
I think I found a bug in the current helpers response parsing code: One
byte remains in helpers io buffer after parsing the response. This is
will cause problems when the next response from helper will enter squid.
The bug exist in helperHandleRead and helperReturnBuffer functions exist
If there is not objections I will apply the latest SSL server
certificate fingerprint ACL type patch
(certificate-fingerprint-ACL-v3.patch) to trunk
On 11/24/2012 05:47 PM, Tsantilas Christos wrote:
On 11/23/2012 01:49 PM, Amos Jeffries wrote:
On 15/11/2012 1:12 a.m., Tsantilas Christos wrote:
On 12/04/2012 01:47 AM, Henrik Nordström wrote:
mån 2012-12-03 klockan 22:25 -0700 skrev Alex Rousskov:
I disagree with this logic. Yes, sawActivity approach supports long
chains, but they are not the loop's fault! If some chain is too long,
the bug is in that chain's code and should be
On 12/04/2012 01:59 AM, Henrik Nordström wrote:
mån 2012-12-03 klockan 23:12 -0700 skrev Alex Rousskov:
BTW, once zero-delay events are removed from the code, the event queue
will no longer need to be a part of the wasActivity loop and the loop
will disappear.
Note: Legacy zero-delay
On 12/01/2012 06:02 PM, Alex Rousskov wrote:
To summarize, our choices for a pinned connection created for the
current client are:
Before sending the request:
1. Reopen and repin used pconns to send unretriable requests,
just like non-pinned connection code does. This eliminates
tis 2012-12-04 klockan 08:39 -0700 skrev Alex Rousskov:
heavy events in the context of addEvent events are really this is very
heavy, and there is only allowed to be one and only one heavy event per
comm invocation. If there is multiple heavy jobs competing for time they
are meant to get
tis 2012-12-04 klockan 08:39 -0700 skrev Alex Rousskov:
There are several ways to interpret the designer intent when looking at
undocumented code. I cannot say whether all of the currently remaining
zero-delay events use your interpretation, but I am certain that I have
added zero-delay
On 05.12.2012 03:24, Tsantilas Christos wrote:
Hi all,
I think I found a bug in the current helpers response parsing code:
One
byte remains in helpers io buffer after parsing the response. This is
will cause problems when the next response from helper will enter
squid.
The bug exist in
On 05.12.2012 02:45, Eliezer Croitoru wrote:
snip
The helper code for now Is too much for me and I will get back to it
when later Amos will have more time and This part of the patch will
be
ready steady and documented.
Christos found a bug which I expect is causing the Unknown. Please
try
12 matches
Mail list logo
