RE: [squid-users] ICAP on Solaris

From: Justin Lawler <jlawler_at_amdocs.com>
Date: Sat, 29 Oct 2011 06:46:24 +0000

Hi Amos,

Thanks for the response. We're not 100% sure about all the different scenarios & are still investigating. We can follow up with you on this.

In our application, we do some response modifications, so it's necessary to get the RESPMOD here. Would the only way to do this is to set up a cache peer, and on the squid instance with ICAP enabled, we'd need to disable the caching?

As far as the squid cache - if an object does not exist in cache & has to be downloaded - our application will then do the response modifications. Would the 'modified' response then be cached for future calls - or would the original one?

Thanks and regards,
Justin

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Saturday, October 29, 2011 12:28 PM
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] ICAP on Solaris

On 29/10/11 00:23, Justin Lawler wrote:
> Hi,
>
> We're using ICAP on Solaris for squid 3.1.16 and we're seeing some strange behavior.
>
> When cache is disabled and/or using 'ufs' caching policy, all works ok, but if we change to 'aufs' and enable caching, we're seeing REQMOD's coming through, but no 'RESPMOD's.
>

Note that REQMOD is asking about the client request. Before it gets satisfied by Squid. It gets "called" for all requests.

Whereas, RESPMOD is asking about some reply, which has *already* been satisfied by some server. It _never_ gets "called" on TCP_HIT.

http://wiki.squid-cache.org/Features/ICAP#Squid_Details

Most of what you describe is expected behaviour (cache enabled == less RESPMOD).
  Having same/more RESPMOD with UFS despite caching enabled sounds like a bug.

> We see the same issue on 3.0.15.
>
> Is this a known issue - or anybody see this before? Could it be a configuration option? Should we consider sticking with ufs, or changing to 'diskd'?
>

It has not been mentioned in this way before. Though maybe was described in other terms.

Note that the I/O system functions used to read/write data onto HDD in no way affects the decision about whether to pass traffic over the network to ICAP.

However, if one method of I/O were corrupting the objects during load it could cause Squid to abandon the cached object and fetch a new one. This would appear as similar behaviour to what you describe for UFS with caching enabled.

Amos

--
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.16
   Beta testers wanted for 3.2.0.13
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Received on Sat Oct 29 2011 - 06:46:36 MDT

This archive was generated by hypermail 2.2.0 : Sat Oct 29 2011 - 12:00:04 MDT