date:20110202

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #1123

2011-02-02 Thread noc

See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/1123/changes

Changes:

[Christos Tsantilas chtsa...@users.sourceforge.net] The attached patch 
implements aggregation of SNMP responses, similar to how
we aggregate some cache manager stats.

The code contains changes that allow us to share some of the classes between
Cache Manager and SNMP code:

* implement the following base classes under the ipc directory/module:
- Ipc::Forwarder (ipc/Forwarder{.cc,.h} files)
- Ipc::Inquirer (ipc/Inquirer{.cc,.h} files)
- Ipc::Request (ipc/Request{.cc,.h} files)
- Ipc::Response (ipc/Response{.cc,.h} files)

* fix the Mgr::Forwarder, Mgr::Inquirer, Mgr::Request and Mgr::Response
classes to be implemented as kid classes of the equivalent Icp::* classes.

Also implements for the SNMP the same mechanism used for cache manager:
The SNMP requests forwarder to coordinator which collects the statistics from
kids and aggregate them.


This is a Measurement Factory project.

[Automatic source maintenance squid...@squid-cache.org] SourceFormat 
Enforcement

--
[...truncated 4338 lines...]
libtool: compile:  g++ -DHAVE_CONFIG_H -I../../.. -I../../../include 
-I../../../lib -I../../../src -I../../include -I../../../src/auth -Wall 
-Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 
-MT Acl.lo -MD -MP -MF .deps/Acl.Tpo -c ../../../src/auth/Acl.cc  -fPIC -DPIC 
-o .libs/Acl.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I../../.. -I../../../include 
-I../../../lib -I../../../src -I../../include -I../../../src/auth -Wall 
-Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 
-MT Acl.lo -MD -MP -MF .deps/Acl.Tpo -c ../../../src/auth/Acl.cc -o Acl.o 
/dev/null 21
libtool: compile:  g++ -DHAVE_CONFIG_H -I../../.. -I../../../include 
-I../../../lib -I../../../src -I../../include -I../../../src/auth -Wall 
-Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 
-MT auth_digest.lo -MD -MP -MF .deps/auth_digest.Tpo -c 
../../../src/auth/digest/auth_digest.cc -o auth_digest.o /dev/null 21
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H  
-I../../.. -I../../../include -I../../../lib -I../../../src -I../../include
-I../../../src/auth   -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror 
-pipe -D_REENTRANT -g -O2 -MT AclMaxUserIp.lo -MD -MP -MF 
.deps/AclMaxUserIp.Tpo -c -o AclMaxUserIp.lo 
../../../src/auth/AclMaxUserIp.cc; \
then mv -f .deps/AclMaxUserIp.Tpo .deps/AclMaxUserIp.Plo; else rm 
-f .deps/AclMaxUserIp.Tpo; exit 1; fi
libtool: compile:  g++ -DHAVE_CONFIG_H -I../../.. -I../../../include 
-I../../../lib -I../../../src -I../../include -I../../../src/auth -Wall 
-Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 
-MT AclMaxUserIp.lo -MD -MP -MF .deps/AclMaxUserIp.Tpo -c 
../../../src/auth/AclMaxUserIp.cc  -fPIC -DPIC -o .libs/AclMaxUserIp.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I../../.. -I../../../include 
-I../../../lib -I../../../src -I../../include -I../../../src/auth -Wall 
-Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 
-MT AclMaxUserIp.lo -MD -MP -MF .deps/AclMaxUserIp.Tpo -c 
../../../src/auth/AclMaxUserIp.cc -o AclMaxUserIp.o /dev/null 21
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H  
-I../../.. -I../../../include -I../../../lib -I../../../src -I../../include
-I../../../src/auth   -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror 
-pipe -D_REENTRANT -g -O2 -MT AclProxyAuth.lo -MD -MP -MF 
.deps/AclProxyAuth.Tpo -c -o AclProxyAuth.lo 
../../../src/auth/AclProxyAuth.cc; \
then mv -f .deps/AclProxyAuth.Tpo .deps/AclProxyAuth.Plo; else rm 
-f .deps/AclProxyAuth.Tpo; exit 1; fi
libtool: compile:  g++ -DHAVE_CONFIG_H -I../../.. -I../../../include 
-I../../../lib -I../../../src -I../../include -I../../../src/auth -Wall 
-Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 
-MT AclProxyAuth.lo -MD -MP -MF .deps/AclProxyAuth.Tpo -c 
../../../src/auth/AclProxyAuth.cc  -fPIC -DPIC -o .libs/AclProxyAuth.o
/bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2  -g -o libbasic.la 
  basicScheme.lo auth_basic.lo basicUserRequest.lo  
