On 08/24/2013 12:58 AM, x-man wrote:
Hi Guys,
actually all the problem appeared to be happening due to ICP communication
between squid and our cache peer which also supports ICP. When we have
workers (more than 1) the ICP packets were not returning back (eventually)
to the proper worker so
On 08/24/2013 09:58 AM, x-man wrote:
After adding the following simple config
# different icp port per worker in order to make it work
icp_port 313${process_number}
now everything is working fine with Multi worker environment and our
cache_peer
I think it's should be documented in
Hi Guys,
actually all the problem appeared to be happening due to ICP communication
between squid and our cache peer which also supports ICP. When we have
workers (more than 1) the ICP packets were not returning back (eventually)
to the proper worker so that's why the TIMEOUTS were happening,
On 12/08/2013 10:10 p.m., x-man wrote:
Hi Amos,
we were actually thinking of trying something else, which is
Configure each squid worker to interact with different cache peer on, which
is listening on different port.
We will start multiple instances of our cache peer software listening on
Hi Amos,
we were actually thinking of trying something else, which is
Configure each squid worker to interact with different cache peer on, which
is listening on different port.
We will start multiple instances of our cache peer software listening on
different ports as well.
This way every
Can you share the squid.conf??
This will make sure we understand what you are doing\trying to do.
please feel free to share squid.conf while removing any personal data.
Once we would have the squid.conf we can try to understand more what
might be the source of the problem..
If you do not want to
Hi Amos,
please let me know how to get your patch related to the above.
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/icp-query-timeout-directive-is-not-working-in-3-3-8-for-some-reason-tp4661324p4661500.html
Sent from the Squid - Users mailing list
Hi Amos,
thanks for the valuable input from your side.
I did further testing and I finally got to the problem.
Really with the new version of squid the problem is happening, but it's only
happening when I use workers 1, if I keep single worker, then everything
is ok, once I have multiple
On 6/08/2013 6:39 p.m., x-man wrote:
Hi Amos,
thanks for the valuable input from your side.
I did further testing and I finally got to the problem.
Really with the new version of squid the problem is happening, but it's only
happening when I use workers 1, if I keep single worker, then
Hi Amos,
it's not only the ICP, this is affecting the communication to the cache
peer, so If I allocate two different ports for ICP and for the peer as well,
then I need to run 2 cache peers, everyone with separate storage, and they
will obviously have duplicate contents...
I would rather try
Hi Amos,
I think this request time is the time needed to serve the entire request.
How is icp_query_timeout related to that, it should be only about the query
through ICP protocol?
Otherwise we are using our own cache peer which is dealing with the youtube
content, which supports ICP protocol,
On 3/08/2013 10:45 p.m., x-man wrote:
Hi Amos,
I think this request time is the time needed to serve the entire request.
It is.
How is icp_query_timeout related to that, it should be only about the query
through ICP protocol?
When determining which sibling peer can be used for the HTTP
Hi,
any insights on this will be more than welcome :)
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/icp-query-timeout-directive-is-not-working-in-3-3-8-for-some-reason-tp4661324p4661411.html
Sent from the Squid - Users mailing list archive at Nabble.com.
13 matches
Mail list logo
