Alex Rousskov wrote:
On 02/21/2010 04:26 PM, Henrik Nordström wrote:
sön 2010-02-21 klockan 15:14 -0700 skrev Alex Rousskov:
Please note that the CPU affinity hack where every process gets its own
core would not work if ${process_name} is not a number, but we can come
up with another hack to s
On 02/21/2010 08:21 PM, Robert Collins wrote:
> On Sun, 2010-02-21 at 20:18 -0700, Alex Rousskov wrote:
>> On 02/21/2010 06:10 PM, Henrik Nordström wrote:
>>> sön 2010-02-21 klockan 17:10 -0700 skrev Alex Rousskov:
>>>
The only inter-process cooperation I plan to support initially is "N
p
On Sun, 2010-02-21 at 20:18 -0700, Alex Rousskov wrote:
> On 02/21/2010 06:10 PM, Henrik Nordström wrote:
> > sön 2010-02-21 klockan 17:10 -0700 skrev Alex Rousskov:
> >
> >> The only inter-process cooperation I plan to support initially is "N
> >> processes monitoring the same http_port (and doin
On 02/21/2010 06:10 PM, Henrik Nordström wrote:
> sön 2010-02-21 klockan 17:10 -0700 skrev Alex Rousskov:
>
>> The only inter-process cooperation I plan to support initially is "N
>> processes monitoring the same http_port (and doing everything else)".
>
> I guess there will be no shared cache th
On 02/21/2010 05:44 PM, Robert Collins wrote:
> On Sun, 2010-02-21 at 22:27 +0100, Henrik Nordström wrote:
>> lör 2010-02-20 klockan 18:25 -0700 skrev Alex Rousskov:
>>
>>> The reasons you mention seem like a good justification for this option
>>> official existence. I do not quite get the "fork bo
On 02/21/2010 04:26 PM, Henrik Nordström wrote:
> sön 2010-02-21 klockan 15:14 -0700 skrev Alex Rousskov:
>
>> Please note that the CPU affinity hack where every process gets its own
>> core would not work if ${process_name} is not a number, but we can come
>> up with another hack to support that
On Sun, 21 Feb 2010 22:16:10 +0100, Henrik Nordström
wrote:
> sön 2010-02-21 klockan 20:37 +0200 skrev Tsantilas Christos:
>> There are broken servers out there that insist on receiving HTTP/1.1
>> requests.
>
> Yes..
>
> and even more which are broken when receiving HTTP/1.0 requests.
>
>> Th
On Sun, 21 Feb 2010 17:10:34 -0700, Alex Rousskov
wrote:
> On 02/21/2010 02:45 PM, Henrik Nordström wrote:
>
>> I guess the main question to ask is interaction between processes.
>> Mainly sharing of cache etc. How do these impact the chosen model?
>>
>>
>> In the longer term model I see that w
On Mon, 2010-02-22 at 02:03 +0100, Henrik Nordström wrote:
> mån 2010-02-22 klockan 11:44 +1100 skrev Robert Collins:
>
> > command protocol for it would be pretty similar to the SHM disk IO
> > helper, but for processes. Something like:
> > squid->helper: spawn stderrfd argv(escaped/encoded to be
sön 2010-02-21 klockan 17:10 -0700 skrev Alex Rousskov:
> The only inter-process cooperation I plan to support initially is "N
> processes monitoring the same http_port (and doing everything else)".
I guess there will be no shared cache then?
> I am working on option (B). While more complex, I t
On Mon, 22 Feb 2010 02:03:31 +0100, Henrik Nordström
wrote:
> mån 2010-02-22 klockan 11:44 +1100 skrev Robert Collins:
>
>> command protocol for it would be pretty similar to the SHM disk IO
>> helper, but for processes. Something like:
>> squid->helper: spawn stderrfd argv(escaped/encoded to be
mån 2010-02-22 klockan 11:44 +1100 skrev Robert Collins:
> command protocol for it would be pretty similar to the SHM disk IO
> helper, but for processes. Something like:
> squid->helper: spawn stderrfd argv(escaped/encoded to be line & NULLZ
>string safe)
> helper->squid: pid, std
On Sun, 2010-02-21 at 22:27 +0100, Henrik Nordström wrote:
> lör 2010-02-20 klockan 18:25 -0700 skrev Alex Rousskov:
>
> > The reasons you mention seem like a good justification for this option
> > official existence. I do not quite get the "fork bomb" analogy because
> > we are not creating more
On Sun, 21 Feb 2010 22:27:06 +0100, Henrik Nordström
wrote:
> lör 2010-02-20 klockan 18:25 -0700 skrev Alex Rousskov:
>
>> The reasons you mention seem like a good justification for this option
>> official existence. I do not quite get the "fork bomb" analogy because
>> we are not creating more t
On 02/21/2010 02:45 PM, Henrik Nordström wrote:
> I guess the main question to ask is interaction between processes.
> Mainly sharing of cache etc. How do these impact the chosen model?
>
>
> In the longer term model I see that we will have several cooperating
> processes, for example
>
> N pro
sön 2010-02-21 klockan 15:14 -0700 skrev Alex Rousskov:
> Please note that the CPU affinity hack where every process gets its own
> core would not work if ${process_name} is not a number, but we can come
> up with another hack to support that without enumerating all
> processes/cores.
>From what
On 02/21/2010 02:36 PM, Henrik Nordström wrote:
> sön 2010-02-21 klockan 00:52 -0700 skrev Alex Rousskov:
>
>> I agree that number and name do not match well. I struggled with this. I
>> did not want to use process_id to avoid the clash with system PID. Just
>> "process" sounds too generic and dif
lör 2010-02-20 klockan 19:14 -0700 skrev Alex Rousskov:
> Hello,
>
> If you recall, I am working on Squid that starts multiple processes,
> each doing similar things. Even with this simple design, folks want to
>
> (a) have differently configured processes (e.g., a process that is
> dedicated
sön 2010-02-21 klockan 00:52 -0700 skrev Alex Rousskov:
> I agree that number and name do not match well. I struggled with this. I
> did not want to use process_id to avoid the clash with system PID. Just
> "process" sounds too generic and difficult to extend though. Would
> process_number be bett
fre 2010-02-19 klockan 21:32 -0700 skrev Alex Rousskov:
> I am
> happy to do it if others think one compound option is better than two
> simple ones in this case.
To me the compound one is easier to understand than having two
directives.
1/1s and 100/100s is quite easy to follow compared to
lim
lör 2010-02-20 klockan 18:25 -0700 skrev Alex Rousskov:
> The reasons you mention seem like a good justification for this option
> official existence. I do not quite get the "fork bomb" analogy because
> we are not creating more than a configured number of concurrent forks,
> are we? We may create
lör 2010-02-20 klockan 17:12 +1300 skrev Amos Jeffries:
> It has been found necessary in certain corner cases with PHP helpers
> (which have system imposed limited lifetimes) where a proxy has
> previously been under some load and helpers started then are timed out
> later under low load as a b
sön 2010-02-21 klockan 20:37 +0200 skrev Tsantilas Christos:
> There are broken servers out there that insist on receiving HTTP/1.1
> requests.
Yes..
and even more which are broken when receiving HTTP/1.0 requests.
> This patch adds a new force_http_1p1_request acl-driven option to
> squid.con
sön 2010-02-21 klockan 20:37 +0200 skrev Tsantilas Christos:
> Please take care to the "#if WHEN_SQUID_IS_HTTP1_1" block in
> HttpMsg.cc file which was disabled. This block allow squid to consider
> a connection to the HTTP server as persistent in the case the
> "Connection: close" header do
There are broken servers out there that insist on receiving HTTP/1.1
requests.
This patch adds a new force_http_1p1_request acl-driven option to
squid.conf.
When the HTTP request matches the specified ACL, Squid uses "HTTP/1.1"
HTTP-Version string in the request sent to the server. The affe
On Sun, Feb 21, 2010 at 2:25 AM, Alex Rousskov
wrote:
> When Squid dies due to frequent helper failures so do helpers. Thus,
> strictly speaking, a current helper is not a true "phoenix". Also, the
> option is applied to the helper, so it should focus on what happens to
> the helper and not Squid
Alex Rousskov wrote:
On 02/20/2010 09:24 PM, Amos Jeffries wrote:
On Sat, 20 Feb 2010 19:14:48 -0700, Alex Rousskov
wrote:
Hello,
If you recall, I am working on Squid that starts multiple processes,
each doing similar things. Even with this simple design, folks want to
(a) have different
27 matches
Mail list logo
