[ 
https://issues.apache.org/jira/browse/THRIFT-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021181#comment-13021181
 ] 

Hudson commented on THRIFT-1149:
--------------------------------

Integrated in Thrift #129 (See 
[https://hudson.apache.org/hudson/job/Thrift/129/])
    THRIFT-1149. ruby: Nonblocking server fails when client connection is reset

In some situations, a disconnecting client could cause the nonblocking server 
to trip on an exception and take the whole server down. This patch rescues such 
errors and cleans up only the disconnected client.

Patch: Alex


> Nonblocking server fails when client connection is reset
> --------------------------------------------------------
>
>                 Key: THRIFT-1149
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1149
>             Project: Thrift
>          Issue Type: Bug
>          Components: Ruby - Library
>    Affects Versions: 0.6
>         Environment: FreeBSD orion 8.2-RELEASE FreeBSD 8.2-RELEASE #19 
> r220462: Fri Apr  8 22:24:26 EDT 2011     
> alex@orion:/usr/obj/usr/src/sys/ORION  amd64
> Ruby 1.9.2
>            Reporter: Alex
>            Assignee: Alex
>              Labels: nonblocking, patch
>             Fix For: 0.7
>
>         Attachments: nonblocking_fix.diff
>
>
> I've attempted to stress test the nonblocking server by writing a client 
> which connects to said server and executes three operations as fast as 
> possible in an infinite loop. I've found that if I kill the client (ctrl + 
> C), an intermittent problem occurs where the server will stop accepting new 
> connections from clients. In the case of multiple clients already connected, 
> they are immediately disconnected.
> I've tracked the bug down to the run method in nonblocking_server.rb, 
> specifically the "if fd.handle.eof?" statement (around line 150). Under 
> certain conditions executing this line will cause Errno::ECONNRESET to be 
> raised. As such, the "@shutdown_queue.push :shutdown" statement is executed, 
> which accounts for the behavior I am seeing. The attached patch rescues such 
> an error and removes the connection. I am not sure if this is the best way to 
> do it, however it solves the problem for me.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to