On 24/06/2014 12:26 p.m., Alex Rousskov wrote:
On 06/20/2014 03:04 AM, Amos Jeffries wrote:
I am playing with the idea of adding a new log file to record just the
connections handled by Squid (rather than the HTTP request/reply
transactions).
This log would include connections opened but
On 24/06/2014 4:41 p.m., Kinkie wrote:
On Tue, Jun 24, 2014 at 2:26 AM, Alex Rousskov
rouss...@measurement-factory.com wrote:
On 06/20/2014 03:04 AM, Amos Jeffries wrote:
I am playing with the idea of adding a new log file to record just the
connections handled by Squid (rather than the HTTP
On 06/24/2014 08:21 AM, Amos Jeffries wrote:
On 24/06/2014 1:44 a.m., Tsantilas Christos wrote:
On 06/23/2014 09:50 AM, Amos Jeffries wrote:
On 23/06/2014 5:43 a.m., Tsantilas Christos wrote:
in src/Notes.cc:
* replaceOrAdd iterates over the notes list twice in the event of
removals (due to
On 06/23/2014 11:00 PM, Amos Jeffries wrote:
On 24/06/2014 8:19 a.m., Alex Rousskov wrote:
On 06/23/2014 07:44 AM, Tsantilas Christos wrote:
On 06/23/2014 09:50 AM, Amos Jeffries wrote:
On 23/06/2014 5:43 a.m., Tsantilas Christos wrote:
clt_conn_id=ID
Associates the received ID with
On 06/24/2014 12:55 AM, Amos Jeffries wrote:
On 24/06/2014 4:41 p.m., Kinkie wrote:
On Tue, Jun 24, 2014 at 2:26 AM, Alex Rousskov wrote:
On 06/20/2014 03:04 AM, Amos Jeffries wrote:
The driver behind this is to help resolve a growing amount of user
queries regarding happy eyeballs idle
On 06/24/2014 12:33 AM, Amos Jeffries wrote:
On 24/06/2014 12:26 p.m., Alex Rousskov wrote:
On 06/20/2014 03:04 AM, Amos Jeffries wrote:
I am playing with the idea of adding a new log file to record just the
connections handled by Squid (rather than the HTTP request/reply
transactions).
On 06/23/2014 11:58 PM, Amos Jeffries wrote:
On 24/06/2014 4:07 p.m., Alex Rousskov wrote:
* Do not abandon writing a collapsed cache entry when we cannot cache
the entry in RAM if the entry can be cached on disk instead. Both shared
memory cache and the disk cache have to refuse to cache the
We can't know except by hammering it.
Did you run coadvisor and polygraph against it?
If not, and if the branch is public, it's trivial tor un them against
it now (thanks TMF, thanks Pavel!). It doesn't guarantee to catch all
cases, but at least it should raise confidence.
On Tue, Jun 24, 2014 at
On 06/24/2014 12:55 PM, Kinkie wrote:
Did you run coadvisor and polygraph against it?
Co-Advisor does not have collapsed forwarding cases (there are no
explicit RFC 2616 MUSTs that cover CF although some cases can be
certainly added to test some MUSTs in a CF context).
Polygraph can be used
Amos already +1-ed the patch, I have no insights to add so unless
someone speaks up real fast, we proceed.
On Tue, Jun 24, 2014 at 9:29 PM, Alex Rousskov
rouss...@measurement-factory.com wrote:
On 06/24/2014 12:55 PM, Kinkie wrote:
Did you run coadvisor and polygraph against it?
Co-Advisor
On 04/29/2014 05:29 AM, Amos Jeffries wrote:
+1. All good apart form one minor nit:
src/tests/stub_store.cc
* the new checkCacheable() needs to be STUB_RETVAL(false).
That can be added on merge.
Finally merged as trunk r13475.
Please note that another, unaudited fix for a frequent
On 06/24/2014 01:44 PM, Kinkie wrote:
Amos already +1-ed the patch, I have no insights to add so unless
someone speaks up real fast, we proceed.
Committed to trunk as r13476 and r13477.
Thank you,
Alex.
On Tue, Jun 24, 2014 at 9:29 PM, Alex Rousskov
rouss...@measurement-factory.com
12 matches
Mail list logo
