jetty6: java.net.SocketException

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

jetty6: java.net.SocketException

EGW0116
Hello,

I got an exception trace, when requesting a page with IE (html page is
built dynamically on client side).
The HTML page itself  is rendered as expected (no images were missing).
With Firefox no errors are thrown.
But the main issue is, that jetty keeps the requested file open as long
as jetty is running, as a result of
this exception. (I cannot access the file with an editor as long as
jetty is running)

regards, Thanassis

274324 [BoundedThreadPool0-0] WARN org.mortbay.log -
/EibDesc/images/eibdesc/puls.png
java.net.SocketException: Connection reset by peer: socket write error
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.net.SocketOutputStream.socketWrite(Unknown Source)
        at java.net.SocketOutputStream.write(Unknown Source)
        at org.mortbay.io.bio.StreamEndPoint.flush(StreamEndPoint.java:121)
        at
org.mortbay.jetty.HttpGenerator.flushBuffers(HttpGenerator.java:619)
        at
org.mortbay.jetty.HttpConnection.flushResponse(HttpConnection.java:426)
        at org.mortbay.jetty.Response.flushBuffer(Response.java:649)
        at
org.mortbay.jetty.servlet.DefaultServlet.passConditionalHeaders(DefaultServlet.java:525)
        at
org.mortbay.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:365)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
        at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:408)
        at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:353)
        at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:177)
        at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:534)
        at org.mortbay.jetty.Server.handle(Server.java:220)
        at org.mortbay.jetty.Server.handle(Server.java:201)
        at
org.mortbay.jetty.HttpConnection.doHandler(HttpConnection.java:362)
        at
org.mortbay.jetty.HttpConnection.access$1600(HttpConnection.java:45)
        at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:592)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:486)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:195)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:297)
        at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:138)
        at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:402)
274354 [BoundedThreadPool0-3] WARN org.mortbay.log -
/EibDesc/images/eibdesc/puls.png
java.net.SocketException: Connection reset by peer: socket write error
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.net.SocketOutputStream.socketWrite(Unknown Source)
        at java.net.SocketOutputStream.write(Unknown Source)
        at org.mortbay.io.bio.StreamEndPoint.flush(StreamEndPoint.java:121)
(.....)



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re:jetty6: java.net.SocketException

EGW0116
Hello,

my suggestion is to handle the IOException in DefaultServlet.sendData.

Cheers


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re:jetty6: java.net.SocketException

EGW0116
In reply to this post by EGW0116
Sorry,
I didn't investigate in deep. The open file issue seems to be
independent of any exception,
because the file access error occurs even when I use Firefox, which does
not cause the
exceptions I noticed with IE.

Is it a caching issue, which keeps file handles open (I run the test on
a W2K system)?

Sorry if I cause any inconvenience,
Regards - Thanassis




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: jetty6: java.net.SocketException

Greg Wilkins-5

Thanassis,

the exception is ignorable.  it is just IE that has a bad habit
of closing connections mid stream.  The latest snapshot of
jetty tries to not be so verbose about it.

I will investigate the open file issue in a week or two when I
revisit the whole static content stuff of Jetty.    I think the whole
cache mechanism can be improved as it got a little "damaged" in the
port from Jetty 5.

cheers


Thanassis Papathanasiou wrote:

> Sorry,
> I didn't investigate in deep. The open file issue seems to be
> independent of any exception,
> because the file access error occurs even when I use Firefox, which does
> not cause the
> exceptions I noticed with IE.
>
> Is it a caching issue, which keeps file handles open (I run the test on
> a W2K system)?
>
> Sorry if I cause any inconvenience,
> Regards - Thanassis
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Ignoring stack traces depending on the circumstances

Ceki Gulcu-2
Hello,

A few months back we talked about the possibility of avoiding printing
stack traces for certain exceptions. Well, I am happy to report that
I've just tested this feature in LOGBack.  LOGBack is capable of avoiding
printing stack traces for appropriately marked log statements:

For example, in a small test I conducted, the following code

     // The marker can be stored in a static variable for convenient
access.
     Marker ignoreMarker = MarkerFactory.getMarker("IGNORE");
     logger.debug("hello", new Exception("test"));
     logger.debug(ignoreMarker, "hello ignore", new Exception("test"));

results in the following log output:

2006-02-21 15:38:27,655 DEBUG - hello
java.lang.Exception: test
         at
com.logback.classic.joran.EvaluatorJoranTest.testIgnoreMarker(EvaluatorJoranTest.java:70)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
         at java.lang.reflect.Method.invoke(Unknown Source)
         at junit.framework.TestCase.runTest(TestCase.java:154)
         at junit.framework.TestCase.runBare(TestCase.java:127)
         at junit.framework.TestResult$1.protect(TestResult.java:106)
         at junit.framework.TestResult.runProtected(TestResult.java:124)
         at junit.framework.TestResult.run(TestResult.java:109)
         at junit.framework.TestCase.run(TestCase.java:118)
         at junit.framework.TestSuite.runTest(TestSuite.java:208)
         at junit.framework.TestSuite.run(TestSuite.java:203)
         at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
         at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
         at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
2006-02-21 15:38:27,665 DEBUG - hello ignore

Note that the last line does not contain a stack trace, which is
the whole point of the exercise. :-)

In the above example, logging was configured using the following
configuration file:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration>

<configuration>

   <evaluator name="IGNORE_EVAL">
    <Expression>(marker != null) &amp;&amp;
(marker.contains("IGNORE"))</Expression>
   </evaluator>

   <appender name="CONSOLE" class="com.logback.core.ConsoleAppender">
     <layout class="com.logback.classic.PatternLayout">
       <Pattern>%date %level - %messge%n%ex{full, IGNORE_EVAL}</Pattern>
     </layout>
   </appender>

   <root>
     <level value="DEBUG" />
     <appender-ref ref="CONSOLE" />
   </root>
</configuration>

The above is quite similar to log4j configuration file in XML format
except for the evaluator tag and the contents of Pattern element.

An evaluator is a named entity, which as the name implies, is meant
to evaluate logical expressions on logging events. In the above
example, the expression language is Java. The evaluator named
"IGNORE_EVAL" will return true if a logging event contains a marker
which contains the string "IGNORE".

A few lines below, create a console appender with a layout which
prints the date, level, message and a new line for each event.
Exceptions are printed to their "full" length, except when the
"IGNORE_EVAL" evaluator returns true for the event being processed.

Comments? Are there any other cool features you'd like to see
implemented?

--
Ceki Gülcü



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss