Re: [PATCH] Cleanup comm connection setup layering

[Amos Jeffries]

Alex Rousskov wrote:

On 06/09/2010 05:44 AM, Amos Jeffries wrote:

(since last submission I've implemented most of Alex suggestions



At the design level, the following problems need to be addressed, IMO:

Connection dual-use: Replace unconnected connections with some sort of
connection destination class and use it to configure the connection
opener (ConnectStateData) object for solo and paths cases. The
connection opener should return a single working Connection object on
success (among other things).


Um, one of the middling-important goals here is to reduce copying of the 
comm data properties from one alloc'd object to another and stack. 
Preserving the handles (refcount pointer) already stored by callers 
(FTP, DNS for starters).
 I'm happy to make a typedef to differentiate the scopes for 
readability. Though it seems to me that will just make more complexity.




ConnectStateData nature: The connection opener class should become an
AsyncJob and treated as such because it is.


Okay. Underway.



Either separate or merge single- and multi-destination cases in
ConnectStateData: The current code still merges some but not all
"single-destination" code with "handling one of the multi-destinations"
code, resulting in bugs. We should fully merge the two similar cases.


Specific questions, suggestions, and lower-level comments are below.



Done. Dropped multi-path code from comm layer.
Forwarding has retryOrBail logics that are used to restart an early 
aborted paths. Just re-using that to loop over the vector for 
single-path opening attempts looks okay.

Building and will need to re-test later.




Peer selection has been extended to do DNS lookups on the peers chosen
for forwarding to and produce a vector<> of possible connection
endpoints (squid local IP via tcp_outgoing_address or tproxy) and remote
server.

ConnectStateData has been moved into src/comm/ (not yet namespaced) and
had all its DNS lookup operations dropped. To be replaced by a looping
process of attempting to open a socket and join a link as described by
some Comm::Connection or vector<> of same.
 Limited by connect_timeout in its running time.
 Extended by connect_retries number of attempts to open each path.


Can ConnectStateData handle DNS lookups? Does the peer selection
algorithm need tight control over those lookups before we try to open a
connection to a peer?


No, ConnectStateData doing its own DNS was the v4/v6 block on 
split-stack IPv6 support for BSD. It blocks outgoing address selection 
based on higher scoped HttpRequest details.


Pre-seeded peer DNS results would probably be a better performance boost 
than doing new lookups each time. I've not found it to be a particularly 
slow lookup, since the peers are most certain to be static or constantly 
looked up the DNS is kept fresh in ipcache.





ConnectStateData::connect() will go away and do some async work. Will
come back at some point by calling the handler with COMM_OK,
COMM_ERR_CONNECT, COMM_TIMEOUT and ptrs to the Comm::Connection or
vector (whichever were passed in).
 On COMM_OK the Comm::ConnectionPointer or the first entry of the vector
will be an open Comm::ConnectionPointer which we can now use.
 On COMM_ERR_CONNECT the vector will be empty (all tried and
discarded),  the single Comm::ConnectionPointer will be !isOpen() or NULL.
 On COMM_TIMEOUT their content is as per COMM_ERR_CONNECT but the vector
may have untried paths still present but closed.

FD opening, FD problems, connection errors, timeouts, early remote
TCP_RST or NACK closure during the setup are all now wrapped out of
sight inside ConnectStateData.


Who is responsible for closing the opened connection descriptor if the
requestor disappears?

The old requestor code could close the FD on job exit because it had
access to the descriptor. With the new code, the descriptor should not
be available to the requestor until the connection is established.

[ I would appreciate if we do not argue exactly which requestors may
disappear -- it is bound to happen sooner or later, and I am tired of
fixing hard-to-find bugs in the code that simply assumed otherwise
because it seemed safe at the time. Let's at least write the new code
the right way. If it is an async job, we should never assume it is
around after AsyncStart. ]


Yes. 100% agreed.

If the requestor disappears and everything goes pear shaped the 
Comm::Connection has just enough smarts to close the FD and prevent 
leaks in its own destructor.


In the case where the original requestor has died then ConnectStateData 
or dialer parameter details is left the only holder of the 
ConnectionPointer and FD closure will be actioned when that state gets 
dropped by the dialer.


We still have the case where an object holding a Comm::Connection 
pointer leaks at a higher level. But there is nothing extra comm can do 
about that.




* Comm::Connection assignment operator does not handle assignment to
self. Please either fix the operator or make the assi

Hudson build is back to normal: 3.HEAD-i386-FreeBSD-6.4 #358

[noc]

See 

Re: [DRAFT][MERGE] Cleanup comm outgoing connections in trunk

[Amos Jeffries]

Alex Rousskov wrote:

On 05/24/2010 03:46 AM, Amos Jeffries wrote:

Alex Rousskov wrote:

* Comm::Connection copy constructor does not copy peer correctly OR
Comm::Connection destructor does not clean peer correctly. It may be a
good idea to hide peer_ from public use to ensure it is always
locked/unlocked properly.

Okay. Fixed the constructors and hidden the _peer variable behind
accessors.
 One thing though, the set accessor can do cbdata ops fine, is it okay
for the retrieve acessor to just return the ptr? leaving
cbdataReference*( x.peer() ) to the calling code?


Yes, it is OK. The object storing a pointer should lock/unlock it as
needed. Accessors should not do that if they just return what was
already stored.



Which is preferred in this case where the paths is only valid as
long as FwdStateData exists? RefCounted or cbdataReference?


I prefer RefCounted if you do not need to separate "valid" from
"allocated". Looks like that is what your second revision implements.



dialer makes sure the object being dialed still exists, or drops the
call. Am I correct?


You are correct. However, when the Call object stores something, we need
to be careful that this "something" is still valid when the Call object
accesses it. For example, a Call or Dialer object should not print a
call argument for debugging if that argument may be invalid. This is a
general answer to a general question; not specific to your changes.



I may have overlooked somewhere where FwdStateData could be deleted by
operations parallel to FwdStateData::start(). Though I believe if that
is possible we have a terribly huge race bug somewhere.



AsyncJobs should be started using AsyncStart() which never fails. Any
failures inside AsyncJob::start() should be no different from failures
inside any other part of the job that is executed asynchronously because
the initiator code does not really know when start() will be executed.

IIRC, we violate the AsyncStart rule in client_side*.cc (at least).

Again, general answer here, not specific to your code.



* Please remove ConnectStateData solo connections as
exceptional/different code path. It has already bitten you (see below).
One alternative is to create paths with a single connection instead
(inside the solo constructor which will be the only solo-specific code
then). Another alternative is to add path/solo access methods that hide
the difference from the rest of the ConnectStateData code without the
Paths creation overhead.

This was the first model I started with. It runs onto severe problems
with connections such as Ident, slow ACL, and DNS where there is no
state object to hold the authoritive lifetime of the paths vector.


Neither of the two proposed solutions assume the presence of such an
object (other than ConnectStateData object itself).


Its also terribly inefficient allocating a vector, adding the single
Comm::Connection object and pushing it, having comm navigate through
extra API layers to validate its presence then access it.


The second solution does not allocate a vector.



You will have to straighten me out on this but I think it may be needed
by ICAP Xaction when the ICAP is configured with a service name (DNS
lookup plus vector of destinations assembled) instead of IP address
(singleton).


Not sure. Do "paths" stand for multiple IP addresses with a single DNS
name? AFAICT, it is not documented or, to be more precise, the paths
members are documented as being ... paths.


They can do. Paths is at the IP level below the name level of DNS, so 
one DNS result in multiple potential connection paths.


We don't yet expand the outgoingAddr set for each of those destinations, 
but the potential is becoming present to do so in future.






* Whenever possible, please declare Pointer parameters and Pointer
return types as const references to avoid unnecessary locking/unlocking.


Unfortunately its not easy to set const on the volatile Comm::Connection
objects in outbound connection handling. They get created as
might-be-used objects and released on failures. Activating one will
shortly result in Comm updating it's properties (transforming wildcard
IP to specific on-link IPs etc).


