thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James King <jeking...@gmail.com>
Subject Re: Unable to stop socket server while there are connected clients
Date Wed, 28 Feb 2018 13:49:25 GMT
 The server should never be held hostage by a client.  As such, I disagree
with your proposal.
When the server needs to shutdown, it shall:

1. Drain outstanding requests to zero.  During this time any outstanding
requests are processed to completion, but no new requests or connections
are allowed.
2. Deliver the responses by properly closing the socket using
well-documented means.  This is by no means a guaranteed delivery of the
response, given how sockets work.
3. Shutdown the service.

Significant work went into the C++ engine to support proper shutdown in
this manner, back in the 0.9.3 release.
Prior to that, any client could hold the server hostage and prevent a
shutdown (see: prevent an upgrade; etc...) - even a simple telnet
connection to the port.
Clearly the other language server libraries need to catch up which is why
we have items in the backlog for it.  (Thank you for reporting it!)

- Jim

On Wed, Feb 28, 2018 at 8:19 AM, Robin Coe <rcoe.javadev@gmail.com> wrote:

> Not having looked at the bug report, so take this advice as appropriate,
> but I would rethink the implementation.  The underlying network protocol
> has no expectation that a server closes a socket, it is always the client's
> responsibility.  Data integrity is in question when the server just
> forcibly closed the connection, and why java responds with a socket
> exception in the client.
>
> A safer approach is to implement a callback mechanism that allows the
> server to broadcast that it is being shutdown and allow the clients to
> respond.  Once clients have closed the connection, then the server daemon
> can terminate.
>
> On Feb 27, 2018 11:06, "Gianni Ambrosio" <gianni.ambrosio@vi-grade.com>
> wrote:
>
> > Hi All,
> > I realized the previous link (THRIFT-2696) was related to Delphi (gosh!).
> > C++ implementation had the same problem but seems to be already fixed:
> >
> > https://github.com/apache/thrift/commit/1684c429501e9df9387c
> > b518e660691f032d7926#diff-73a64b6e865fd1b207b30764b9e06033
> >
> > Is it possible to open a ticket for C# too?
> >
> > Regards,
> > Gianni
> >
> > On 27/02/2018 14:09, Gianni Ambrosio wrote:
> >
> >> Hi All,
> >> I was experiencing exacly the same problem reported here with Thrift
> >> 0.9.1:
> >> https://issues.apache.org/jira/browse/THRIFT-2696
> >>
> >>  So I moved to the latest thrift version (i.e. 0.11.0) but the problem
> is
> >> still there!
> >>
> >> I implemented a thrift server with TSimpleServer in C#:
> >>
> >> public class ThriftServer
> >> {
> >>    public void start(){
> >>       Service.Processor processor = new Service.Processor(serviceHandl
> >> er);
> >>       TServerSocket serverTransport = new TServerSocket(ServiceConstants
> >> .ServicePort);
> >>       server = new TSimpleServer(processor, serverTransport);
> >>       workerThread = new Thread(new ThreadStart(run));
> >>       workerThread.Start();
> >>    }
> >>    private void run(){
> >>       server.Serve();
> >>    }
> >>    public void stop(){
> >>       server.Stop();
> >>    }
> >> }
> >>
> >> And here is the C++ client implementation:
> >>
> >> void ThriftClient::connect(const std::string& serverIp) {
> >> boost::shared_ptr<apache::thrift::transport::TTransport> socket(new
> >> apache::thrift::transport::TSocket(serverIp.c_str(),
> >> g_Service_constants.ServicePort));
> >>    transport = boost::make_shared<apache::thr
> >> ift::transport::TBufferedTransport>(socket);
> >>    transport->open();
> >>    client = boost::make_shared<ServiceClient>(boost::make_
> shared<apache:
> >> :thrift::protocol::TBinaryProtocol>(transport));
> >> }
> >>
> >> The problem is that when I close the C# application the application does
> >> not close. But in that state it closes as soon as I close the C++ client
> >> application.
> >> Debugging the C# application, server.Stop() is called but server.Serve()
> >> call does not exit unless the client has been disconnected.
> >> Since the above thrift ticket seems reporting exactly the same issue and
> >> it should be fixed in thrift 0.9.2, what's wrong in my code?
> >>
> >> Best regards,
> >> Gianni
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message