[
https://issues.apache.org/jira/browse/THRIFT-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-3081:
---------------------------------------
Description:
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.
was:
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}}.
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.
> 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
>
> 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)