I was not talking about that. I will try to be more specific in the next
review email.



* We now have ConnectStateData and ConnStateData public classes.
StateData suffix is already wonderfully descriptive, but this brings
confusion to the next level.

Aye. I'm slowly working through comm.cc figuring out what bits are used
by which side. ConnStateData will hopefully get a better descriptive
name when its scope is clearly known.



Let's solve this by renaming ConnectStateData instead. I believe you
already defined ConnStateData scope. With some polishing touches I would
restate it as:

/// Async-opener of a Comm connection.
/// Can find the first "working" among multiple destinations.

If you agree with the above scope, let's s/ConnectStateData/ConnOpener/g



I think the primary reason for most

Build failed in Hudson: 3.HEAD-i386-opensolaris-SunStudioCc #295

[noc]

See 


Changes:

[Automatic source maintenance ] Bootstrapped

[Amos Jeffries ] Author: Matthias Pitzl 

Bug 2967: raw-IPv6 address URL with append_domain broken

--
[...truncated 4509 lines...]
source='../../../../helpers/basic_auth/MSNT/smblib.c' object='smblib.o' 
libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g -c 
../../../../helpers/basic_auth/MSNT/smblib.c
source='../../../../helpers/basic_auth/MSNT/valid.c' object='valid.o' 
libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g -c 
../../../../helpers/basic_auth/MSNT/valid.c
source='../../../../helpers/basic_auth/MSNT/denyusers.c' object='denyusers.o' 
libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g -c 
../../../../helpers/basic_auth/MSNT/denyusers.c
source='../../../../helpers/basic_auth/MSNT/allowusers.c' object='allowusers.o' 
libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g -c 
../../../../helpers/basic_auth/MSNT/allowusers.c
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g 
-DSYSCONFDIR=\"
 -c ../../../../helpers/basic_auth/MSNT/confload.c -o confload.o
