[jboss-jira] [JBoss JIRA] Commented: (JBWEB-125) Crash ending an event driven HTTP connection

[Remy Maucherat (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBWEB-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12436580#action_12436580 ] 

Remy Maucherat commented on JBWEB-125:
--------------------------------------

I have a problem with that. It's not accepatble that this stuff does not have basic robustness. Note that I'm asking for "never crash", like NIO, not "never screw up" like when you're doing things like concurrent writes (I'm only calling setTimeout here).

I can see that:
- the JVM dump is also about a timeoutSet, like the exception; the stack trace looks legitimate (the connection is done, switch back to normal mode), but may be called on sockets which are gone (and caused some nasty poll error); obviously that's not very useful, so I will fix that to not call it if the socket got there due to an error in the poller
- if the native layer does not care at all about robustness, then you should be consistent abd remove your "if (!sock)" check

> Crash ending an event driven HTTP connection
> --------------------------------------------
>
>                 Key: JBWEB-125
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-125
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-2.1.1.GA
>            Reporter: Remy Maucherat
>            Assignee: Mladen Turk
>         Attachments: hs_err_pid5850.log
>
>
> I experienced a very rare crash when using events (bayeux stock ticker on localhost + F5), when setting back the socket timeout at the end of the processing. The odd part is that it seems to be caught with an exception (very good) but causes a JVM crash anyway.
> Oct 31, 2008 5:31:47 PM org.apache.coyote.http11.Http11AprProcessor event
> SEVERE: Error processing request
> org.apache.tomcat.jni.Error: Socket operation on non-socket
> 	at org.apache.tomcat.jni.Socket.timeoutSet(Native Method)
> 	at org.apache.coyote.http11.Http11AprProcessor.action(Http11AprProcessor.java:1262)
> 	at org.apache.coyote.Response.action(Response.java:184)
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:272)
> 	at org.apache.coyote.http11.Http11AprProcessor.event(Http11AprProcessor.java:786)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.event(Http11AprProtocol.java:544)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1988)
> 	at java.lang.Thread.run(Thread.java:636)
> #
> # An unexpected error has been detected by Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00b43521, pid=5850, tid=101182352
> #
> # Java VM: OpenJDK Server VM (1.6.0-b09 mixed mode linux-x86)
> # Problematic frame:
> # C  [libtcnative-1.so.0.1.15+0xf521]  Java_org_apache_tomcat_jni_Socket_timeoutSet+0x61
> #
> # An error report file with more information is saved as:
> # /home/remm/Work/jbossweb/jbossweb-2.1.x/output/build/hs_err_pid5850.log
> [thread 97975184 also had an error]
> #
> # If you would like to submit a bug report, please visit:
> #   http://icedtea.classpath.org/bugzilla
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> Assigning to Mladen since the error hints the crash can be avoided (as it seems detected already).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira