Hello.
I am at odds with a strange behaviour with 2.5.STABLE3 recent-snapshot
I have a rproxy setup where upstream connections are being kept alive, but
NOT reused.
I added a few debug statements to trace what's going on, and here's the
results:
2003/07/30 00:10:22| fwdConnectStart: host is 10.254.3.26, port is 81, ctimeout
is 120u
2003/07/30 00:10:22| fwdCheckRetriable: Retriable
2003/07/30 00:10:22| pconnPop: key is 10.254.3.26.81
2003/07/30 00:10:22| pconnPop: hptr is 0x817c420
2003/07/30 00:10:22| pconnPop: returning fd 135775264
2003/07/30 00:10:22| fwdConnectStart: not retriable
Now, if hptr is not null, why is the
if (hptr != NULL) {
...
}
branch in pconnPop not taken? It's not a matter of overoptimization, I've
rebuilt at -O0.
Here's the modified pconnPop:
int
pconnPop(const char *host, u_short port)
{
struct _pconn *p;
hash_link *hptr;
int fd = -1;
LOCAL_ARRAY(char, key, SQUIDHOSTNAMELEN + 10);
assert(table != NULL);
strcpy(key, pconnKey(host, port));
debug(17,3)("pconnPop: key is %s\n");
hptr = hash_lookup(table, key);
debug(17,3)("pconnPop: hptr is %p\n");
if (hptr != NULL) {
p = (struct _pconn *) hptr;
assert(p->nfds > 0);
debug(17,3)("pconnPop: nfds=%d\n",p->nfds);
fd = p->fds[0];
debug(17,3)("pconnPop: fd is $d\n",fd);
pconnRemoveFD(p, fd);
commSetSelect(fd, COMM_SELECT_READ, NULL, NULL, 0);
commSetTimeout(fd, -1, NULL, NULL);
}
debug(17,3)("pconnPop: returning fd %d\n");
return fd;
}
Thanks for any hints.
-- kinkie (kinkie-squid [at] kinkie [dot] it) Random fortune, unrelated to the message: If I am elected, the concrete barriers around the WHITE HOUSE will be replaced by tasteful foam replicas of ANN MARGARET!Received on Tue Jul 29 2003 - 13:51:12 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:20:18 MST