[
https://issues.apache.org/jira/browse/THRIFT-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14386277#comment-14386277
]
Randy Abernethy commented on THRIFT-2441:
-----------------------------------------
Hey Ben,
I agree with your rational, however this patch applies after the listening
socket has already been shutdown/closed, so the nasty case you describe is
avoided.
The exposure we are left with is an abortive close of a stream socket
independent of the control thread. This could certainly cause a communications
error but so could a broken network link (one of those things you just need to
code for). While I don't think this server was broken before (it just waited
for clients to close before exiting), I don't think it is broken now post patch
either. Folks just need to know how stop() works. Now it means stop listening
(first) and then disconnect all clients regardless of what they are in the
middle of. Pull the plug.
Signalling server threads to let them finish any in-progress RPC would
certainly be nice but I might prefer the abortive close, used once in a rare
while, to the extra clean shutdown overhead, used on every single recv.
-Randy
> Cannot shutdown TThreadedServer when clients are still connected
> ----------------------------------------------------------------
>
> Key: THRIFT-2441
> URL: https://issues.apache.org/jira/browse/THRIFT-2441
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9.1
> Reporter: Chris Stylianou
> Assignee: Roger Meier
>
> When calling stop() on the TThreadedServer no interrupts are sent to the
> client threads. This means the stop() call blocks on tasksMonitor.wait()
> until all client naturally disconnect.
> How can we tell the client thread connections to close/exit during the
> TThreadedServer::stop() call?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
