[jira] [Comment Edited] (THRIFT-3226) Fix TNamedPipeServer trapped in loop on accept

["Paweł Janicki (JIRA)" <ji...@apache.org>]

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

Paweł Janicki edited comment on THRIFT-3226 at 7/8/15 11:29 AM:
----------------------------------------------------------------

2.0. It is impossible to cause thread blocked on TServer::serve() to return by any operation on TServerTransport derivateive, including call to TServerTransport::interrupt(), because
2.1.1. Call to TSocketServer::interrupt() (see. attached source ConsoleApplication1.cpp) causes the TThreadPoolServer (as well TSimpleServer) to report error and go and wait on accept for new connections in dispatch loop, and
2.1.2. Call to TPipeServer::interrupt() causes the TThreadPoolServer (as well TSimpleServer) to report error and actively loop in serve() loop,
2.2. because
2.3. In current implemntation to cause TSimpleServer::serve() or TThreadPoolServer::serve() to return it is required that the stop_ member must is set to true, and
2.4. The TServerTransport derivatives have no reference to TSimpleServer or TThreadPoolServer in order to mutate the stop_ member to true, thus
2.5. To fix it the condition in TServer derivatives must be fixed that the receival of TTransportException such that TTransportException::getType() == TTransportException::INTERRUPTED is enough to cause server stop and break serve loop.


was (Author: pjanicki):
The transport is closed by client asynchronously.
Herein I'm actually fully satisfying condition: "Don't use closed transports".
I handle situation when transport was closed on client side to prevent server lock-up.

> Fix TNamedPipeServer trapped in loop on accept
> ----------------------------------------------
>
>                 Key: THRIFT-3226
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3226
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>    Affects Versions: 0.9.2
>            Reporter: Paweł Janicki
>            Assignee: Paweł Janicki
>            Priority: Critical
>              Labels: patch
>         Attachments: 0001-THRIFT-3226.-cpp-Fix-TNamedPipeServer-trapped-in-loo.patch, ConsoleApplication1.cpp
>
>
> TNamedPipeServer can trap itself in infinite loop if the client closed Pipe before server instantiated TPipe object in NamedPipeServer::acceptImpl().
> The accept loop waits for connected client on GetOverlappedResult(Pipe_.h , ..) then wraps the connected pipe client hande into TPipe object, opens another pipe handle to wait for next client and returns the newly created pipe wrapper object.
> TPipe object may throw on c-tor if the pipe in meantime has been closed by the client. If so the new pipe instance for next client will NOT be created as the implementation expects. The accept is called with no inital valid pipe handle what causes it to throw and restart accept. It happens then forever.
> I propose to solve the issue by handling the case when TPipe throws: The failed handle should be dropped and new pipe created and wait for next client repeated within acceptImpl



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)