tcp reset problem with varnish 2.0.4 o n Solaris 10 (SPARC)

[Alex Hooper]

Ken Brownfield uttered:
> Your tcpdump seems to imply that there's an immediate timeout on the
> connection.  Do the timeouts (and other settings) emitted from
> "varnishadm -T :6082 param.show" all have sane values?
> 

As far as I can tell...:

accept_fd_holdoff          50 [ms]
acceptor                   default (ports, poll)
auto_restart               on [bool]
backend_http11             on [bool]
between_bytes_timeout      60.000000 [s]
cache_vbe_conns            off [bool]
cc_command                 "cc -Kpic -G -o %o %s"
cli_buffer                 8192 [bytes]
cli_timeout                5 [seconds]
client_http11              off [bool]
clock_skew                 10 [s]
connect_timeout            5.000000 [s]
default_grace              10
default_ttl                120 [seconds]
diag_bitmap                0x0 [bitmap]
err_ttl                    0 [seconds]
esi_syntax                 0 [bitmap]
fetch_chunksize            128 [kilobytes]
first_byte_timeout         60.000000 [s]
group                      nobody (60001)
listen_address             :80
listen_depth               1024 [connections]
log_hashstring             off [bool]
log_local_address          off [bool]
lru_interval               2 [seconds]
max_esi_includes           5 [includes]
max_restarts               4 [restarts]
obj_workspace              8192 [bytes]
overflow_max               100 [%]
ping_interval              3 [seconds]
pipe_timeout               60 [seconds]
prefer_ipv6                off [bool]
purge_dups                 off [bool]
purge_hash                 on [bool]
rush_exponent              3 [requests per request]
send_timeout               600 [seconds]
sess_timeout               5 [seconds]
sess_workspace             16384 [bytes]
session_linger             0 [ms]
shm_reclen                 255 [bytes]
shm_workspace              8192 [bytes]
srcaddr_hash               1049 [buckets]
srcaddr_ttl                30 [seconds]
thread_pool_add_delay      20 [milliseconds]
thread_pool_add_threshold  2 [requests]
thread_pool_fail_delay     200 [milliseconds]
thread_pool_max            500 [threads]
thread_pool_min            5 [threads]
thread_pool_purge_delay    1000 [milliseconds]
thread_pool_timeout        300 [seconds]
thread_pools               2 [pools]
user                       nobody (60001)
vcl_trace                  off [bool]


I did note this in config.log; not sure if it implies the kind of
problem I'm seeing:

configure:19586: checking whether SO_SNDTIMEO works
configure:19629: gcc -std=gnu99 -o conftest -g -O2   conftest.c  >&5
Undefined                       first referenced
 symbol                             in file
socket                              /var/tmp//ccKa38Tg.o
setsockopt                          /var/tmp//ccKa38Tg.o
ld: fatal: Symbol referencing errors. No output written to conftest
...
configure:19673: WARNING: connection timeouts will not work


> You might also experiment by adding a probe to your backend, to see if
> the probes pass.
> 

They show as sick, with the same reset symptom in tcpdump.

> Otherwise, I guess I'd suspect an issue with compilation.  They say
> Varnish only supports gcc (which might not be strictly true, but I'll
> bet it's not tested under the Sun compiler).  What was the isfinite()
> issue?

The same as that reported at
http://varnish.projects.linpro.no/ticket/464. Actually, having re-tried,
I can get around the isfinite() issue with the provided patch, but am
caught by the second issue with NAN. I get:


gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../include
-DVARNISH_STATE_DIR='"/local/var/varnish"' -g -O2 -MT
varnishd-cache_center.o -MD -MP -MF .deps/varnishd-cache_center.Tpo -c
-o varnishd-cache_center.o `test -f 'cache_center.c' || echo
'./'`cache_center.c
cache_center.c: In function `cnt_done':
cache_center.c:234: error: incompatible types in assignment
cache_center.c:241: error: incompatible types in assignment
*** Error code 1

It's starting to look as though there may be a few too many issues with
Varnish on Solaris currently. I'll keep trying to resolve, but time
issues may force me to fall back to squid for the moment.

Cheers,

Alex.
-- 
Alex Hooper                           |  <w> www.bmjpg.com
Systems and Database Administration   |  <e> ahooper at bmjgroup.com
BMJ Technology, BMJ Publishing Group  |  <t> +44 20 7383 6049
BMA House, LONDON, WC1H 9JR           |



_______________________________________________________________________
The BMJ Group is one of the world's most trusted providers of medical information for doctors, researchers, health care workers and patients www.bmjgroup.bmj.com.  This email and any attachments are confidential.  If you have received this email in error, please delete it and kindly notify us.  If the email contains personal views then the BMJ Group accepts no responsibility for these statements.  The recipient should check this email and attachments for viruses because the BMJ Group accepts no liability for any damage caused by viruses.  Emails sent or received by the BMJ Group may be monitored for size, traffic, distribution and content.  BMJ Publishing Group Limited trading as BMJ Group.  A private limited company, registered in England and Wales under registration number 03102371.  Registered office: BMA House, Tavistock Square, London WC1H 9JR, UK.
_______________________________________________________________________