Thank you Ben. So probably that is the problem I'm having. While I called TThreadedServer::stop(), I think the tasks are still keeping their own connections with clients open. I don't know why. This sounds the most reasonable explanation of what I'm seeing. Sorry for the confusion.
Rodolfo > -----Original Message----- > From: Ben Craig [mailto:[email protected]] > Sent: Wednesday, June 04, 2014 6:24 PM > To: [email protected] > Subject: RE: Thread dies in TThreadedServer task > > Calling TThreadedServer::stop() will eventually call > TServerSocket::interrupt(). > > The server interrupt() calls don't currently force clients to disconnect, and > the > interrupt calls() don't interrupt outstanding RPC calls. > > So yes, if you have a client that is currently connected, then it will hold up > TThreadedServer destruction. > > "Kohn, Rodolfo" <[email protected]> wrote on 06/04/2014 04:02:29 > PM: > > > From: "Kohn, Rodolfo" <[email protected]> > > To: "[email protected]" <[email protected]>, > > Date: 06/04/2014 04:03 PM > > Subject: RE: Thread dies in TThreadedServer task > > > > Hi Ben, > > Is it possible that the task threads blocked in the read operation? > > (Maybe the client stopped sending data and never closed the > > connection) > > > > Rodolfo > > > > > > > > > -----Original Message----- > > > From: Kohn, Rodolfo [mailto:[email protected]] > > > Sent: Wednesday, June 04, 2014 12:24 PM > > > To: [email protected] > > > Subject: RE: Thread dies in TThreadedServer task > > > > > > > In what way does the thread die? > > > This is weird, I'm not able to debug it, so I was working with logs. > The > > > exception, if any, is not caught and I don't understand why because > the > > > catch's are: > > > 1-TTransportException > > > 2-exception > > > 3-... > > > > > > None is catching the exception, if any. What I'm sure is that the > > line where it > > > dies is the one mentioned below: setReadBuffer(rBuf_.get(), > transport_- > > > >read(rBuf_.get(), rBufSize_)); in TBufferTransports.h It could bean > access > > > violation but in this line we are only using thrift internal > > buffers and in this > > > case I think I should see an event in the event viewer (this is > > not happening). > > > > > > Thanks, > > > Rodolfo > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Ben Craig [mailto:[email protected]] > > > > Sent: Wednesday, June 04, 2014 11:03 AM > > > > To: [email protected] > > > > Subject: RE: Thread dies in TThreadedServer task > > > > > > > > I don't have as good of an answer as "apply patch X" for you now > > > > :) > > > > > > > When the connection with the client is broken for some > > > > > > > reason > (I > > > > don't > > > > > > > know whether it received a RST but I suppose so), the > following > > > > > > > line makes the thread die: > > > > > > > > In what way does the thread die? > > > > > > > > My expectation is that tSocket::read() will throw an exception > > > > when > it > > > > sees that the socket is bad. tThreadedServer::Task should catch > that > > > > exception, and then let the thread remove itself from the > > > > servertask > list. > > > > So is something else happening in your case? Is there an access > > > > violation, a null pointer dereference, or some other non-C++ > exception > > > that happens? > > > > Is the tThreadedServer::Task not catching the exception? > > > > > > > > > > > > "Kohn, Rodolfo" <[email protected]> wrote on 06/04/2014 > 08:36:04 > > > > AM: > > > > > > > > > From: "Kohn, Rodolfo" <[email protected]> > > > > > To: "[email protected]" <[email protected]>, > > > > > Date: 06/04/2014 08:36 AM > > > > > Subject: RE: Thread dies in TThreadedServer task > > > > > > > > > > Thank you Ben for the response. > > > > > Sorry for the missing data. > > > > > > > > > > -Version Thrift 0.9.1 > > > > > -OS: Windows 8 > > > > > -Language: C++ > > > > > > > > > > As additional data, when I call interrupt to stop the server > > > > > (TThreadedServer), since the threads died, when the server in > > > > > its final path stops waiting for all task threads to finish, it > > > > > enters > a > > > > > deadlock because tasks cannot erase themselves from the task set > and > > > > > cannot notify the main server thread. > > > > > > > > > > Thanks, > > > > > Rodolfo > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Craig [mailto:[email protected]] > > > > > > Sent: Wednesday, June 04, 2014 10:18 AM > > > > > > To: [email protected] > > > > > > Subject: Re: Thread dies in TThreadedServer task > > > > > > > > > > > > Which OS? Broken pipe signal handling differs wildly between > > > > > > Windows, Mac, Linux, BSD, etc. > > > > > > Which version of Thrift? > > > > > > > > > > > > If you are using Mac, and Thrift 0.9.1, then you may want to > look > > > > > > at > > > > > > THRIFT-2019 and its associated .patch. > > > > > > https://issues.apache.org/jira/browse/THRIFT-2019 > > > > > > > > > > > > "Kohn, Rodolfo" <[email protected]> wrote on 06/03/2014 > > > > > > 05:44:07 > > > > > > PM: > > > > > > > > > > > > > From: "Kohn, Rodolfo" <[email protected]> > > > > > > > To: "[email protected]" <[email protected]>, > > > > > > > Date: 06/03/2014 05:45 PM > > > > > > > Subject: Thread dies in TThreadedServer task > > > > > > > > > > > > > > Hello, > > > > > > > I'm working with C++ Thrift and I'm using TThreadedServer > > > > > > > with TBinaryProtocolFactory and TBufferedTransportFactory. > > > > > > > When a new connection is received in accept, a task is > > > > > > > created and executed as a runnable. > > > > > > > When the connection with the client is broken for some > > > > > > > reason > (I > > > > don't > > > > > > > know whether it received a RST but I suppose so), the > following > > > > > > > line makes the thread die: > > > > > > > > > > > > > > !input_->getTransport()->peek() > > > > > > > > > > > > > > I found the problem occurs inside TBufferTransports.h in > method > > > > > > > bool > > > > > > > peek() in the following line: > > > > > > > setReadBuffer(rBuf_.get(), transport_->read(rBuf_.get(), > > > > rBufSize_)); > > > > > > > > > > > > > > I suppose this is because the thread is getting a broken > > > > > > > pipe signal that is not properly handled but I would like to > > > > > > > ask > the > > > > > > > list > > > > whether > > > > > > > this makes sense and how this could be solved. > > > > > > > > > > > > > > Thanks, > > > > > > > Rodolfo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