libtool: compile:  g++ -DHAVE_CONFIG_H -I../../.. -I../../../include 
-I../../../lib -I../../../src -I../../include -I../../../src/auth -Wall 
-Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 
-MT AclProxyAuth.lo -MD -MP -MF .deps/AclProxyAuth.Tpo -c 
../../../src/auth/AclProxyAuth.cc -o AclProxyAuth.o /dev/null 21
libtool: link: /usr/bin/ar cru .libs/libbasic.a .libs/basicScheme.o 
.libs/auth_basic.o .libs/basicUserRequest.o 
libtool: link: ranlib .libs/libbasic.a
libtool: link: ( cd .libs  rm -f libbasic.la  ln -s ../libbasic.la 
libbasic.la )
/bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith 
-Wwrite-strings

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #1124

2011-02-02 Thread noc

See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/1124/changes

Changes:

[Christos Tsantilas chtsa...@users.sourceforge.net] SMP SNMP: First try to 
handle compile problems in CentOS 5.3

[Christos Tsantilas chtsa...@users.sourceforge.net] The attached patch 
implements aggregation of SNMP responses, similar to how
we aggregate some cache manager stats.

The code contains changes that allow us to share some of the classes between
Cache Manager and SNMP code:

* implement the following base classes under the ipc directory/module:
- Ipc::Forwarder (ipc/Forwarder{.cc,.h} files)
- Ipc::Inquirer (ipc/Inquirer{.cc,.h} files)
- Ipc::Request (ipc/Request{.cc,.h} files)
- Ipc::Response (ipc/Response{.cc,.h} files)

* fix the Mgr::Forwarder, Mgr::Inquirer, Mgr::Request and Mgr::Response
classes to be implemented as kid classes of the equivalent Icp::* classes.

Also implements for the SNMP the same mechanism used for cache manager:
The SNMP requests forwarder to coordinator which collects the statistics from
kids and aggregate them.


This is a Measurement Factory project.

--
[...truncated 4294 lines...]
libtool: compile:  g++ -DHAVE_CONFIG_H -I../../.. -I../../../include 
-I../../../lib -I../../../src -I../../include -I../../../src/auth -Wall 
-Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 
-MT AclProxyAuth.lo -MD -MP -MF .deps/AclProxyAuth.Tpo -c 
../../../src/auth/AclProxyAuth.cc  -fPIC -DPIC -o .libs/AclProxyAuth.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I../../.. -I../../../include 
-I../../../lib -I../../../src -I../../include -I../../../src/auth -Wall 
-Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 
-MT AclMaxUserIp.lo -MD -MP -MF .deps/AclMaxUserIp.Tpo -c 
../../../src/auth/AclMaxUserIp.cc -o AclMaxUserIp.o /dev/null 21
libtool: compile:  g++ -DHAVE_CONFIG_H -I../../.. -I../../../include 
-I../../../lib -I../../../src -I../../include -I../../../src/auth -Wall 
-Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 
-MT AclProxyAuth.lo -MD -MP -MF .deps/AclProxyAuth.Tpo -c 
../../../src/auth/AclProxyAuth.cc -o AclProxyAuth.o /dev/null 21
/bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2  -g -o libbasic.la 
  basicScheme.lo auth_basic.lo basicUserRequest.lo  
libtool: link: /usr/bin/ar cru .libs/libbasic.a .libs/basicScheme.o 
.libs/auth_basic.o .libs/basicUserRequest.o 
libtool: link: ranlib .libs/libbasic.a
libtool: link: ( cd .libs  rm -f libbasic.la  ln -s ../libbasic.la 
libbasic.la )
/bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2  -g -o libntlm.la  
 ntlmScheme.lo auth_ntlm.lo ntlmUserRequest.lo  
