thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Craig <bencr...@apache.org>
Subject RE: Thread dies in TThreadedServer task
Date Wed, 04 Jun 2014 21:23:39 GMT
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" <rodolfo.kohn@intel.com> wrote on 06/04/2014 04:02:29 PM:

> From: "Kohn, Rodolfo" <rodolfo.kohn@intel.com>
> To: "user@thrift.apache.org" <user@thrift.apache.org>, 
> 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:rodolfo.kohn@intel.com]
> > Sent: Wednesday, June 04, 2014 12:24 PM
> > To: user@thrift.apache.org
> > 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:bencraig@apache.org]
> > > Sent: Wednesday, June 04, 2014 11:03 AM
> > > To: user@thrift.apache.org
> > > 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" <rodolfo.kohn@intel.com> wrote on 06/04/2014 
08:36:04
> > > AM:
> > >
> > > > From: "Kohn, Rodolfo" <rodolfo.kohn@intel.com>
> > > > To: "user@thrift.apache.org" <user@thrift.apache.org>,
> > > > 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:ben.craig@ni.com]
> > > > > Sent: Wednesday, June 04, 2014 10:18 AM
> > > > > To: user@thrift.apache.org
> > > > > 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" <rodolfo.kohn@intel.com> wrote on 06/03/2014
> > > > > 05:44:07
> > > > > PM:
> > > > >
> > > > > > From: "Kohn, Rodolfo" <rodolfo.kohn@intel.com>
> > > > > > To: "user@thrift.apache.org" <user@thrift.apache.org>,
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >

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