source='../../../../helpers/basic_auth/MSNT/usersfile.c' object='usersfile.o' 
libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g -c 
../../../../helpers/basic_auth/MSNT/usersfile.c
/bin/sh ../../../libtool --tag=CC   --mode=link ccache 
/opt/SunStudioExpress/prod/bin/cc -D_REENTRANT -g  
-L/usr/local/sunstudio-libs/lib -o msnt_auth md4.o rfcnb-io.o rfcnb-util.o 
session.o msntauth.o smbdes.o smbencrypt.o smblib-util.o smblib.o valid.o 
denyusers.o allowusers.o confload.o usersfile.o -L../../../lib -lmiscutil 
../../../compat/libcompat.la -lm -lsocket -lresolv -lnsl -lsocket 
libtool: link: ccache /opt/SunStudioExpress/prod/bin/cc -D_REENTRANT -g -o 
msnt_auth md4.o rfcnb-io.o rfcnb-util.o session.o msntauth.o smbdes.o 
smbencrypt.o smblib-util.o smblib.o valid.o denyusers.o allowusers.o confload.o 
usersfile.o  -L/usr/local/sunstudio-libs/lib 
-L
 -lmiscutil ../../../compat/.libs/libcompat.a -lm -lresolv -lnsl -lsocket
make[4]: Leaving directory 
`
Making all in MSNT-multi-domain
make[4]: Entering directory 
`
sed -e 's,[...@]perl[@],/usr/bin/perl,g' 
<../../../../helpers/basic_auth/MSNT-multi-domain/basic_msnt_multi_domain_auth.pl.in
 >basic_msnt_multi_domain_auth || (/usr/gnu/bin/rm -f -f 
basic_msnt_multi_domain_auth ; exit 1)
make[4]: Leaving directory 
`

Re: Caching of the POST messages

[Alex Rousskov]

On 06/24/2010 07:51 AM, Henrik Nordström wrote:
> ons 2010-06-23 klockan 07:36 -0500 skrev Sandeep Kuttal:
> 
>> I am looking for changing the Squid code little bit to cache POST
>> messages.
> 
> caching POST messages in Squid is hard to implement due to Squid not
> buffering the POST body before forwarding the request.

Actually, we do buffer the body of chunked requests, for now. So there
is working code that can be used as a starting point.

Alex.

Re: [DRAFT][MERGE] Cleanup comm outgoing connections in trunk

[Alex Rousskov]

On 05/24/2010 03:46 AM, Amos Jeffries wrote:
> Alex Rousskov wrote:
>> * Comm::Connection copy constructor does not copy peer correctly OR
>> Comm::Connection destructor does not clean peer correctly. It may be a
>> good idea to hide peer_ from public use to ensure it is always
>> locked/unlocked properly.
> 
> Okay. Fixed the constructors and hidden the _peer variable behind
> accessors.
>  One thing though, the set accessor can do cbdata ops fine, is it okay
> for the retrieve acessor to just return the ptr? leaving
> cbdataReference*( x.peer() ) to the calling code?

Yes, it is OK. The object storing a pointer should lock/unlock it as
needed. Accessors should not do that if they just return what was
already stored.


> Which is preferred in this case where the paths is only valid as
> long as FwdStateData exists? RefCounted or cbdataReference?

I prefer RefCounted if you do not need to separate "valid" from
"allocated". Looks like that is what your second revision implements.


> dialer makes sure the object being dialed still exists, or drops the
> call. Am I correct?

You are correct. However, when the Call object stores something, we need
to be careful that this "something" is still valid when the Call object
accesses it. For example, a Call or Dialer object should not print a
call argument for debugging if that argument may be invalid. This is a
general answer to a general question; not specific to your changes.


> I may have overlooked somewhere where FwdStateData could be deleted by
> operations parallel to FwdStateData::start(). Though I believe if that
> is possible we have a terribly huge race bug somewhere.


AsyncJobs should be started using AsyncStart() which never fails. Any
failures inside AsyncJob::start() should be no different from failures
inside any other part of the job that is executed asynchronously because
the initiator code does not really know when start() will be executed.

IIRC, we violate the AsyncStart rule in client_side*.cc (at least).

Again, general answer here, not specific to your code.


>> * Please remove ConnectStateData solo connections as
>> exceptional/different code path. It has already bitten you (see below).
>> One alternative is to create paths with a single connection instead
>> (inside the solo constructor which will be the only solo-specific code
>> then). Another alternative is to add path/solo access methods that hide
>> the difference from the rest of the ConnectStateData code without the
>> Paths creation overhead.
> 
> This was the first model I started with. It runs onto severe problems
> with connections such as Ident, slow ACL, and DNS where there is no
> state object to hold the authoritive lifetime of the paths vector.

Neither of the two proposed solutions assume the presence of such an
object (other than ConnectStateData object itself).

> Its also terribly inefficient allocating a vector, adding the single
> Comm::Connection object and pushing it, having comm navigate through
> extra API layers to validate its presence then access it.

The second solution does not allocate a vector.


> You will have to straighten me out on this but I think it may be needed
> by ICAP Xaction when the ICAP is configured with a service name (DNS
> lookup plus vector of destinations assembled) instead of IP address
> (singleton).

Not sure. Do "paths" stand for multiple IP addresses with a single DNS
name? AFAICT, it is not documented or, to be more precise, the paths
members are documented as being ... paths.


>> * Whenever possible, please declare Pointer parameters and Pointer
>> return types as const references to avoid unnecessary locking/unlocking.
>>
> 
> Unfortunately its not easy to set const on the volatile Comm::Connection
> objects in outbound connection handling. They get created as
> might-be-used objects and released on failures. Activating one will
> shortly result in Comm updating it's properties (transforming wildcard
> IP to specific on-link IPs etc).

I was not talking about that. I will try to be more specific in the next
review email.


>> * We now have ConnectStateData and ConnStateData public classes.
>> StateData suffix is already wonderfully descriptive, but this brings
>> confusion to the next level.
> 
> Aye. I'm slowly working through comm.cc figuring out what bits are used
> by which side. ConnStateData will hopefully get a better descriptive
> name when its scope is clearly known.


Let's solve this by renaming ConnectStateData instead. I believe you
already defined ConnStateData scope. With some polishing touches I would
restate it as:

/// Async-opener of a Comm connection.
/// Can find the first "working" among multiple destinations.

If you agree with the above scope, let's s/ConnectStateData/ConnOpener/g


>> I think the primary reason for most of these problems is that the new
>> Connection class has dual personality. It is both holds the information
>> necessary to establish a connection _and_ the established connection
>> 

Re: [PATCH] Cleanup comm connection setup layering

[Alex Rousskov]

On 06/09/2010 05:44 AM, Amos Jeffries wrote:
> (since last submission I've implemented most of Alex suggestions


At the design level, the following problems need to be addressed, IMO:

Connection dual-use: Replace unconnected connections with some sort of
connection destination class and use it to configure the connection
opener (ConnectStateData) object for solo and paths cases. The
connection opener should return a single working Connection object on
success (among other things).

ConnectStateData nature: The connection opener class should become an
AsyncJob and treated as such because it is.

Either separate or merge single- and multi-destination cases in
ConnectStateData: The current code still merges some but not all
"single-destination" code with "handling one of the multi-destinations"
code, resulting in bugs. We should fully merge the two similar cases.


Specific questions, suggestions, and lower-level comments are below.


> Peer selection has been extended to do DNS lookups on the peers chosen
> for forwarding to and produce a vector<> of possible connection
> endpoints (squid local IP via tcp_outgoing_address or tproxy) and remote
> server.
> 
> ConnectStateData has been moved into src/comm/ (not yet namespaced) and
> had all its DNS lookup operations dropped. To be replaced by a looping
> process of attempting to open a socket and join a link as described by
> some Comm::Connection or vector<> of same.
>  Limited by connect_timeout in its running time.
>  Extended by connect_retries number of attempts to open each path.

Can ConnectStateData handle DNS lookups? Does the peer selection
algorithm need tight control over those lookups before we try to open a
connection to a peer?


> ConnectStateData::connect() will go away and do some async work. Will
> come back at some point by calling the handler with COMM_OK,
> COMM_ERR_CONNECT, COMM_TIMEOUT and ptrs to the Comm::Connection or
> vector (whichever were passed in).
>  On COMM_OK the Comm::ConnectionPointer or the first entry of the vector
> will be an open Comm::ConnectionPointer which we can now use.
>  On COMM_ERR_CONNECT the vector will be empty (all tried and
> discarded),  the single Comm::ConnectionPointer will be !isOpen() or NULL.
>  On COMM_TIMEOUT their content is as per COMM_ERR_CONNECT but the vector
> may have untried paths still present but closed.
> 
> FD opening, FD problems, connection errors, timeouts, early remote
> TCP_RST or NACK closure during the setup are all now wrapped out of
> sight inside ConnectStateData.

Who is responsible for closing the opened connection descriptor if the
requestor disappears?

The old requestor code could close the FD on job exit because it had
access to the descriptor. With the new code, the descriptor should not
be available to the requestor until the connection is established.

[ I would appreciate if we do not argue exactly which requestors may
disappear -- it is bound to happen sooner or later, and I am tired of
fixing hard-to-find bugs in the code that simply assumed otherwise
because it seemed safe at the time. Let's at least write the new code
the right way. If it is an async job, we should never assume it is
around after AsyncStart. ]


* Comm::Connection assignment operator does not handle assignment to
self. Please either fix the operator or make the assignment impossible
(if it is not needed).

* Comm::Connection assignment operator should return non-const reference
to follow typical C/C++ assignment expectations.


* Do we really need to support Comm::Connection copying and assignment?
Seems like a very dangerous operation given the fact that Connection
closes it descriptor upon destruction. For example, the following code
is currently possible but is totally wrong:

  void foo(Connection c) { ... }

  Connection c;
  c.fd = openex...
  foo(c);

If we do not use Comm::Connection copying and assignment now, I would
strongly recommend prohibiting it. Otherwise, please point me to the
code that does.

* Do you plan on converting idle pconn pools to use Comm::Connection?


* Please use "const reference" types for Pointer methods parameters by
default. This avoids needless locking/unlocking during parameter
copying. For example,

ConnectStateData(Comm::PathsPointer paths, AsyncCall::Pointer handler)

can be optimized as

ConnectStateData(const Comm::PathsPointer &paths, const
AsyncCall::Pointer &handler)


* Do not free the host before deleting self because the destructor will
do it for you:

> callback = NULL;
> safe_free(host);
> delete this;


* The ConnectStateData code still has slightly different code executed
for solo and path cases, code where solo/path decision is tested in
slightly different ways, etc.

I have already commented on that and you responded that fixing this bug
is too inefficient. I disagree. There is no need to allocate paths if
they are not used.

If you provide a simple currentDestination() accessor for the current
path/solo destination and a goin

Re: Caching of the POST messages

[Mark Nottingham]

...although there is a patch for this in squid2-HEAD. It buffers to memory, 
though, not disk.


On 24/06/2010, at 6:51 AM, Henrik Nordström wrote:

> ons 2010-06-23 klockan 07:36 -0500 skrev Sandeep Kuttal:
> 
>> I am looking for changing the Squid code little bit to cache POST
>> messages.
> 
> caching POST messages in Squid is hard to implement due to Squid not
> buffering the POST body before forwarding the request.
> 
> Regards
> Henrik
> 

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

Build failed in Hudson: 3.HEAD-i386-opensolaris-SunStudioCc #294

[noc]

See 


Changes:

[Amos Jeffries ] Author: Matthias Pitzl 

Bug 2967: raw-IPv6 address URL with append_domain broken

[Amos Jeffries ] Author: Sean Critica 

Bug 2903: does not send X-Client-Ip in ICAP respmod

--
[...truncated 4511 lines...]
source='../../../../helpers/basic_auth/MSNT/smblib.c' object='smblib.o' 
libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g -c 
../../../../helpers/basic_auth/MSNT/smblib.c
source='../../../../helpers/basic_auth/MSNT/valid.c' object='valid.o' 
libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g -c 
../../../../helpers/basic_auth/MSNT/valid.c
source='../../../../helpers/basic_auth/MSNT/denyusers.c' object='denyusers.o' 
libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g -c 
../../../../helpers/basic_auth/MSNT/denyusers.c
source='../../../../helpers/basic_auth/MSNT/allowusers.c' object='allowusers.o' 
libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g -c 
../../../../helpers/basic_auth/MSNT/allowusers.c
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g 
-DSYSCONFDIR=\"
 -c ../../../../helpers/basic_auth/MSNT/confload.c -o confload.o
source='../../../../helpers/basic_auth/MSNT/usersfile.c' object='usersfile.o' 
libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../../cfgaux/depcomp \
ccache /opt/SunStudioExpress/prod/bin/cc -DHAVE_CONFIG_H  -I../../../.. 
-I../../../../include -I../../../../src -I../../../include -I/usr/local/include 
-I/usr/include/gssapi -I/usr/include/kerberosv5 
-I../../../../helpers/basic_auth/MSNT  -I/usr/include/gssapi 
-I/usr/include/kerberosv5 -D_REENTRANT -g -c 
../../../../helpers/basic_auth/MSNT/usersfile.c
/bin/sh ../../../libtool --tag=CC   --mode=link ccache 
/opt/SunStudioExpress/prod/bin/cc -D_REENTRANT -g  
-L/usr/local/sunstudio-libs/lib -o msnt_auth md4.o rfcnb-io.o rfcnb-util.o 
session.o msntauth.o smbdes.o smbencrypt.o smblib-util.o smblib.o valid.o 
denyusers.o allowusers.o confload.o usersfile.o -L../../../lib -lmiscutil 
../../../compat/libcompat.la -lm -lsocket -lresolv -lnsl -lsocket 
libtool: link: ccache /opt/SunStudioExpress/prod/bin/cc -D_REENTRANT -g -o 
msnt_auth md4.o rfcnb-io.o rfcnb-util.o session.o msntauth.o smbdes.o 
smbencrypt.o smblib-util.o smblib.o valid.o denyusers.o allowusers.o confload.o 
usersfile.o  -L/usr/local/sunstudio-libs/lib 
-L
 -lmiscutil ../../../compat/.libs/libcompat.a -lm -lresolv -lnsl -lsocket
make[4]: Leaving directory 
`
Making all in MSNT-multi-domain
make[4]: Entering directory 
`
sed -e 's,[...@]perl[@],/usr/bin/perl,g' 
<../../../../helpers/basic_auth/MSNT-multi-domain/basic_msnt_multi_domain_auth.pl.in
 >basic_msnt_multi_domain_auth || (/usr/gnu/bin/rm -f -f 
basic_msnt_multi_domain_auth ; exit 1)
make[4]:

Re: Caching of the POST messages

[Henrik Nordström]

ons 2010-06-23 klockan 07:36 -0500 skrev Sandeep Kuttal:

> I am looking for changing the Squid code little bit to cache POST
> messages.

caching POST messages in Squid is hard to implement due to Squid not
buffering the POST body before forwarding the request.

Regards
Henrik

Build failed in Hudson: 3.HEAD-i386-FreeBSD-6.4 #356

[noc]

See 

Changes:

[Amos Jeffries ] Author: Sean Critica 

Bug 2903: does not send X-Client-Ip in ICAP respmod

[Automatic source maintenance ] SourceFormat 
Enforcement

--
Started by upstream project "3.HEAD-amd64-CentOS-5.3" build number 606
Building remotely on west
http://bzr.squid-cache.org/bzr/squid3/trunk is permanently redirected to 
http://bzr.squid-cache.org/bzr/squid3/trunk/
 M  src/HttpRequest.cc
All changes applied successfully.
Now on revision 10572.
FATAL: Unable to produce a script file
hudson.util.IOException2: Failed to create a temp file on 

at hudson.FilePath.createTextTempFile(FilePath.java:893)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:577)
at hudson.model.Build$RunnerImpl.build(Build.java:165)
at hudson.model.Build$RunnerImpl.doRun(Build.java:133)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:417)
at hudson.model.Run.run(Run.java:1176)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:123)
Caused by: hudson.util.IOException2: remote file operation failed
at hudson.FilePath.act(FilePath.java:677)
at hudson.FilePath.act(FilePath.java:665)
at hudson.FilePath.createTextTempFile(FilePath.java:871)
... 11 more
Caused by: java.io.IOException: No space left on device
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:260)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:297)
at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:130)
at java.io.OutputStreamWriter.close(OutputStreamWriter.java:216)
at hudson.FilePath$12.invoke(FilePath.java:887)
at hudson.FilePath$12.invoke(FilePath.java:871)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2072)
at hudson.remoting.UserRequest.perform(UserRequest.java:104)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)