thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Coe <rcoe.java...@gmail.com>
Subject Re: Unable to stop socket server while there are connected clients
Date Wed, 28 Feb 2018 17:49:34 GMT
I agree with the followups to my post, which I did point out was just
advice on implementing a client that can be informed of a pending
shutdown.  I see that as prudent, regardless of the issue.  And your points
on how best to terminate connections cleanly is part of that prudence.

Certainly nothing stops java from handling an interrupt and terminating a
socket, which is why the socket connection libraries use caught
exceptions.  My point was that a designer of a service should take into
account the needs of the client, which obviously it doesn't know.  However,
a clean contract that can message the client at least provides a best
effort before the socket is closed.



On Feb 28, 2018 08:49, "James King" <jeking3rd@gmail.com> wrote:

 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