On 6/09/2012 11:00 p.m., Eliezer Croitoru wrote:
I had a *smalll* issue with my storage so I'm forced to start from
almost scratch.
I previously worked on the 3.2.1 latest stable sources and I am
wondering on where to start now?
start on head? stable?
Eliezer
3.HEAD please.
Amos
On 8/09/2012 3:54 p.m., Alex Rousskov wrote:
Hello,
I came upon a Squid proxy configured with "cache_peer ssl" (i.e.,
peer->use_ssl is true). The proxy forwards GETs to the peer using an SSL
connection because forward.cc code knows that "SSL peers" need an SSL
connection and establishes suc
Hello,
I came upon a Squid proxy configured with "cache_peer ssl" (i.e.,
peer->use_ssl is true). The proxy forwards GETs to the peer using an SSL
connection because forward.cc code knows that "SSL peers" need an SSL
connection and establishes such a connection. This works well.
However, when
On 8/09/2012 3:17 a.m., Alex Rousskov wrote:
On 09/07/2012 08:33 AM, Alexander Komyagin wrote:
On Fri, 2012-09-07 at 08:15 -0600, Alex Rousskov wrote:
On 09/07/2012 02:32 AM, Alexander Komyagin wrote:
However, as I stated earlier, the comm.cc problem (actually semantics
problem) persists. I th
On 8/09/2012 7:38 a.m., Eliezer Croitoru wrote:
On 09/07/2012 05:10 PM, Alex Rousskov wrote:
I am not sure what "option" you are referring to in the above. The
Store::get(key) API I have described is not optional -- it is the
primary way of detecting a hit.
+1 to use the api.
are we t
On 09/07/2012 01:32 PM, Eliezer Croitoru wrote:
> On 09/07/2012 05:10 PM, Alex Rousskov wrote:
>
> I am not sure what "option" you are referring to in the above. The
> Store::get(key) API I have described is not optional -- it is the
> primary way of detecting a hit.
>
> +1 to use the
On 09/07/2012 05:10 PM, Alex Rousskov wrote:
I am not sure what "option" you are referring to in the above. The
Store::get(key) API I have described is not optional -- it is the
primary way of detecting a hit.
+1 to use the api.
are we talking about the "Store::Root().get" ?
I was just
On 09/07/2012 08:33 AM, Alexander Komyagin wrote:
> On Fri, 2012-09-07 at 08:15 -0600, Alex Rousskov wrote:
>> On 09/07/2012 02:32 AM, Alexander Komyagin wrote:
>>> However, as I stated earlier, the comm.cc problem (actually semantics
>>> problem) persists. I think it should be documented that seco
On Fri, 2012-09-07 at 08:15 -0600, Alex Rousskov wrote:
> On 09/07/2012 02:32 AM, Alexander Komyagin wrote:
> > OK. I agree. It sounds rather reasonable to avoid excess code complexity
> > and CPU consuming in order to gain performance for the common case.
>
> I am very glad that we are in agreeme
On 09/07/2012 02:32 AM, Alexander Komyagin wrote:
> OK. I agree. It sounds rather reasonable to avoid excess code complexity
> and CPU consuming in order to gain performance for the common case.
I am very glad that we are in agreement here. Will you work on a patch
to fix ConnOpener?
> However,
On 09/07/2012 06:20 AM, Eliezer Croitoru wrote:
> On 09/06/2012 09:04 PM, Alex Rousskov wrote:
>> The biggest question for me is why Squid2 code was storing multiple
>> URLs with the cached object (if it was).
>> Why cannot Store just work with the [rewritten] URL given to it and
>> ignore the fac
On 09/06/2012 09:04 PM, Alex Rousskov wrote:
On 09/05/2012 06:58 PM, Amos Jeffries wrote:
FWIW, I have not reviewed the store_url_rewrite code in Squid2 so I
cannot answer the questions related to how it was done.
I can suggest ways of doing this in Squid3, but since somebody already
investigat
OK. I agree. It sounds rather reasonable to avoid excess code complexity
and CPU consuming in order to gain performance for the common case.
However, as I stated earlier, the comm.cc problem (actually semantics
problem) persists. I think it should be documented that second and
subsequent calls to
13 matches
Mail list logo
