[
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)
