Alex Rousskov wrote:
On 02/20/2010 09:24 PM, Amos Jeffries wrote:
On Sat, 20 Feb 2010 19:14:48 -0700, Alex Rousskov
rouss...@measurement-factory.com wrote:
Hello,
If you recall, I am working on Squid that starts multiple processes,
each doing similar things. Even with this simple design,
On Sun, Feb 21, 2010 at 2:25 AM, Alex Rousskov
rouss...@measurement-factory.com 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
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
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 does not
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.conf.
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
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
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 better
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 to a
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 difficult to
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 I
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 processes
On Sun, 21 Feb 2010 22:27:06 +0100, Henrik Nordström
hen...@henriknordstrom.net 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
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 than a
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, stdinfd,
On Mon, 22 Feb 2010 02:03:31 +0100, Henrik Nordström
hen...@henriknordstrom.net 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
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 think
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 line
On Sun, 21 Feb 2010 17:10:34 -0700, Alex Rousskov
rouss...@measurement-factory.com 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
On Sun, 21 Feb 2010 22:16:10 +0100, Henrik Nordström
hen...@henriknordstrom.net 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
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 without
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 bomb analogy
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 then?
Not
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 doing
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
processes
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
26 matches
Mail list logo
