[
https://issues.apache.org/jira/browse/THRIFT-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513251#comment-14513251
]
Hudson commented on THRIFT-3081:
--------------------------------
SUCCESS: Integrated in Thrift #1521 (See
[https://builds.apache.org/job/Thrift/1521/])
THRIFT-3081 consolidate client processing loop in Simple, Threaded, and Thread
Pool servers (roger: rev 5ec805b22b81001b1b785cd7f85eb8647fde60df)
* lib/cpp/src/thrift/server/TSimpleServer.cpp
* lib/cpp/src/thrift/server/TConnectedClient.h
* lib/cpp/src/thrift/server/TSimpleServer.h
* lib/cpp/Makefile.am
* lib/cpp/src/thrift/server/TThreadedServer.cpp
* lib/cpp/src/thrift/server/TConnectedClient.cpp
* lib/cpp/src/thrift/server/TThreadPoolServer.cpp
* lib/cpp/CMakeLists.txt
* lib/cpp/src/thrift/server/TThreadedServer.h
* lib/cpp/src/thrift/server/TThreadPoolServer.h
> C++ Consolidate client processing loops in TServers
> ---------------------------------------------------
>
> Key: THRIFT-3081
> URL: https://issues.apache.org/jira/browse/THRIFT-3081
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
> Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2
> Reporter: James E. King, III
> Fix For: 0.9.3
>
>
> Currently each of TSimpleServer, TThreadedServer, and TThreadPoolServer have
> their own very similar but not quite identical way of processing a client's
> lifetime. The code has been copied around and changed; for example a
> TThreadPoolServer handles TTransportExceptions from process() differently
> than a TThreadedServer does.
> There are certain requirements for this processing loop that needs to be met
> by every client. Consolidating these three disparate implementations of the
> client processing loop into one will provide consistency as well as easier
> maintenance, as there will be one common client processing loop that will
> contain all the logic from {{eventHandler->createContext}} through
> {{client->close}}.
> It was also discovered that all three implementations call peek() in each
> loop which causes more recv calls than are really needed. Will experiment
> with removing peek entirely; expectation is that it is sufficient to have
> exception handling around process() and/or have process() return false to end
> the processing loop, and peek() is likely an unnecessary temporary band-aid
> that got left there.
> This was inspired by changes in THRIFT-2441 and I was encouraged to make this
> a separate body of work from that change so that it can be reviewed in
> isolation from other changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
