[
https://issues.apache.org/jira/browse/THRIFT-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15210485#comment-15210485
]
Ted Wang commented on THRIFT-3238:
----------------------------------
I also saw this on Windows. The observable end-user effect is that the server
could exit out of serve() if the client connects and immediately disconnects.
I think the better solution is to simply catch exceptions coming out of
beginAsyncRead in the TPipe constructor. The transport really should not be
doing any IO in the constructor, but TPipe needs to in order to be
pollable/selectable before the first read. Catching the exception in
beginAsyncRead is a-ok as long as beginAsyncRead signals ready_event_.h even if
it fails (it really should) so that the poll/select will still be signalled.
Furthermore, the error is preserved in overlapped so that the next read/write
will throw (the right place to raise this error).
> Fix TNamedPipeServer can be interrupted by faulty client
> --------------------------------------------------------
>
> Key: THRIFT-3238
> URL: https://issues.apache.org/jira/browse/THRIFT-3238
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9.2
> Environment: Windows
> Reporter: Paweł Janicki
> Priority: Critical
> Attachments:
> 0001-Fix-TNamedPipeServer-can-be-interrupted-by-faulty-cl.patch,
> 0002-THRIFT-3238.-cpp-Fix-TNamedPipeServer-can-be-interru.patch
>
>
> A faulty or hostile client can cause TNamedPipeServer to be interrupted and
> return from serve(). The client that causes such effect just needs to open
> and immediately close TPipe transport.
> Caused by not handling some NamedPipe error codes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
