I will provide a better bug report. I believe I found the problem with
generation of coredumps.
On Apr 6, 2005 6:07 PM, Tsantilas Christos
[EMAIL PROTECTED] wrote:
This mail posted to c-icap mailing list.
I believe that it is related with ICAP's request modification operation.
It does not
Mateus
send me the backtrace
On Apr 5, 2005 10:05 AM, Mateus Gröess wrote:
2005/04/04 14:07:00| storeLateRelease: released 0 objects
2005/04/04 17:12:31| assertion failed: client_side.c:3268: cbdataValid(conn)
2005/04/04 17:12:42| Starting Squid Cache version 2.5.STABLE9-CVS for
Hi Henrik,
Ruy Oliveira helped me debuging the program. Return was ok, but there
was some perl errors at my code. After some cleanup (by Ruy) it finally
worked, and it really doesn't the encode_base64.
As I am not a experienced perl programmer, and running it from command
line give me
Hey Henrik and all,
I've got a reverse proxy running Squid with the following cache_peer
configuration:
cache_peer 192.168.1.47 parent 80 7 originserver no-query carp
cache_peer 192.168.1.48 parent 80 7 originserver no-query carp
cache_peer_domain 192.168.1.47 .domain.com
cache_peer_domain
On Thu, 7 Apr 2005, Joe Cooper wrote:
The whole configuration is working, except for load balancing. Without
carp I always get FIRST_UP_PARENT/192.168.1.47. With carp I always get
CARP/192.168.1.48, no matter what IP I'm coming from (and I tried a half
dozen client IPs to be sure I wasn't
Thanks for the rapid response, Henrik.
Henrik Nordstrom wrote:
On Thu, 7 Apr 2005, Joe Cooper wrote:
The whole configuration is working, except for load balancing.
Without carp I always get FIRST_UP_PARENT/192.168.1.47. With carp
I always get CARP/192.168.1.48, no matter what IP I'm coming
On Thu, 7 Apr 2005, Joe Cooper wrote:
CARP balances based on a hash of the destination URL, not client.
Hmmm...that raises a different question: How does one address the issue of
maintaining client stickiness?
It doesn't. CARP is designed for routing requests to a cloud/array of
parent proxy
