Hi Guys,
 I'm running RedBack 4.1.3.2.on HP-UX 11. My question is has anyone had the
experience of RedBack stopping at irregular intervals -when I mean  and when
you look in the rgw.log files there is an error code of 239 stating
connection refused. I'm wondering if this has something to do with time
outs? I don't know too much about RedBack as we only have just started using
it for our online forms.
A couple of months ago I found the redback responders (which are Universe
sessions) were taking up a hell of a lot of CPU usage even in sleep mode -
this was rectified by stopping the GARBAGE.COLLECT and using other means to
empty the WWLOG and WWSTATE files.

Much appreciated...

Cheers  Pedds :  )

connect <pamato@ultradata.com.au> wrote:
>  I'm running RedBack 4.1.3.2.on HP-UX 11. My question is has anyone
> had the experience of RedBack stopping at irregular intervals -when
> I mean and when you look in the rgw.log files there is an error code
> of 239 stating connection refused. I'm wondering if this has
> something to do with time outs? I don't know too much about RedBack
> as we only have just started using it for our online forms.

I know nothing about RedBack, but a 239 ECONNREFUSED typically implies
a connection attempt was made and actively rejected rather than
timing-out.  A timeout on a connection attempt would be an errno 238
ETIMEDOUT.

Given there is no way for a sockets application to cause a RST to be
sent in response to a SYN (connection request), an ECONNREFUSED can
often mean that an attempt was made to connect to a port on a remote
system for which there was no listener, or perhaps the request was
intercepted and terminated with extremem predjudice by a firewall.  It
may also be possible, however very unlikely, that the SYN segment
itself was somehow unliked by the remote TCP.

Ideally, the software would log useful things like the remote IP
address and port number it had passed in the call to connect() that
got the ECONNREFUSED.  Of course, most software is far from ideal.

In the less than ideal world... If these things are happening
frequently enough that you are concerned, and you happen to have a bit
of spare CPU cycles left on the system running the redback bits, you
could consider running tcpdump on the interface(s) being used and set
a filter expression that only captured RST segments.  If you included
an apropriate timestamp format (check the tcpdump manpage after you
install it via HP Internet Express or compilation from sources at
www.tcpdump.org) you could correlate the tcpdump trace with the
redback error log and extract the IP address and port number from the
RST segment. (They will be the source IP and port in this case)

Or, I suppose you could use tusc to system call trace the redback
bits, but that might be even more overhead. Even perhaps if you
configured it to only trace calls to connect().

rick jones
-- 
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...

Rick Jones wrote:
> connect <pamato@ultradata.com.au> wrote:
> 
>> I'm running RedBack 4.1.3.2.on HP-UX 11. My question is has anyone
>>had the experience of RedBack stopping at irregular intervals -when
>>I mean and when you look in the rgw.log files there is an error code
>>of 239 stating connection refused. I'm wondering if this has
>>something to do with time outs? I don't know too much about RedBack
>>as we only have just started using it for our online forms.
> 
> 
> I know nothing about RedBack, but a 239 ECONNREFUSED typically implies
> a connection attempt was made and actively rejected rather than
> timing-out.  A timeout on a connection attempt would be an errno 238
> ETIMEDOUT.
> 
> Given there is no way for a sockets application to cause a RST to be
> sent in response to a SYN (connection request), an ECONNREFUSED can
> often mean that an attempt was made to connect to a port on a remote
> system for which there was no listener, or perhaps the request was
> intercepted and terminated with extremem predjudice by a firewall.  It
> may also be possible, however very unlikely, that the SYN segment
> itself was somehow unliked by the remote TCP.
> 
> Ideally, the software would log useful things like the remote IP
> address and port number it had passed in the call to connect() that
> got the ECONNREFUSED.  Of course, most software is far from ideal.
> 
> In the less than ideal world... If these things are happening
> frequently enough that you are concerned, and you happen to have a bit
> of spare CPU cycles left on the system running the redback bits, you
> could consider running tcpdump on the interface(s) being used and set
> a filter expression that only captured RST segments.  If you included
> an apropriate timestamp format (check the tcpdump manpage after you
> install it via HP Internet Express or compilation from sources at
> www.tcpdump.org) you could correlate the tcpdump trace with the
> redback error log and extract the IP address and port number from the
> RST segment. (They will be the source IP and port in this case)
> 
> Or, I suppose you could use tusc to system call trace the redback
> bits, but that might be even more overhead. Even perhaps if you
> configured it to only trace calls to connect().
> 
> rick jones
good shot rick