libtool: link: /usr/bin/ar cru .libs/libntlm.a .libs/ntlmScheme.o 
.libs/auth_ntlm.o .libs/ntlmUserRequest.o 
libtool: link: ranlib .libs/libntlm.a
libtool: link: ( cd .libs  rm -f libntlm.la  ln -s ../libntlm.la 
libntlm.la )
/bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2  -g -o 
libnegotiate.la   negotiateScheme.lo auth_negotiate.lo negotiateUserRequest.lo  
/bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2  -g -o 
libdigest.la   digestScheme.lo auth_digest.lo digestUserRequest.lo  
libtool: link: /usr/bin/ar cru .libs/libnegotiate.a .libs/negotiateScheme.o 
.libs/auth_negotiate.o .libs/negotiateUserRequest.o 
libtool: link: ranlib .libs/libnegotiate.a
libtool: link: ( cd .libs  rm -f libnegotiate.la  ln -s 
../libnegotiate.la libnegotiate.la )
/bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2  -g -o libacls.la  
 Acl.lo AclMaxUserIp.lo AclProxyAuth.lo  
libtool: link: /usr/bin/ar cru .libs/libdigest.a .libs/digestScheme.o 
.libs/auth_digest.o .libs/digestUserRequest.o 
libtool: link: ranlib .libs/libdigest.a
libtool: link: ( cd .libs  rm -f libdigest.la  ln -s ../libdigest.la 
libdigest.la )
/bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith 
-Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2  -g -o libauth.la  
 AuthType.lo Config.lo Gadgets.lo Scheme.lo State.lo User.lo UserRequest.lo 
