You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Henrique Mendonca (JIRA)" <ji...@apache.org> on 2013/04/24 10:31:16 UTC

[jira] [Commented] (THRIFT-1850) make check hangs on TSocket tests in TransportTest.cpp

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

Henrique Mendonca commented on THRIFT-1850:
-------------------------------------------

Hi Randy,
Thanks a lot for the patch. I can also reproduce this but apparently it run smoothly on the Jenkins build servers, so I'm not really sure why it hangs there.
Perhaps someone else has a better idea?

                
> make check hangs on TSocket tests in TransportTest.cpp
> ------------------------------------------------------
>
>                 Key: THRIFT-1850
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1850
>             Project: Thrift
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 0.9, 1.0
>         Environment: Mint 14 x64 and Centos 6.3 x64 and x86 [Web Server Profile] with clean install and minimum Thrift support added for C++
>            Reporter: Randy Abernethy
>             Fix For: 1.0
>
>         Attachments: 0001-TSocket-TransportTest.cpp-hang.patch
>
>
> On the systems noted with trunk rev 3a67c2f 
>    TEST_BLOCKING_BEHAVIOR(CoupledFDTransports) and
>    TEST_BLOCKING_BEHAVIOR(CoupledSocketTransports) in
>    lib/cpp/test/TransportTest.cpp (around line 850) 
> produce timeout alarms with the warning: 
>    "Timeout alarm expired; attempting to unblock transport" 
> and then the 4th (and 8th) TEST_RW(CoupledSocketTransports,...) hangs indefinitely due to a blocking socket write. Some others have noticed this:
>    http://stackoverflow.com/questions/13147105/thrfit-make-check-stuck
> I have attached a patch that sets a timeout on the TSocket in question allowing transport reads to take place when the socket layer refuses to write. It appears trunk revision 0c025e8f reduced the socket_max_outstanding on the two problem tests to 400 in order to repair this (which I assume it did at the time). I do not think this is needed with the attached patch and have reverted to the symbolic socket_max_outstanding value. 
> The two TEST_BLOCKING_BEHAVIOR timeouts still alarm but the tests appear to run as they were meant to with this patch on all three systems I have tested. This is my first contribution, please let me know if it is off base in any way.

--
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