Actually I did find another reason for non-caching of this specific
URL - maximum_object_size default is 4 MB, while the object is about 6
MB.
While experimenting, I stumbled upon an undocumented requirement -
maximum_object_size MUST be placed before cache_dir, Otherwise
cacheable check fails wit
IMHO the proper way would be to adopt zeromq or similar messaging
library for communication with rock diskers.
On Wed, Mar 26, 2014 at 2:23 AM, Eliezer Croitoru wrote:
> I have been wondering about the need of a shared cache_dir.
> In squid the development of a cluster is kind of uses ICP and HTC
On Thu, Mar 13, 2014 at 5:44 PM, Alex Rousskov
wrote:
> On 03/13/2014 07:24 AM, Nikolai Gorchilov wrote:
>> On Wed, Mar 12, 2014 at 1:27 AM, Alex Rousskov wrote:
>>> Just to make sure we are on the same page, here is a list of options I
>>> recall being discussed:
On Tue, Mar 11, 2014 at 9:43 PM, Alex Rousskov
wrote:
> On 03/11/2014 01:18 PM, Nikolai Gorchilov wrote:
>> On Tue, Mar 11, 2014 at 6:10 PM, Alex Rousskov wrote:
>>> On 03/11/2014 08:05 AM, Omid Kosari wrote:
>>>> Is it possible for Squid to automatically find every
On Wed, Mar 12, 2014 at 1:27 AM, Alex Rousskov
wrote:
> On 02/14/2014 04:38 AM, Nikolai Gorchilov wrote:
>> On Fri, Feb 14, 2014 at 7:22 AM, Alex Rousskov wrote:
>>> Would using ICP reqnum field as a cache key or adding StoreID to
>>> ICP/HTCP requests work for your
On Tue, Mar 11, 2014 at 6:10 PM, Alex Rousskov
wrote:
> On 03/11/2014 08:05 AM, Omid Kosari wrote:
>
>> Is it possible for Squid to automatically find every similar object based on
>> something like md5 of objects and serve them to clients without need custom
>> DB ?
>
> No, because clients do not
Reviving this topic from the dead as I made a discovery that others
may find useful :)
>> i also revived some suspicious logs :
>>
>> 2013/11/08 16:51:26 kid3| snmpHandleUdp: FD 20 recvfrom: (11) Resource
>> temporarily unavailable
>
> We are still trying to figure this one out. It seems not to be
On Fri, Feb 21, 2014 at 7:34 AM, Alex Rousskov
wrote:
> On 02/20/2014 08:08 PM, Nikolai Gorchilov wrote:
>> On Fri, Feb 21, 2014 at 12:13 AM, Alex Rousskov wrote:
>>> On 02/15/2014 06:12 AM, Nikolai Gorchilov wrote:
>>>> I'm trying to avoid the followi
On Fri, Feb 21, 2014 at 12:13 AM, Alex Rousskov
wrote:
> On 02/15/2014 06:12 AM, Nikolai Gorchilov wrote:
>> I'm trying to avoid the following scenario (excerpt from store.log):
>>
>> 1392406208.398 SWAPOUT 00 8C2B9C51268EFEEDEB33FB9EC53030A1
>> 200 139240
On Tue, Feb 18, 2014 at 10:30 AM, Amos Jeffries wrote:
> On 18/02/2014 1:16 p.m., Nikolai Gorchilov wrote:
>> Hi Spyros,
>>
>> Seems you're experiencing request loops, that are unrelated to your ACLs
>>
>> Looking at the logs, we can clearly see pairs
Hi Spyros,
Seems you're experiencing request loops, that are unrelated to your ACLs
Looking at the logs, we can clearly see pairs of requests for same
url. Like this:
1392590890.301 0 192.168.1.20 TCP_MISS/403 4158 GET
http://www.tvxs.gr/ - HIER_NONE/- text/html
1392590890.302 1 192.168
You haven't define myportname ACLs. Corrections embedded bellow
On Mon, Feb 17, 2014 at 1:34 PM, Grooz, Marc (regio iT)
wrote:
> http_port 3128 name=squidguard
acl squidguard myportname squidguard
> url_rewrite_access allow squidguard
> url_rewrite_access deny all
>
> or
>
> http_port 8080 nam
Hi, Marc,
Yes, it is possible. RTFM about myport/myportname ACL at
http://www.squid-cache.org/Doc/config/acl/
Best,
Niki
On Mon, Feb 17, 2014 at 12:48 PM, Grooz, Marc (regio iT)
wrote:
> Hi Squid Usergroup,
>
> I want that a redirector like squidgard is only ask if a client connect to
> port 3
Dear Amos,
On Sat, Feb 15, 2014 at 3:12 PM, Nikolai Gorchilov wrote:
> On Sat, Feb 15, 2014 at 1:46 PM, Amos Jeffries wrote:
>
> I'm trying to avoid the following scenario (excerpt from store.log):
>
> 1392406208.398 SWAPOUT 00 8C2B9C51268EFEEDEB33FB9EC5303
On Sat, Feb 15, 2014 at 1:46 PM, Amos Jeffries wrote:
> On 15/02/2014 10:35 a.m., Niki Gorchilov wrote:
>> Hi all,
>>
>> I keep exploring the darkest corners of the Squid universe thus
>> meeting unexpected creatures. :-)
>>
>> Today's discovery is hier_code ACL.
>>
>> I stumbled upon it while loo
discuss working solutions for:
a/ No StoreID is used outside Squid
b/ StoreID normalization on incoming ICP/HTCP requests
c/ false-negative HTTP revalidation
Best,
Niki
On Fri, Feb 14, 2014 at 5:20 AM, Amos Jeffries wrote:
> On 14/02/2014 2:20 p.m., Nikolai Gorchilov wrote:
>> On Fri,
On Fri, Feb 14, 2014 at 7:22 AM, Alex Rousskov
wrote:
> On 02/13/2014 06:05 PM, Nikolai Gorchilov wrote:
>> On Thu, Feb 13, 2014 at 10:04 PM, Alex Rousskov wrote:
>>> AFAICT, if Squid always uses URLs for anything
>>> outside internal storage, everything would work corr
On Fri, Feb 14, 2014 at 2:04 AM, Amos Jeffries wrote:
> On 2014-02-14 09:04, Alex Rousskov wrote:
>>
>> On 02/13/2014 05:11 AM, Nikolai Gorchilov wrote:
>>
>>> I'd suggest first to review all possible StoreID use cases involving
>>> cache peers before p
On Thu, Feb 13, 2014 at 10:04 PM, Alex Rousskov
wrote:
> On 02/13/2014 05:11 AM, Nikolai Gorchilov wrote:
>
>> I'd suggest first to review all possible StoreID use cases involving
>> cache peers before proceeding further.
>>
>> Let's define A as originatin
Amos,
I'd suggest first to review all possible StoreID use cases involving
cache peers before proceeding further.
Let's define A as originating proxy and B - as the next hop proxy in
the request forwarding chain. UDP is alias for both ICP or HTCP query,
while TCP is synonym of the following HTTP
Could it be related to Host header mismatch? In your direct example it
is localhost, but when routed via squid it will become couchdb. You
can add forceddomain=localhost parameter in your cache_peer directive
in order to fix it.
Hope this helps!
Best,
Niki
P.S. I assume you run both Squid and Co
Can somebody reproduce the problem? Or I'm the only one who have it?
Best,
Niki
P.S. Made some additional testing with diskd storage - no problems
detected. IPC seems to work as expected in diskd mode.
On Wed, Jan 29, 2014 at 12:26 PM, Nikolai Gorchilov wrote:
> I just made a new d
I just made a new discovery - the problem seemingly disappears when
running Squid with -N, thus removing the disker process out of the
equation.
Could it be a worker-disker IPC related issue, instead of rock store
specific problem?
Best,
Niki
On Wed, Jan 29, 2014 at 12:00 PM, Nikolai Gorchilov
Dear Amos
On Wed, Jan 29, 2014 at 5:18 AM, Amos Jeffries wrote:
>>
>> The simple steps to reproduce:
>>
>> 1. Empty store dir and recreate swap with -z
>
> Did you leave sufficient time after doing this to ensure that the -z
> operation was completed successfully and all the "squid -z" spawned
>
On Wed, Jan 15, 2014 at 8:35 PM, babajaga wrote:
> Interesting question Did you compare this behaviour to squid2.7 using
> storeurl ?
Nope. I just tried 4.3.2. Same result - both UDP and TCP requests go
with altered URLs.
>> Not possible because there is none that "recognize request protocol".
>>
>> What happens is admin configure squid.conf ports manually, one per
>> protocol type to be recieved. Squid only supports HTTP, HTTPS, ICP,
>> HTCP, and SNMP incoming traffic.
>>
>> The non-HTTP traffic support in Squid is
Hi Brian,
Do you add CFLAGS/CXXFLAGS/etc while ./configure? I had similar issue,
until I completely removed them.
Best,
Niki
On Mon, Dec 16, 2013 at 3:31 PM, Brian J. Murrell wrote:
> On Mon, 2013-12-16 at 15:08 +1300, Amos Jeffries wrote:
>>
>> I have a patch that fixes some of these at
>>
>
That's why it is necessary to have an acl clause that prevents Squid
from caching a page based on contents of the response headers,
especially status code.
On Tue, Oct 8, 2013 at 5:34 PM, Alfredo Rezinovsky
wrote:
> El 08/10/13 11:18, Niki Gorchilov escribió:
>
>> Hi there.
>>
>> Started playing
Amos,
It turned out there's no issue at all. I was using my own (obsolete)
build script that provided CFLAGS, CPPFLAGS & CXXFLAGS.
Sorry! Case closed!
Best,
Niki
On Thu, Oct 3, 2013 at 8:42 PM, Nikolai Gorchilov wrote:
> On Thu, Oct 3, 2013 at 7:15 PM, Amos Jeffries wrote:
>&g
On Thu, Oct 3, 2013 at 7:15 PM, Amos Jeffries wrote:
>>> Does it build past this error if you run this command before ./configure
>>> ?
>>>sed --in-place s/_LIBRARIES/_LTLIBRARIES/ compat/Makefile.in
>>
>> Unfortunately not. Same error in both 3.4.0.1 & 3.4.0.2.
>
> Strange. It is building wit
On Thu, Oct 3, 2013 at 5:18 PM, Amos Jeffries wrote:
> On 4/10/2013 2:46 a.m., Niki Gorchilov wrote:
>>
>> I'm trying to compile 3.4.0.1 on Ubuntu 12.04 LTS I get the following
>> errors:
>
>
> Please try the 3.4.0.2 package which has just been bundled.
> (NP: I dont think it will solve this parti
On Sun, Sep 15, 2013 at 12:52 AM, Eliezer Croitoru wrote:
> I have found the problem and I will rephrase the problem description:
> While using tproxy the main issue is that the ports of the source IP is
NOPE. As I said before, it's NOT related to TPROXY code at all. Same
problem exists, even whe
On Sat, Sep 14, 2013 at 11:59 PM, Eliezer Croitoru wrote:
> OK so let's make this experience that you already have as a public
> resource..
here it is: a simple php script that demonstrates the issue:
https://gist.github.com/ngorchilov/6570413#file-s-php
> This way more then just you will have
On Sat, Sep 14, 2013 at 9:36 PM, Eliezer Croitoru wrote:
> Hey,
>
> it can be tested in a matter of minutes.
> If we have some test candidate I will write a small tproxy script to
> verify the suspect.
The pseudo code I have provided is based on my real-world experiment.
I did the test myself, be
On Tue, Sep 10, 2013 at 11:51 PM, Alex Rousskov
wrote:
> Hi Niki,
>
> We have seen similar problems with high-performance Web Polygraph
> tests and added an option for Polygraph clients to explicitly manage
> client port assignment instead of relying on kernel's ephemeral ports
> algorithm. Po
Hi, Eliezer,
On Tue, Sep 10, 2013 at 1:49 AM, Eliezer Croitoru wrote:
> Hey Nickolai,
>
> I would try to make sense of what you have seen.
> The tproxy is a very complex feature which by the kernel cannot bind
> double src(ip:port) + dst(ip:port)..
> like let say for example the 10.100.1.100 clie
On Mon, Sep 9, 2013 at 4:41 PM, Antony Stone
wrote:
> On Monday 09 September 2013 at 13:08:00, Nikolai Gorchilov wrote:
>
>> On Mon, Sep 9, 2013 at 4:15 PM, Nikolai Gorchilov wrote:
>> > User's original port seems to be an easy option in TPROXY mode
>>
>> I
On Mon, Sep 9, 2013 at 4:15 PM, Nikolai Gorchilov wrote:
> User's original port seems to be an easy option in TPROXY mode
I did a simple test and found the kernel will emit EADDRINUSE when you
bind on user's ip:port... So, a more complicated solution is needed.
Keeping track of
On Sun, Aug 25, 2013 at 7:20 AM, Amos Jeffries wrote:
>> Before digging deeper into the TPROXY kernel code, I'd like to clarify
>> one aspect of squid's behaviour. Do you pass a port number (anything >
>> 0) in inaddr.ai_addr during the bind call? Sorry, I couldn't trace it
>> myself, as I didn't
On Fri, Sep 6, 2013 at 5:08 PM, Amos Jeffries wrote:
> It does indeed. You are not checking the external_acl_type helper early
> enough in the request processing sequence.
>
> clientside_tos directive is processed and TOS selected before the request
> upstream destination is selected.
> always_di
s acl
clientside_tos 0x10 peering
clientside_tos 0x00 !peering
===[cut]===
Hope this helps!
Niki
On Fri, Sep 6, 2013 at 10:10 AM, Amos Jeffries wrote:
> On 6/09/2013 11:56 a.m., Nikolai Gorchilov wrote:
>>
>> Sorry for the late reply. Was traveling in the last two days.
>>
Sorry for the late reply. Was traveling in the last two days.
On Wed, Sep 4, 2013 at 10:05 AM, Amos Jeffries wrote:
>
> On 4/09/2013 7:14 a.m., Niki Gorchilov wrote:
>>
>> 2. We know that 50% of the objects in our cache never get requested
>> second time, thus only creating load on the system to
42 matches
Mail list logo
