You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Roger Meier (JIRA)" <ji...@apache.org> on 2012/12/16 20:46:13 UTC

[jira] [Resolved] (THRIFT-536) Problem with connectionStackLimit in TNonblockingServer

     [ https://issues.apache.org/jira/browse/THRIFT-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Roger Meier resolved THRIFT-536.
--------------------------------

    Resolution: Fixed

it's old...
Please create a new ticket if you have new ideas on this.

;-r
                
> Problem with connectionStackLimit in TNonblockingServer
> -------------------------------------------------------
>
>                 Key: THRIFT-536
>                 URL: https://issues.apache.org/jira/browse/THRIFT-536
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>         Environment: Any
>            Reporter: Grzegorz LeszczyƄski
>            Priority: Minor
>
> Problem is for version 1.0-782997 for debian, I don't know is it 0.1 or 0.2 version.
> Problem is that, when connectionStackLimit is used (and it is used by default), in TNonblockingServer::returnConnection TConnection could be destroyed. But returnConnection is called from TConnection::close, so we are inside method for object, which is destroyed and it could lead to crashes. It looks that only place, where TConnection data is used, after object being destroyed, is in TConnection::transition for state APP_READ_REQUEST (in "catch (IllegalStateException & ise)") - I think it is bug anyway, because return is missing there. But we made a patch for closing server gracefully and we use TConnection::close() in TConnection destructor, too.
> Anyway, it isn't good idea to delete object inside call to its method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira