Re: Ctx( ): IOException in: R( + /tomcat-power.gif + null) socket w rite error

[Dave Smith <sa...@home.com>]

I get the same error with the same configuration
(NT4/tomcat3.2 standalone). My machine is configured
and working properly, and I have no other problems
related to winsock. So, does anyone know where
this error originates in the code? Is it a tomcat bug?
If so, I'll try and figure out how to do a bug report...

Tomcat 3.2 works fine and serves pages, even SSL
works, but standard out spews this junk on every request.

Thanks for any input,

Dave Smith


----- Original Message -----
From: "Steven Newton" <St...@Qsent.com>
To: <to...@jakarta.apache.org>
Sent: Tuesday, December 12, 2000 1:42 PM
Subject: RE: Ctx( ): IOException in: R( + /tomcat-power.gif + null) socket w
rite error


> > I am running tomcat 3.2 on NT. While trying to access
> > http://localhost/index.html I get the following errors:
> >
> > 2000-12-12 09:27:41 - Ctx(  ): IOException in: R(  +
> > /index.html + null)
> > socket write error (code=10053)
> > 2000-12-12 09:27:41 - Ctx(  ): IOException in: R(  +
> > /tomcat-power.gif +
> > null) socket write error (code=10053)
> >
>
> This is a winsock error.  The below is quoted from
> http://www.sockets.com/err_lst1.htm.
> It's not specifically a Tomcat error.
>
> WSAECONNABORTED (10053) Software caused connection abort.
>
> Berkeley description: A connection abort was caused internal to your host
> machine. The software caused a connection abort because there is no space
on
> the socket's queue and the socket cannot receive further connections.
>
> WinSock description: Partly the same as Berkeley. The error can occur when
> the local network system aborts a connection. This would occur if WinSock
> aborts an established connection after data retransmission fails (receiver
> never acknowledges data sent on a datastream socket).
>
> TCP/IP scenario: A connection will timeout if the local system doesn't
> receive an (ACK)nowledgement for data sent. It would also timeout if a
> (FIN)ish TCP packet is not ACK'd (and even if the FIN is ACK'd, it will
> eventually timeout if a FIN is not returned).
>
> User suggestions: There are a number of things to check, that might help
to
> identify why the failure occurred. Basically, you want to identify where
the
> problem occurred.
> Ping the remote host you were connected to. If it doesn't respond, it
might
> be off-line or there may be a network problem along the way. If it does
> respond, then this problem might have been a transient one (so you can
> reconnect now), or the server application you were connected to might have
> terminated (so you might not be able to connect again).
> Ping a local host to verify that your local network is still functioning
(if
> on a serial connection, see next step)
> Ping your local router address. If you're on a serial connection, your
local
> router is the IP address of the host you initially logged onto with SLIP
or
> PPP.
> Ping a host on the same subnet as the host you were connected to (if you
> know one). This will verify that the destination network is functioning.
> Try a "traceroute" to the host you were connected to. This won't reveal
too
> much unless you know the router addresses at the remote end, but it might
> help to identify if the problem is somewhere along the way.
>
> WinSock functions: recv(), recvfrom(), sendto(), FD_CLOSE
>
> Additional functions: send() can also fail with WSAECONNABORTED. Any
> function that takes a socket as an input parameter--except close
> socket()--could potentially fail with this error.
>
> See also: WSAECONNRESET, WSAENETRESET, WSAETIMEDOUT