libbasic.la libntlm.la libnegotiate.la libdigest.la 
libtool: link: /usr/bin/ar cru .libs/libacls.a .libs/Acl.o .libs/AclMaxUserIp.o 
.libs/AclProxyAuth.o 
libtool: link: ranlib .libs/libacls.a
libtool: link: ( cd .libs  rm -f libacls.la  ln -s ../libacls.la 
libacls.la )
libtool: link: (cd .libs/libauth.lax/libbasic.a  /usr/bin/ar x 
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/auth/./.libs/libbasic.a;)
libtool: link: (cd .libs/libauth.lax/libntlm.a  /usr/bin/ar x

dedup fs's?

2011-02-02 Thread Mark Nottingham

Has anyone tried squid with lessfs or ZFS in dedup mode?

Just curious; I read a paper once that implied that Traffic Server used to do 
dedup internally, but apparently it doesn't any more...


--
Mark Nottingham   m...@yahoo-inc.com

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #1125

2011-02-02 Thread noc

See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/1125/changes

Changes:

[Christos Tsantilas chtsa...@users.sourceforge.net] SMP SNMP: 2nd try to 
handle compiler errors in CentOS 5.3

[Christos Tsantilas chtsa...@users.sourceforge.net] SMP SNMP: First try to 
handle compile problems in CentOS 5.3

--
[...truncated 6930 lines...]
BUILD: .././test-suite/buildtests/layer-00-default.opts
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:190:
 undefined reference to `enter_suid'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:192:
 undefined reference to `comm_open_listener'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:194:
 undefined reference to `leave_suid'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:163:
 undefined reference to `Snmp::Response::Response(unsigned int)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:165:
 undefined reference to `Snmp::Response::pack(Ipc::TypedMsgHdr) const'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Inquirer.h:49:
 undefined reference to `Snmp::Inquirer::CBDATA_Inquirer'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:168:
 undefined reference to `Snmp::Inquirer::Inquirer(Snmp::Request const, 
std::vectorIpc::StrandCoord, std::allocatorIpc::StrandCoord  const)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:168:
 undefined reference to `AsyncJob::Start(AsyncJob*)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Response.h:21:
 undefined reference to `vtable for Snmp::Response'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Response.h:21:
 undefined reference to `Snmp::Pdu::~Pdu()'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Response.h:20:
 undefined reference to `VTT for Snmp::Response'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Response.h:20:
 undefined reference to `VTT for Snmp::Response'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Response.h:21:
 undefined reference to `vtable for Snmp::Response'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Response.h:21:
 undefined reference to `Snmp::Pdu::~Pdu()'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:147:
 undefined reference to `CacheManager::createRequestedAction(Mgr::ActionParams 
const)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:148:
 undefined reference to `AsyncJob::Start(AsyncJob*)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:93:
 undefined reference to `Snmp::Response::Response(Ipc::TypedMsgHdr const)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:86:
 undefined reference to `Snmp::Request::Request(Ipc::TypedMsgHdr const)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Request.h:23:
 undefined reference to `vtable for Snmp::Request'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Request.h:23:
 undefined reference to `Snmp::Session::~Session()'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Request.h:23:
 undefined reference to `Snmp::Pdu::~Pdu()'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Request.h:20:
 undefined reference to `VTT for Snmp::Request'

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #1126

2011-02-02 Thread noc

See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/1126/changes

Changes:

[Automatic source maintenance squid...@squid-cache.org] SourceFormat 
Enforcement

[Christos Tsantilas chtsa...@users.sourceforge.net] SMP SNMP: 2nd try to 
handle compiler errors in CentOS 5.3

--
[...truncated 6944 lines...]
BUILD: .././test-suite/buildtests/layer-00-default.opts
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:190:
 undefined reference to `enter_suid'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:192:
 undefined reference to `comm_open_listener'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:194:
 undefined reference to `leave_suid'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:163:
 undefined reference to `Snmp::Response::Response(unsigned int)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:165:
 undefined reference to `Snmp::Response::pack(Ipc::TypedMsgHdr) const'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Inquirer.h:49:
 undefined reference to `Snmp::Inquirer::CBDATA_Inquirer'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:168:
 undefined reference to `Snmp::Inquirer::Inquirer(Snmp::Request const, 
std::vectorIpc::StrandCoord, std::allocatorIpc::StrandCoord  const)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:168:
 undefined reference to `AsyncJob::Start(AsyncJob*)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Response.h:21:
 undefined reference to `vtable for Snmp::Response'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Response.h:21:
 undefined reference to `Snmp::Pdu::~Pdu()'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Response.h:20:
 undefined reference to `VTT for Snmp::Response'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Response.h:20:
 undefined reference to `VTT for Snmp::Response'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Response.h:21:
 undefined reference to `vtable for Snmp::Response'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Response.h:21:
 undefined reference to `Snmp::Pdu::~Pdu()'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:147:
 undefined reference to `CacheManager::createRequestedAction(Mgr::ActionParams 
const)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:148:
 undefined reference to `AsyncJob::Start(AsyncJob*)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:93:
 undefined reference to `Snmp::Response::Response(Ipc::TypedMsgHdr const)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Coordinator.cc:86:
 undefined reference to `Snmp::Request::Request(Ipc::TypedMsgHdr const)'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Request.h:23:
 undefined reference to `vtable for Snmp::Request'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Request.h:23:
 undefined reference to `Snmp::Session::~Session()'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/snmp/Request.h:23:
 undefined reference to `Snmp::Pdu::~Pdu()'
http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.HEAD-BZR/_build/src/ipc/../../../src/ipc/Request.h:20:
 undefined reference to `VTT for Snmp::Request'

Re: /bzr/squid3/trunk/ r11205: SMP SNMP: 2nd try to handle compiler errors in CentOS 5.3

2011-02-02 Thread Amos Jeffries


The new lib also seems to be missing from unit test linkages.

When the problems here are resolved I think this may be a good places to
use the 'bzr uncommit' ability and re-commit as a single update.

It's usable on trunk under some very narrow conditions:
 * nobody else commits unrelated changes between your fix patches and the
main patch
   ** source formater changes are okay, just cut out any unrelated
alterations and the formater will re-do them later
 * commits by others to assist fixing the patch may be okay to merge, if
the other is happy to loose credit on the sub-fix (speaking for myself
thats fine, I don't care)
 * someone with ability to tweak the website changesets is made aware of
the earliest revno affected. At present that means myself or Henrik if I'm
away.

Amos

Re: not caching ecap munged body

2011-02-02 Thread Jonathan Wolfe

Oops, here's the diff from Alex which I forgot to include below:

=== modified file 'src/adaptation/ecap/MessageRep.cc'
--- src/adaptation/ecap/MessageRep.cc 2010-05-26 03:06:02 +
+++ src/adaptation/ecap/MessageRep.cc 2011-01-26 21:43:36 +
@@ -44,24 +44,30 @@
 void
 Adaptation::Ecap::HeaderRep::add(const Name name, const Value value)
 {
 const http_hdr_type squidId = TranslateHeaderId(name); // HDR_OTHER OK
 HttpHeaderEntry *e = new HttpHeaderEntry(squidId, name.image().c_str(),
 value.toString().c_str());
 theHeader.addEntry(e);
+
+ // XXX: this is too often and not enough, on many levels
+ theMessage.content_length = theHeader.getInt64(HDR_CONTENT_LENGTH);
 }

 void
 Adaptation::Ecap::HeaderRep::removeAny(const Name name)
 {
 const http_hdr_type squidId = TranslateHeaderId(name);
 if (squidId == HDR_OTHER)
 theHeader.delByName(name.image().c_str());
 else
 theHeader.delById(squidId);
+
+ // XXX: this is too often and not enough, on many levels
+ theMessage.content_length = theHeader.getInt64(HDR_CONTENT_LENGTH);
 }

 libecap::Area
 Adaptation::Ecap::HeaderRep::image() const
 {
 MemBuf mb;
 mb.init();


This only works, I think, because when removing Content-Length we end up with a 
-1 in the length for the whole message, instead of the old (too large) content 
length.  (There's a Adaptation::Ecap::XactionRep::setAdaptedBodySize function 
that's commented out in the eCAP support, presumably because it's common to not 
know the length of the final adapted body, like in the gzip case.)

There are a few options - assume the content-length for adapted messages is 
just the total object_len - hdr_sz, leave it always -1 unless the eCAP module 
tells you otherwise by setting the Content-Length header maybe, or finally, 
store it by accumulating the size of returned chunks along the way receiving 
the adapted body and set it accordingly when there's no more adapted body to 
receive.

Any suggestions for the best route to pursue?

Regards,
Jonathan Wolfe

On Jan 26, 2011, at 2:35 PM, Jonathan Wolfe wrote:

 Okay, I narrowed this down a bit more with some help from Alex Rousskov:
 
 When it works (doing a string replace from asdf to fdsa for example, so 
 same total content length):
 
 2011/01/26 16:07:21.312| storeEntryValidLength: Checking 
 '1078B4E8EC1D17CFEBCD533EE19F7FD6'
 2011/01/26 16:07:21.312| storeEntryValidLength: object_len = 20366
 2011/01/26 16:07:21.312| storeEntryValidLength: hdr_sz = 360
 2011/01/26 16:07:21.312| storeEntryValidLength: content_length = 20006
 2011/01/26 16:07:21.317| StoreEntry::setMemStatus: inserted mem node 
 http://www.example.com/squid-test
 
 When it doesn't work (asdf to just a):
 
 2011/01/26 16:05:59.878| storeEntryValidLength: Checking 
 '1078B4E8EC1D17CFEBCD533EE19F7FD6'
 2011/01/26 16:05:59.878| storeEntryValidLength: object_len = 14843
 2011/01/26 16:05:59.878| storeEntryValidLength: hdr_sz = 360
 2011/01/26 16:05:59.878| storeEntryValidLength: content_length = 20006
 2011/01/26 16:05:59.878| storeEntryValidLength: 5523 bytes too small; 
 '1078B4E8EC1D17CFEBCD533EE19F7FD6'
 2011/01/26 16:05:59.879| StoreEntry::checkCachable: NO: wrong content-length
 
 The headers returned in both cases don't actually include a Content-Length 
 header, which is removed by the module using adapted-header().removeAny.
 
 It looks like squid is restoring the content length in the second case, and 
 declaring it too small.
 
 See https://answers.launchpad.net/ecap/+question/142965 for my discussion 
 with Alex on this.  The diff he provided, which is repeated here, seems to 
 have the effect of setting the message content length to -1 when removing the 
 content length header from within the ecap module, and that results in this:
 
 2011/01/26 17:21:46.539| storeEntryValidLength: Checking 
 '1078B4E8EC1D17CFEBCD533EE19F7FD6'
 2011/01/26 17:21:46.539| storeEntryValidLength: object_len = 16190
 2011/01/26 17:21:46.539| storeEntryValidLength: hdr_sz = 360
 2011/01/26 17:21:46.539| storeEntryValidLength: content_length = -1
 2011/01/26 17:21:46.539| storeEntryValidLength: Unspecified content length: 
 1078B4E8EC1D17CFEBCD533EE19F7FD6
 2011/01/26 17:21:46.544| StoreEntry::setMemStatus: inserted mem node 
 http://www.example.com/squid-test
 
 Not the best behavior, but it does cache as expected now.
 
 Likely there's a better place to reset the content length, right?  Perhaps in 
 src/adaptation/ecap/XactionRep.cc, in moveAbContent() when we've received the 
 full adapted body?
 
 Regards,
 -Jon
 
 On Jan 23, 2011, at 8:46 PM, Amos Jeffries wrote:
 
 On 24/01/11 13:43, Henrik Nordström wrote:
 lör 2011-01-22 klockan 23:04 +1300 skrev Amos Jeffries:
 
 Squid caches only one of N variants so the expected behviour is that
 each new variant is a MISS but becomes a HIT on repeated duplicate
 requests until a new variant pushes it out of cache.
 
 No it caches all N variants seen if the origin response has Vary:
 
 But

Re: [squid-users] Re: not caching ecap munged body

2011-02-02 Thread Amos Jeffries

On Wed, 2 Feb 2011 20:09:05 -0800, Jonathan Wolfe wrote:
 Oops, here's the diff from Alex which I forgot to include below:
 
 === modified file 'src/adaptation/ecap/MessageRep.cc'
 --- src/adaptation/ecap/MessageRep.cc 2010-05-26 03:06:02 +
 +++ src/adaptation/ecap/MessageRep.cc 2011-01-26 21:43:36 +
 @@ -44,24 +44,30 @@
  void
  Adaptation::Ecap::HeaderRep::add(const Name name, const Value value)
  {
  const http_hdr_type squidId = TranslateHeaderId(name); // HDR_OTHER
OK
  HttpHeaderEntry *e = new HttpHeaderEntry(squidId,
  name.image().c_str(),
  value.toString().c_str());
  theHeader.addEntry(e);
 +
 + // XXX: this is too often and not enough, on many levels
 + theMessage.content_length = theHeader.getInt64(HDR_CONTENT_LENGTH);
  }
 
  void
  Adaptation::Ecap::HeaderRep::removeAny(const Name name)
  {
  const http_hdr_type squidId = TranslateHeaderId(name);
  if (squidId == HDR_OTHER)
  theHeader.delByName(name.image().c_str());
  else
  theHeader.delById(squidId);
 +
 + // XXX: this is too often and not enough, on many levels
 + theMessage.content_length = theHeader.getInt64(HDR_CONTENT_LENGTH);
  }
 
  libecap::Area
  Adaptation::Ecap::HeaderRep::image() const
  {
  MemBuf mb;
  mb.init();
 
 
 This only works, I think, because when removing Content-Length we end up
 with a -1 in the length for the whole message, instead of the old (too
 large) content length.  (There's a
 Adaptation::Ecap::XactionRep::setAdaptedBodySize function that's
commented
 out in the eCAP support, presumably because it's common to not know the
 length of the final adapted body, like in the gzip case.)


I think that patch should be:

 if (squidId == HDR_CONTENT_LENGTH)
theMessage.content_length = theHeader.getInt64(HDR_CONTENT_LENGTH);

in both places to avoid that too often case.

 
 There are a few options - assume the content-length for adapted messages
 is just the total object_len - hdr_sz, leave it always -1 unless the
eCAP
 module tells you otherwise by setting the Content-Length header maybe,
or
 finally, store it by accumulating the size of returned chunks along the
way
 receiving the adapted body and set it accordingly when there's no more
 adapted body to receive.

We almost always end up with problems caused by large bodies extending
past any possible buffer window. So sending this headers after object
completion is not an available choice.

AFAIK if the adaptor sends its reply with chunked encoding and no
Content-Length header at all it would work out. Squid should handle the
dechunking and connection termination requirements for old clients.

Amos

Re: /bzr/squid3/trunk/ r11205: SMP SNMP: 2nd try to handle compiler errors in CentOS 5.3

2011-02-02 Thread Kinkie

On Thu, Feb 3, 2011 at 3:18 AM, Amos Jeffries squ...@treenet.co.nz wrote:

 The new lib also seems to be missing from unit test linkages.

 When the problems here are resolved I think this may be a good places to
 use the 'bzr uncommit' ability and re-commit as a single update.

Also, matrix builds are now finallty useable in Hudson / Jenkins.
For invasive feature-branches with a public repository, it is now
reasonable to think about requiring greenlight on the build-farm
before merging.
The 3.2-matrix configuration can ben used as a template to build such a test.

-- 
    /kinkie

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #1123

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #1124

dedup fs's?

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #1125

Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #1126

Re: /bzr/squid3/trunk/ r11205: SMP SNMP: 2nd try to handle compiler errors in CentOS 5.3

Re: not caching ecap munged body

Re: [squid-users] Re: not caching ecap munged body

Re: /bzr/squid3/trunk/ r11205: SMP SNMP: 2nd try to handle compiler errors in CentOS 5.3

9 matches

Site Navigation

Mail list logo

Footer information