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

["Rush Manbert (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728740#action_12728740 ] 

Rush Manbert commented on THRIFT-536:
-------------------------------------

Caveat: I didn't write the code, but I'm pretty familiar with it right now. (This issue made me go through my new code and make sure I don't't have the same bug.)

It certainly looks like you crash if you catch the exception, because of the ensuing call to setIdle().

But if a return is added immediately following the close call in the catch, everything else looks to be safe, if undocumented. All other calls to TConnection::close() immediately return and no one but returnConnection should be calling the TConnection destructor.

> Problem with connectionStackLimit in TNonblockingServer
> -------------------------------------------------------
>
>                 Key: THRIFT-536
>                 URL: https://issues.apache.org/jira/browse/THRIFT-536
>             Project: Thrift
>          Issue Type: Bug
>          Components: Library (C++)
>         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.
-
You can reply to this email to add a comment to the issue online.