[GitHub] thrift issue #1497: Do not call workSocket() in TNonblockigServer without en...
Github user bgedik commented on the issue: https://github.com/apache/thrift/pull/1497 @jeking3 There is already a Jira item: https://issues.apache.org/jira/browse/THRIFT-4465 Btw, it makes sense that the fix resolves the framed transport failures. Because the bug was about the transition from the frame size reading to the frame content reading. ---
[jira] [Commented] (THRIFT-4465) TNonblockingServer throwing THRIFT LOGGER: TConnection::workSocket(): THRIFT_EAGAIN (unavailable resources)
[
https://issues.apache.org/jira/browse/THRIFT-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394659#comment-16394659
]
ASF GitHub Bot commented on THRIFT-4465:
Github user bgedik commented on the issue:
https://github.com/apache/thrift/pull/1497
@jeking3 There is already a Jira item:
https://issues.apache.org/jira/browse/THRIFT-4465
Btw, it makes sense that the fix resolves the framed transport failures.
Because the bug was about the transition from the frame size reading to the
frame content reading.
> TNonblockingServer throwing THRIFT LOGGER: TConnection::workSocket():
> THRIFT_EAGAIN (unavailable resources)
> ---
>
> Key: THRIFT-4465
> URL: https://issues.apache.org/jira/browse/THRIFT-4465
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.11.0
>Reporter: Buğra Gedik
>Priority: Critical
>
> Once I upgraded to 0.11.0, I'm getting the following error occasionally:
> THRIFT LOGGER: TConnection::workSocket(): THRIFT_EAGAIN (unavailable
> resources)
> I tracked this to the following change:
> [https://github.com/apache/thrift/commit/808d143245f4f5c30600fab31cf9db854cbf5b48#diff-fe8fec8ec38ea35df64cfcc305e3ab08]
>
> {code:java}
> // Work the socket right away
> - // workSocket();
> + workSocket();
> {code}
> While adding SSL support, @dthaluru has re-activated the above line. From my
> own testing, this causes occasional THRIFT_EAGAIN exceptions. It seems like
> this is due to calling workSocket() too early and the socket gets a read call
> in non-blocking mode before it has data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1497: Do not call workSocket() in TNonblockigServer without en...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1497 Cool so that last test run was without the fix (I thought it had it, but it only had my fixes to TestServer.cpp), and adding your fix seems to have taken care of the header failures somehow: ``` root@1dcb0ce83732:/thrift/src# test/test.py --server cpp --client cpp --regex='.*framed.*-ip.*' Apache Thrift - Integration Test Suite Sun Mar 11 19:39:18 2018 === server-client: protocol: transport: result: cpp-cpp compact framed-ipsuccess cpp-cpp multi-binary framed-ip-sslsuccess cpp-cpp compact framed-ip-sslsuccess cpp-cpp multi-binary framed-ipsuccess cpp-cpp multihframed-ipsuccess cpp-cpp multihframed-ip-sslsuccess cpp-cpp multih-header framed-ip-sslsuccess cpp-cpp multih-header framed-ipsuccess cpp-cpp multij-json framed-ip-sslsuccess cpp-cpp multij-json framed-ipsuccess cpp-cpp json framed-ip-sslsuccess cpp-cpp json framed-ipsuccess cpp-cpp multicframed-ipsuccess cpp-cpp multicframed-ip-sslsuccess cpp-cpp multic-compactframed-ip-sslsuccess cpp-cpp multic-compactframed-ipsuccess cpp-cpp multij-json framed-ip-sslsuccess cpp-cpp multij-json framed-ipsuccess cpp-cpp multijframed-ip-sslsuccess cpp-cpp multijframed-ipsuccess cpp-cpp headerframed-ip-sslsuccess cpp-cpp headerframed-ipsuccess cpp-cpp multic-compactframed-ip-sslsuccess cpp-cpp multic-compactframed-ipsuccess cpp-cpp multi-binary framed-ip-sslsuccess cpp-cpp multi-binary framed-ipsuccess cpp-cpp multi framed-ipsuccess cpp-cpp multi framed-ip-sslsuccess cpp-cpp multih-header framed-ip-sslsuccess cpp-cpp multih-header framed-ipsuccess cpp-cpp binaryframed-ipsuccess cpp-cpp binaryframed-ip-sslsuccess === No unexpected failures. ``` ---
[GitHub] thrift issue #1497: Do not call workSocket() in TNonblockigServer without en...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1497 You need to create a Jira ticket in the THRIFT project (https://issues.apache.org/jira/projects/THRIFT/issues) that describes the bug and resolution so that I can merge it. --- I was able to test these changes out by making some changes to the cpp TestServer for crosstest which I will check in today. I changed my local tests.json file to add "--server-type=nonblocking" to each cpp server and changed some code to make additional cases work: ``` root@8d560c4cc0fa:/thrift/src# test/test.py --server cpp --client cpp --regex='.*framed.*-ip.*' Apache Thrift - Integration Test Suite Sun Mar 11 14:49:02 2018 === server-client: protocol: transport: result: cpp-cpp compact framed-ipsuccess cpp-cpp multi-binary framed-ipsuccess cpp-cpp compact framed-ip-sslsuccess cpp-cpp multihframed-ip-sslsuccess cpp-cpp multihframed-ipsuccess cpp-cpp multi-binary framed-ip-sslsuccess cpp-cpp multih-header framed-ipsuccess cpp-cpp multih-header framed-ip-sslsuccess cpp-cpp multij-json framed-ip-sslsuccess cpp-cpp multij-json framed-ipsuccess cpp-cpp json framed-ipsuccess cpp-cpp json framed-ip-sslsuccess cpp-cpp multicframed-ipsuccess cpp-cpp multicframed-ip-sslsuccess cpp-cpp multic-compactframed-ipsuccess cpp-cpp multic-compactframed-ip-sslsuccess cpp-cpp multij-json framed-ip-sslsuccess cpp-cpp multij-json framed-ipsuccess cpp-cpp headerframed-ip failure(-6) cpp-cpp multijframed-ipsuccess cpp-cpp multijframed-ip-sslsuccess cpp-cpp headerframed-ip-ssl failure(-6) cpp-cpp multic-compactframed-ipsuccess cpp-cpp multic-compactframed-ip-sslsuccess cpp-cpp multi-binary framed-ip-sslsuccess cpp-cpp multi-binary framed-ipsuccess cpp-cpp multi framed-ip-sslsuccess cpp-cpp multi framed-ipsuccess cpp-cpp multih-header framed-ip-sslsuccess cpp-cpp multih-header framed-ipsuccess cpp-cpp binaryframed-ip-sslsuccess cpp-cpp binaryframed-ipsuccess === ``` (I think you can ignore the header failures) ---
[jira] [Created] (THRIFT-4515) Gracefully shutdown cross-test servers to fully test teardown
James E. King, III created THRIFT-4515: -- Summary: Gracefully shutdown cross-test servers to fully test teardown Key: THRIFT-4515 URL: https://issues.apache.org/jira/browse/THRIFT-4515 Project: Thrift Issue Type: Improvement Components: Test Suite Affects Versions: 0.11.0 Reporter: James E. King, III The cross test suite kills the server process after the client is done, see test/crosstest/run.py:_scoped, the process is killed. In the C++ TestServer code at the end of main it sits in a TIGHT while loop unnecessarily causing CPU usage and slowing down the system. There should be a signal (like SIGUSR1) that each server waits for, and on receiving that signal stops the thrift server cleanly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (THRIFT-4515) Gracefully shutdown cross-test servers to fully test teardown
[ https://issues.apache.org/jira/browse/THRIFT-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-4515: -- Assignee: James E. King, III > Gracefully shutdown cross-test servers to fully test teardown > - > > Key: THRIFT-4515 > URL: https://issues.apache.org/jira/browse/THRIFT-4515 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.11.0 >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Major > > The cross test suite kills the server process after the client is done, see > test/crosstest/run.py:_scoped, the process is killed. In the C++ TestServer > code at the end of main it sits in a TIGHT while loop unnecessarily causing > CPU usage and slowing down the system. > There should be a signal (like SIGUSR1) that each server waits for, and on > receiving that signal stops the thrift server cleanly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1497: Do not call workSocket() in TNonblockigServer without en...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1497 What's the Jira ticket ID for this work? ---
[GitHub] thrift issue #1497: Do not call workSocket() in TNonblockigServer without en...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1497 Wow, haven't seen a green build in a while. Of course, none of the cross tests exercise nonblocking code. :( Would be nice to add this as another matrix option. ---
[jira] [Assigned] (THRIFT-4301) configuring --without-python and --without-py3 still invokes py3 tests in make cross
[ https://issues.apache.org/jira/browse/THRIFT-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-4301: -- Assignee: (was: James E. King, III) > configuring --without-python and --without-py3 still invokes py3 tests in > make cross > > > Key: THRIFT-4301 > URL: https://issues.apache.org/jira/browse/THRIFT-4301 > Project: Thrift > Issue Type: Bug > Components: Test Suite >Affects Versions: 0.10.0 > Environment: docker:ubuntu >Reporter: James E. King, III >Priority: Major > > I ran configure using --without-py3 and the make cross test command line > included py3 in the server and client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4085) Add .NET Core to the make cross standard test suite
[ https://issues.apache.org/jira/browse/THRIFT-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4085. Resolution: Fixed Assignee: James E. King, III Fix Version/s: 0.12.0 This was resolved by https://github.com/apache/thrift/pull/1469 > Add .NET Core to the make cross standard test suite > --- > > Key: THRIFT-4085 > URL: https://issues.apache.org/jira/browse/THRIFT-4085 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.10.0 > Environment: Docker Images, Travis CI >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Major > Fix For: 0.12.0 > > > .NET Core is not part of a standard make cross. It should be enabled and run > with every build once there is a docker image with it inside. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
