To avoid thecosmetic ugliness, you can change the level of debug for the log
in the tomcat server.xml file.  The default setting is INFORMATION.  This is
a good setting for development but in production I would recommend putting
it to ERROR. See the comments in Tomcat's server.xml file for more info.

-----Original Message-----
From: Szlapa, Michael [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 28, 2001 06:52
To: '[EMAIL PROTECTED]'
Subject: RE: Bug in tomcat or the JDK (testing it on 1.2.2)


That is not the bug. It's a feature ;-). 

When your browser realizes that it already has a copy of given file in
browser cache, it abruptly closes the connection in order not to waste time
and bandwidth. This causes exception on the server (tomcat) side of the
connection. It is plainly cosmetic nuisance.

There is plenty of information on this on the web if you run the search on
"tomcat socket write error"

Hope it helps,

Michael Szlapa
[EMAIL PROTECTED]

                -----Original Message-----
                From:   Johan Compagner [mailto:[EMAIL PROTECTED]]
                Sent:   Wednesday, March 28, 2001 9:49 AM
                To:     Struts
                Subject:        Bug in tomcat or the JDK (testing it on
1.2.2)

                Hi,

                If i use Tomcat as a static (gifs) and dynamic (jsp) server,
that is mostly
                used inside a debugging evironment or maybe if it is
specified that everything
                in the webapp\app dir must be served by tomcat (still find
this a very bad idee),
                then i noticed that i get socket exceptions on specifiek
files those files have
                something in common they are the larger files in my app:
31290 and 23281 bytes

                this is the error:
                2001-03-28 04:40:07 - Ctx( /financialtools ): IOException
in: R( /financialtools + /overlib.js + null) socket write error
                (code=10053)

                Then i went testing in the source code of
org.apache.tomcat.request.FileHandler where it is thrown.
                And after sometesting i found out that a picture can't be
larger then 16383 because if it is 16384
                then an exception will be thrown. I tested this with the
read in buffer:
                byte[] buf = new byte[16383];

                if that number is larger then 16383 i wil get a exception
when i write it.
                so if i keept it 16383 then the first write to
out.write(buf, 0, read); will pass
                but the next bloc will fail. And if i make it 16384,
out.write(buf, 0, read); will fail the first time!

                As far as i can see now it comes from the jdk it self:

                java.net.SocketException: socket write error (code=10053)
                 java.lang.Throwable(java.lang.String)
                 java.lang.Exception(java.lang.String)
                 java.io.IOException(java.lang.String)
                 java.net.SocketException(java.lang.String)
                 void java.net.SocketOutputStream.socketWrite(byte [], int,
int, java.io.FileDescriptor) <-----------
                 void java.net.SocketOutputStream.write(byte [], int, int)
                 void
org.apache.tomcat.service.http.HttpResponseAdapter.doWrite(byte [], int,
int)
                 void
org.apache.tomcat.core.BufferedServletOutputStream.doWrite(byte [], int,
int)
                 void
org.apache.tomcat.core.BufferedServletOutputStream.reallyFlush()
                 void
org.apache.tomcat.core.BufferedServletOutputStream.write(byte [], int, int)
                 void
org.apache.tomcat.request.FileHandler.doService(org.apache.tomcat.core.Reque
st, org.apache.tomcat.core.Response)


                So is this a bug of Tomcat or the JDK it self? But can't
send more then 16K? that is a bit strange.

                I know this is not a tomcat list but when developing with
struts i came accross this and i don't want
                to have another list that i have to monitor and i know there
are a few tomcat developers here.

                Johan
                

Reply via email to