zph code will not correctly qualify parent and sibling hits (trivial fix)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. With ZPH enabled and zph_local & zph_sibling/zph_parent set
2. Any cache hits from parents/siblings will show the issue

What is the expected output? What do you see instead?

Due to the way the code is written instead of seeing the correct
parent/sibling hit ZPH code we're presented with the zph_local code.

What version of the product are you using? On what operating system?
This should affect all current squid 2.0 and lusca_head on any operating system

This is a trivial fix correcting the code order to ensure we're falling
through to zph_local instead of defaulting to it

Original issue reported on code.google.com by regar...@gmail.com on 8 Jul 2009 at 2:24

Attachments:

• zph_fix.patch

[GoogleCodeExporter]

I'll look into it, thanks.

Would you be able to help me write out some actual documentation outlining what 
ZPH
does and how it works? The documentation is very, very lacking.

Thanks!

Original comment by adrian.c...@gmail.com on 8 Jul 2009 at 2:48

• Changed state: Accepted
• Added labels: Version-Head
• Removed labels: Version-1.0

[GoogleCodeExporter]

The patch makes sense if zph_local is to be overridden by the sibling/parent
settings. Unfortunately the zph documentation doesn't cover which order this 
should
all be abused in.

How should we change the configuration documentation to make the zph selection
algorithm clearer?

Original comment by adrian.c...@gmail.com on 8 Jul 2009 at 3:00

[GoogleCodeExporter]

Hi Adrian,

I'll submit proposed documentation update for you soon.

Regardt

Original comment by regar...@gmail.com on 8 Jul 2009 at 8:38

[GoogleCodeExporter]

Wiki or as part of source?

Original comment by regar...@gmail.com on 8 Jul 2009 at 8:42

[GoogleCodeExporter]

Let's put it in cf.data.pre for now.

I'd eventually really like to see the zph specific code moved out into a 
separate module instead of being inserted 
in-line in the client_side code - it'd then be a no-brainer to document it 
there. :)

Original comment by adrian.c...@gmail.com on 8 Jul 2009 at 10:07

[GoogleCodeExporter]

Hi Adrian,

Review and let me know if you think it needs a lot more.

OT: Know if anyone has been working on getting lusca debian(.deb) ready?

Regardt

Original comment by regar...@gmail.com on 9 Jul 2009 at 9:28

Attachments:

• zph_doc.patch

[GoogleCodeExporter]

Patch committed - revision 14164.

Thanks!

Original comment by adrian.c...@gmail.com on 9 Jul 2009 at 10:23

[GoogleCodeExporter]

Also - re debian package - please ask on the lusca-users@ mailing list.

Original comment by adrian.c...@gmail.com on 9 Jul 2009 at 10:24

• Changed state: Fixed

[GoogleCodeExporter]

CD&peer hit still doesn't mark.
    if (!isTcpHit(http->log_type))
        tos = 0;
isTcpHit is all about local hits. Therefore tos always zero if local MISS and 
peer HIT
I would like to put local on first before peer, CMIIW if squid has the local 
content then no query to peer to be made.

Original comment by chudy.fernandez on 21 Apr 2011 at 5:39

• Changed state: Accepted

Attachments:

• lusca_CD_peer_tos.diff

[GoogleCodeExporter]

Oh, I see now. So when there's a miss but it's a cache-peer fetch hit?

Hm, it's still different though as it's going over the network. What about we 
create another zph TOS match for that case?

Original comment by adrian.c...@gmail.com on 9 Jul 2011 at 12:27