[
https://issues.apache.org/jira/browse/THRIFT-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213225#comment-15213225
]
Ben Craig commented on THRIFT-3238:
-----------------------------------
ugh, makes sense. The remainder of the attached patch makes more sense now.
This suggests one of these ugly options (or something awesome that doesn't come
to mind immediately):
1: Wrap the TPipe construction with a try / catch block.
2: Move the read initiation to a separate function call that returns some kind
of error status upon disappointment.
3: Do the read initiation before constructing TPipe, then hand the successful
results to TPipe.
4: Give up selectability.
I don't really like any of those options, but the first three all seem workable.
> 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)
