[jira] [Commented] (THRIFT-4064) Update node library dependencies
[ https://issues.apache.org/jira/browse/THRIFT-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860693#comment-15860693 ] ASF GitHub Bot commented on THRIFT-4064: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1175 I looked at the build failures. Build jobs 2 and 4 use the "debian" Dockerfile which needs to be updated in a very similar way to the ubuntu one. Give that a try. As for build jobs 3 and 8, I don't know exactly what happened but job #8 has me the most nervous since it was using the "ubuntu" image which we updated to node.js 4.7.2 and it looks like it hung during testing. > Update node library dependencies > > > Key: THRIFT-4064 > URL: https://issues.apache.org/jira/browse/THRIFT-4064 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.10.0 >Reporter: Andres Suarez >Assignee: James E. King, III > > ws@0.4.32 is really old and presents issues for users using modern versions > of Node (see > https://github.com/apache/thrift/pull/672#issuecomment-276678791). Its should > be updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3622) Fix deprecated uses of std::auto_ptr
[
https://issues.apache.org/jira/browse/THRIFT-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860704#comment-15860704
]
ASF GitHub Bot commented on THRIFT-3622:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1183
Build job #7 failed because it failed to download something from a site I
can get to just fine (github, holding "phantomjs"). Not related to the PR.
> Fix deprecated uses of std::auto_ptr
>
>
> Key: THRIFT-3622
> URL: https://issues.apache.org/jira/browse/THRIFT-3622
> Project: Thrift
> Issue Type: Task
> Components: C++ - Library
>Reporter: John Sirois
>Assignee: James E. King, III
>
> We have some in lib/cpp, like so:
> {noformat}
> JSONProtoTest.cpp:35:13: warning: ‘template class std::auto_ptr’ is
> deprecated [-Wdeprecated-declarations]
> static std::auto_ptr ooe;
> ^
> In file included from /usr/include/c++/5.3.0/bits/locale_conv.h:41:0,
> from /usr/include/c++/5.3.0/locale:43,
> from /usr/include/c++/5.3.0/iomanip:43,
> from JSONProtoTest.cpp:22:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1183: THRIFT-3622: remove auto_ptr use in the codebase because...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1183 Build job #7 failed because it failed to download something from a site I can get to just fine (github, holding "phantomjs"). Not related to the PR. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4075) Better MinGW support for headers-only boost (without thread library)
[
https://issues.apache.org/jira/browse/THRIFT-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860695#comment-15860695
]
ASF GitHub Bot commented on THRIFT-4075:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1184
Kicking another build by pushing an empty commit amend. Appveyor croaked
early with:
Build started
Fetching repository commit (979c781)...Cannot download GitHub repository
contents: NotFound
See:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/build/960
> Better MinGW support for headers-only boost (without thread library)
>
>
> Key: THRIFT-4075
> URL: https://issues.apache.org/jira/browse/THRIFT-4075
> Project: Thrift
> Issue Type: Improvement
> Components: Build Process, C++ - Library
>Affects Versions: 0.10.0
> Environment: MingW 5.3 / QtCreator (CMake)
>Reporter: Aurelien Regat-Barrel
>Assignee: James E. King, III
>Priority: Trivial
>
> Hello,
> I am building Thrift on Windows with QtCreator as a front-end on top of
> CMake. I am using MingW 5.3 (Qt 5.7).
> I saw that you are working on improving the build experience on Windows with
> MingW (#THRIFT-4046) so here are my suggestions :)
> - The doc says Boost 1.53 is required, but actually *Boost 1.63 works better*
> because they fixed some issues preventing the use of Boost as header only
> - I was able to build Thrift with *Boost as header only* with very small
> changes. **Boost threads is not required** for MingW 5.3 (it should also work
> with MingW 4.9). This makes the build process much simpler because we just
> have to unzip the boost package and that's all.
> - Therefore you should consider passing *-DWITH_BOOSTTHREADS=OFF* in the
> [README-MSYS2.md
> doc|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=build/cmake/README-MSYS2.md;h=06c0205056658e743352dabe9fbbc90e1eeaf49e;hb=2d6060d882069ed3e3d6302aa63ea7eb4bb155ad]
> - boost/cstdint.hpp is not required (*#define HAVE_STDINT_H*)
> Here's the changes I made to
> *thrift-0.10.0\lib\cpp\src\thrift\windows\config.h* to better support MingW
> and make it possible to use boost as header only.
> Since I don't know how to attach a patch here, I'll do it old school :)
> Before :
> {noformat}
> // use std::thread in MSVC11 (2012) or newer
> #if _MSC_VER >= 1700
> #define USE_STD_THREAD 1
> #else
> // otherwise use boost threads
> #define USE_BOOST_THREAD 1
> #endif
> // VS2010 or later has stdint.h
> #if _MSC_VER >= 1600
> #define HAVE_STDINT_H 1
> #endif
> {noformat}
> After :
> {noformat}
> // use std::thread in MSVC11 (2012) or newer
> #if defined(_MSC_VER) && (_MSC_VER >= 1700)
> #define USE_STD_THREAD 1
> #elif defined(__MINGW32__)
> #define USE_STD_THREAD 1
> #else
> // otherwise use boost threads
> #define USE_BOOST_THREAD 1
> #endif
> // VS2010 or later has stdint.h
> #if defined(_MSC_VER) && (_MSC_VER >= 1600)
> #define HAVE_STDINT_H 1
> #elif defined(__MINGW32__)
> #define HAVE_STDINT_H 1
> #endif
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1184: THRIFT-4075: better support for headers-only boost with ...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1184 Kicking another build by pushing an empty commit amend. Appveyor croaked early with: Build started Fetching repository commit (979c781)...Cannot download GitHub repository contents: NotFound See: https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/build/960 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1175: THRIFT-4064 Update node library dependencies
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1175 I looked at the build failures. Build jobs 2 and 4 use the "debian" Dockerfile which needs to be updated in a very similar way to the ubuntu one. Give that a try. As for build jobs 3 and 8, I don't know exactly what happened but job #8 has me the most nervous since it was using the "ubuntu" image which we updated to node.js 4.7.2 and it looks like it hung during testing. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3607) Unify exception handling policy of TProcessor
[ https://issues.apache.org/jira/browse/THRIFT-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860659#comment-15860659 ] Christopher Tubbs commented on THRIFT-3607: --- I did a PR for THRIFT-1805 to make the behavior configurable, but I think it might be more applicable to this issue, since the code changes for that issue have already been released: https://github.com/apache/thrift/pull/1186 > Unify exception handling policy of TProcessor > - > > Key: THRIFT-3607 > URL: https://issues.apache.org/jira/browse/THRIFT-3607 > Project: Thrift > Issue Type: Improvement > Components: Wish List >Reporter: Aki Sukegawa > > A discussion in THRIFT-1805 uncovered inconsistent error handling behaviors > of TProcessors across languages and releases. > Most outstanding are Java sync and async processors as described there, but > others are also subtly different in details. > I propose unifying the TProcessor behavior by specifying mappings from > "uncaught server handler exceptions" to "observable server behaviors" as > follows: > * TApplicationException -> send TApplicationException with the message and > the type as thrown > * TTransportException -> the connection is either already broken or newly > broken > * other exceptions -> send opaque TApplicationException(INTERNAL_ERROR) > That way users can still arbitrarily disconnect the client by throwing > TTransportException. > (IMO ideally this should have been done by exposing "client context" object > to the handler instead) > The first one can be a bit controversial as it can be regarded as information > leak. > Also some may prefer unifying the TProcessor behavior to catch-all, so that > servers never die on handler exceptions. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860657#comment-15860657 ] ASF GitHub Bot commented on THRIFT-1805: Github user ctubbsii commented on the issue: https://github.com/apache/thrift/pull/1186 I'm not familiar enough with Thrift's testing framework to add tests, but this works tested locally. I don't know if this makes sense for other languages, but it seems to make a lot of sense for Java. > Thrift should not swallow ALL exceptions > > > Key: THRIFT-1805 > URL: https://issues.apache.org/jira/browse/THRIFT-1805 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler, Java - Library >Affects Versions: 0.9 >Reporter: Diwaker Gupta >Assignee: Diwaker Gupta > Attachments: THRIFT-1805.patch > > > In Thrift 0.8.0, Thrift generated Java code did not swallow application > exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and > now the generated code swallows ALL application exceptions (via > ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while > I see the rationale, it is breaking our applications. > Our code relies on the fact that exceptions can propagate outside of Thrift > for certain things (e.g., to aggressively drop connections for clients that > send invalid/malformed requests). ProcessFunction makes it near impossible to > do this -- not only does it swallow the exception, it also loses all > information about the original exception and just writes out a generic > TApplicationException. > IMO ProcessFunction should only catch TException. If the application code > wants to use other exceptions for some reason (in particular, Errors and > RuntimeExceptions), Thrift shouldn't prevent that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1186: THRIFT-1805 Provide option for handling RTEs
Github user ctubbsii commented on the issue: https://github.com/apache/thrift/pull/1186 I'm not familiar enough with Thrift's testing framework to add tests, but this works tested locally. I don't know if this makes sense for other languages, but it seems to make a lot of sense for Java. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860648#comment-15860648 ] ASF GitHub Bot commented on THRIFT-1805: GitHub user ctubbsii opened a pull request: https://github.com/apache/thrift/pull/1186 THRIFT-1805 Provide option for handling RTEs Adds a Java option to the generator to generate code which lets Thrift handle RuntimeExceptions from a service, and present them as TApplicationException to the client. This addresses a back-and-forth debate over the expected behavior of this in Java services, and the resulting breakage, as described in THRIFT-1805 and related issues, by making the behavior configurable. Throwable types are not handled, because it is generally ill-advised to handle Error types within a Java application. So, this only allows configuration of handling RuntimeException. This patch preserves current behavior as the default, and works with previously generated code. This patch does not affect AsyncProcessFunction exception handling. Related JIRAs: THRIFT-378, THRIFT-1658, THRIFT-1805, THRIFT-3607 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ctubbsii/thrift handle-runtimeexceptions Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1186.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1186 commit 48ee27b210edf2d92af2f5060820d77ca0898aff Author: Christopher Tubbs Date: 2017-02-10T03:32:00Z THRIFT-1805 Provide option for handling RTEs Adds a Java option to the generator to generate code which lets Thrift handle RuntimeExceptions from a service, and present them as TApplicationException to the client. This addresses a back-and-forth debate over the expected behavior of this in Java services, and the resulting breakage, as described in THRIFT-1805 and related issues, by making the behavior configurable. Throwable types are not handled, because it is generally ill-advised to handle Error types within a Java application. So, this only allows configuration of handling RuntimeException. This patch preserves current behavior as the default, and works with previously generated code. This patch does not affect AsyncProcessFunction exception handling. Related JIRAs: THRIFT-378, THRIFT-1658, THRIFT-1805, THRIFT-3607 > Thrift should not swallow ALL exceptions > > > Key: THRIFT-1805 > URL: https://issues.apache.org/jira/browse/THRIFT-1805 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler, Java - Library >Affects Versions: 0.9 >Reporter: Diwaker Gupta >Assignee: Diwaker Gupta > Attachments: THRIFT-1805.patch > > > In Thrift 0.8.0, Thrift generated Java code did not swallow application > exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and > now the generated code swallows ALL application exceptions (via > ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while > I see the rationale, it is breaking our applications. > Our code relies on the fact that exceptions can propagate outside of Thrift > for certain things (e.g., to aggressively drop connections for clients that > send invalid/malformed requests). ProcessFunction makes it near impossible to > do this -- not only does it swallow the exception, it also loses all > information about the original exception and just writes out a generic > TApplicationException. > IMO ProcessFunction should only catch TException. If the application code > wants to use other exceptions for some reason (in particular, Errors and > RuntimeExceptions), Thrift shouldn't prevent that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1186: THRIFT-1805 Provide option for handling RTEs
GitHub user ctubbsii opened a pull request: https://github.com/apache/thrift/pull/1186 THRIFT-1805 Provide option for handling RTEs Adds a Java option to the generator to generate code which lets Thrift handle RuntimeExceptions from a service, and present them as TApplicationException to the client. This addresses a back-and-forth debate over the expected behavior of this in Java services, and the resulting breakage, as described in THRIFT-1805 and related issues, by making the behavior configurable. Throwable types are not handled, because it is generally ill-advised to handle Error types within a Java application. So, this only allows configuration of handling RuntimeException. This patch preserves current behavior as the default, and works with previously generated code. This patch does not affect AsyncProcessFunction exception handling. Related JIRAs: THRIFT-378, THRIFT-1658, THRIFT-1805, THRIFT-3607 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ctubbsii/thrift handle-runtimeexceptions Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1186.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1186 commit 48ee27b210edf2d92af2f5060820d77ca0898aff Author: Christopher Tubbs Date: 2017-02-10T03:32:00Z THRIFT-1805 Provide option for handling RTEs Adds a Java option to the generator to generate code which lets Thrift handle RuntimeExceptions from a service, and present them as TApplicationException to the client. This addresses a back-and-forth debate over the expected behavior of this in Java services, and the resulting breakage, as described in THRIFT-1805 and related issues, by making the behavior configurable. Throwable types are not handled, because it is generally ill-advised to handle Error types within a Java application. So, this only allows configuration of handling RuntimeException. This patch preserves current behavior as the default, and works with previously generated code. This patch does not affect AsyncProcessFunction exception handling. Related JIRAs: THRIFT-378, THRIFT-1658, THRIFT-1805, THRIFT-3607 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1178: THRIFT-4072 php: TCurlClient - Add the possibility to se...
Github user swatkatz commented on the issue: https://github.com/apache/thrift/pull/1178 thank you @jeking3 and @Jens-G .. I will give a shot at adding tests for this class in a separate PR. Also, thank you for letting me the correct way of setting up the PRs. Really appreciate the guidance. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4072) Add the possibility to send custom headers in TCurlClient
[ https://issues.apache.org/jira/browse/THRIFT-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860409#comment-15860409 ] ASF GitHub Bot commented on THRIFT-4072: Github user swatkatz commented on the issue: https://github.com/apache/thrift/pull/1178 thank you @jeking3 and @Jens-G .. I will give a shot at adding tests for this class in a separate PR. Also, thank you for letting me the correct way of setting up the PRs. Really appreciate the guidance. > Add the possibility to send custom headers in TCurlClient > - > > Key: THRIFT-4072 > URL: https://issues.apache.org/jira/browse/THRIFT-4072 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.10.0 >Reporter: Swati Kumar >Assignee: James E. King, III >Priority: Minor > Labels: patch > Fix For: 0.11.0 > > > Currently, there is no ability to add custom headers in TCurlClient.php which > is the PHP implementation of https://issues.apache.org/jira/browse/THRIFT-2394 > The THttpClient already supports it > https://issues.apache.org/jira/browse/THRIFT-1878 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4082) Java library can't parse JSON generated by javascript TJSONProtocol
Christopher Wright created THRIFT-4082:
--
Summary: Java library can't parse JSON generated by javascript
TJSONProtocol
Key: THRIFT-4082
URL: https://issues.apache.org/jira/browse/THRIFT-4082
Project: Thrift
Issue Type: Bug
Components: Java - Library
Affects Versions: 0.10.0
Reporter: Christopher Wright
Thrift definition:
struct Entity {
1: string id;
}
service EntityService {
void save(1: Entity entity);
}
JSON document: [1,"save",1,0,{"1":{"rec":{"1":{"str":"q19786052"]
Error:
org.apache.thrift.protocol.TProtocolException: Unexpected character:}
(Additionally, the parser would ideally state where it found the unexpected
character.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-3622) Fix deprecated uses of std::auto_ptr
[
https://issues.apache.org/jira/browse/THRIFT-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860125#comment-15860125
]
ASF GitHub Bot commented on THRIFT-3622:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1183
The build failure is about node.js version dependencies which curiously is
in an unrelated but active pull request for THRIFT-4074. There were no errors
in Travis CI to worry about here; waiting for Appveyor before merging.
> Fix deprecated uses of std::auto_ptr
>
>
> Key: THRIFT-3622
> URL: https://issues.apache.org/jira/browse/THRIFT-3622
> Project: Thrift
> Issue Type: Task
> Components: C++ - Library
>Reporter: John Sirois
>Assignee: James E. King, III
>
> We have some in lib/cpp, like so:
> {noformat}
> JSONProtoTest.cpp:35:13: warning: ‘template class std::auto_ptr’ is
> deprecated [-Wdeprecated-declarations]
> static std::auto_ptr ooe;
> ^
> In file included from /usr/include/c++/5.3.0/bits/locale_conv.h:41:0,
> from /usr/include/c++/5.3.0/locale:43,
> from /usr/include/c++/5.3.0/iomanip:43,
> from JSONProtoTest.cpp:22:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1183: THRIFT-3622: remove auto_ptr use in the codebase because...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1183 The build failure is about node.js version dependencies which curiously is in an unrelated but active pull request for THRIFT-4074. There were no errors in Travis CI to worry about here; waiting for Appveyor before merging. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (THRIFT-4072) Add the possibility to send custom headers in TCurlClient
[ https://issues.apache.org/jira/browse/THRIFT-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4072. Resolution: Fixed Fix Version/s: 0.11.0 Committed - thanks. > Add the possibility to send custom headers in TCurlClient > - > > Key: THRIFT-4072 > URL: https://issues.apache.org/jira/browse/THRIFT-4072 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.10.0 >Reporter: Swati Kumar >Assignee: James E. King, III >Priority: Minor > Labels: patch > Fix For: 0.11.0 > > > Currently, there is no ability to add custom headers in TCurlClient.php which > is the PHP implementation of https://issues.apache.org/jira/browse/THRIFT-2394 > The THttpClient already supports it > https://issues.apache.org/jira/browse/THRIFT-1878 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4072) Add the possibility to send custom headers in TCurlClient
[ https://issues.apache.org/jira/browse/THRIFT-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860119#comment-15860119 ] ASF GitHub Bot commented on THRIFT-4072: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1178 > Add the possibility to send custom headers in TCurlClient > - > > Key: THRIFT-4072 > URL: https://issues.apache.org/jira/browse/THRIFT-4072 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.10.0 >Reporter: Swati Kumar >Assignee: James E. King, III >Priority: Minor > Labels: patch > Fix For: 0.11.0 > > > Currently, there is no ability to add custom headers in TCurlClient.php which > is the PHP implementation of https://issues.apache.org/jira/browse/THRIFT-2394 > The THttpClient already supports it > https://issues.apache.org/jira/browse/THRIFT-1878 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1178: THRIFT-4072 php: TCurlClient - Add the possibilit...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1178 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Assigned] (THRIFT-4072) Add the possibility to send custom headers in TCurlClient
[ https://issues.apache.org/jira/browse/THRIFT-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-4072: -- Assignee: James E. King, III > Add the possibility to send custom headers in TCurlClient > - > > Key: THRIFT-4072 > URL: https://issues.apache.org/jira/browse/THRIFT-4072 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.10.0 >Reporter: Swati Kumar >Assignee: James E. King, III >Priority: Minor > Labels: patch > > Currently, there is no ability to add custom headers in TCurlClient.php which > is the PHP implementation of https://issues.apache.org/jira/browse/THRIFT-2394 > The THttpClient already supports it > https://issues.apache.org/jira/browse/THRIFT-1878 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4072) Add the possibility to send custom headers in TCurlClient
[ https://issues.apache.org/jira/browse/THRIFT-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860106#comment-15860106 ] James E. King, III commented on THRIFT-4072: I checked the builds and the failures were unrelated. I'll merge this. > Add the possibility to send custom headers in TCurlClient > - > > Key: THRIFT-4072 > URL: https://issues.apache.org/jira/browse/THRIFT-4072 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.10.0 >Reporter: Swati Kumar >Priority: Minor > Labels: patch > > Currently, there is no ability to add custom headers in TCurlClient.php which > is the PHP implementation of https://issues.apache.org/jira/browse/THRIFT-2394 > The THttpClient already supports it > https://issues.apache.org/jira/browse/THRIFT-1878 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4072) Add the possibility to send custom headers in TCurlClient
[ https://issues.apache.org/jira/browse/THRIFT-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860097#comment-15860097 ] ASF GitHub Bot commented on THRIFT-4072: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1178 If the class has no testing at all then I would not require you to add tests in order to get committed, however as Jens suggested it would improve the quality of the project if tests were put in, so I always ask. It looks like you are making modifications in your master branch and they are getting sync'd into this pull request. In the future I would recommend that you create a branch off master first, like "git checkout -b THRIFT-4072" and then submit a pull request from that branch instead so it is isolated from the changes in your master. There should only be one commit for your changes... it looks like the way you have it set up, every time the apache master is revised your pull request will rebuild here, which is a bit heavy. If the previous build was clean I can merge this. > Add the possibility to send custom headers in TCurlClient > - > > Key: THRIFT-4072 > URL: https://issues.apache.org/jira/browse/THRIFT-4072 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.10.0 >Reporter: Swati Kumar >Priority: Minor > Labels: patch > > Currently, there is no ability to add custom headers in TCurlClient.php which > is the PHP implementation of https://issues.apache.org/jira/browse/THRIFT-2394 > The THttpClient already supports it > https://issues.apache.org/jira/browse/THRIFT-1878 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1178: THRIFT-4072 php: TCurlClient - Add the possibility to se...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1178 If the class has no testing at all then I would not require you to add tests in order to get committed, however as Jens suggested it would improve the quality of the project if tests were put in, so I always ask. It looks like you are making modifications in your master branch and they are getting sync'd into this pull request. In the future I would recommend that you create a branch off master first, like "git checkout -b THRIFT-4072" and then submit a pull request from that branch instead so it is isolated from the changes in your master. There should only be one commit for your changes... it looks like the way you have it set up, every time the apache master is revised your pull request will rebuild here, which is a bit heavy. If the previous build was clean I can merge this. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4072) Add the possibility to send custom headers in TCurlClient
[ https://issues.apache.org/jira/browse/THRIFT-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860086#comment-15860086 ] ASF GitHub Bot commented on THRIFT-4072: Github user Jens-G commented on the issue: https://github.com/apache/thrift/pull/1178 @swatkatz: Having a test is better than not having one. We have way too many patches without tests, so if you provide one, we increase quality standards (and you will be our positive role model 👍) How awesome is that? > Add the possibility to send custom headers in TCurlClient > - > > Key: THRIFT-4072 > URL: https://issues.apache.org/jira/browse/THRIFT-4072 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.10.0 >Reporter: Swati Kumar >Priority: Minor > Labels: patch > > Currently, there is no ability to add custom headers in TCurlClient.php which > is the PHP implementation of https://issues.apache.org/jira/browse/THRIFT-2394 > The THttpClient already supports it > https://issues.apache.org/jira/browse/THRIFT-1878 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1178: THRIFT-4072 php: TCurlClient - Add the possibility to se...
Github user Jens-G commented on the issue: https://github.com/apache/thrift/pull/1178 @swatkatz: Having a test is better than not having one. We have way too many patches without tests, so if you provide one, we increase quality standards (and you will be our positive role model ð) How awesome is that? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4064) Update node library dependencies
[ https://issues.apache.org/jira/browse/THRIFT-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860083#comment-15860083 ] ASF GitHub Bot commented on THRIFT-4064: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1175 I looked at the build results and in build job #2 it was still using node.js version 0.10 presumably because that's what is on the base install on the build slave being used: NodeJS Library: Using NodeJS .. : /usr/bin/nodejs Using NodeJS version... : v0.10.29 The build failure has led me to a number of questions about how we maintain our docker images, who is responsible for that, and how we stage changes like this so CI builds can pass and prove the changes and new docker image are okay. I have sent emails out to others on the development team to learn this process and see if it needs to be modified to handle this type of change. > Update node library dependencies > > > Key: THRIFT-4064 > URL: https://issues.apache.org/jira/browse/THRIFT-4064 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.10.0 >Reporter: Andres Suarez >Assignee: James E. King, III > > ws@0.4.32 is really old and presents issues for users using modern versions > of Node (see > https://github.com/apache/thrift/pull/672#issuecomment-276678791). Its should > be updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1175: THRIFT-4064 Update node library dependencies
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1175 I looked at the build results and in build job #2 it was still using node.js version 0.10 presumably because that's what is on the base install on the build slave being used: NodeJS Library: Using NodeJS .. : /usr/bin/nodejs Using NodeJS version... : v0.10.29 The build failure has led me to a number of questions about how we maintain our docker images, who is responsible for that, and how we stage changes like this so CI builds can pass and prove the changes and new docker image are okay. I have sent emails out to others on the development team to learn this process and see if it needs to be modified to handle this type of change. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4072) Add the possibility to send custom headers in TCurlClient
[ https://issues.apache.org/jira/browse/THRIFT-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860067#comment-15860067 ] ASF GitHub Bot commented on THRIFT-4072: Github user swatkatz commented on the issue: https://github.com/apache/thrift/pull/1178 @jeking3 : I can add the tests as you suggest, but since this is a minor feature improvement and there don't seem to be any tests that exist for this class (and I see that other such patches don't have them either e.g. https://github.com/apache/thrift/commit/1f9717d192137d06927846cc2f2f7e380e5da834), I was just wondering what the standard practice around this was? > Add the possibility to send custom headers in TCurlClient > - > > Key: THRIFT-4072 > URL: https://issues.apache.org/jira/browse/THRIFT-4072 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.10.0 >Reporter: Swati Kumar >Priority: Minor > Labels: patch > > Currently, there is no ability to add custom headers in TCurlClient.php which > is the PHP implementation of https://issues.apache.org/jira/browse/THRIFT-2394 > The THttpClient already supports it > https://issues.apache.org/jira/browse/THRIFT-1878 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1178: THRIFT-4072 php: TCurlClient - Add the possibility to se...
Github user swatkatz commented on the issue: https://github.com/apache/thrift/pull/1178 @jeking3 : I can add the tests as you suggest, but since this is a minor feature improvement and there don't seem to be any tests that exist for this class (and I see that other such patches don't have them either e.g. https://github.com/apache/thrift/commit/1f9717d192137d06927846cc2f2f7e380e5da834), I was just wondering what the standard practice around this was? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4070) Generated PHP for Thrift sets are incompatible with PHP
[
https://issues.apache.org/jira/browse/THRIFT-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860039#comment-15860039
]
David Reiman commented on THRIFT-4070:
--
http://php.net/manual/en/intro.ds.php The built-in Set data structure and other
data structures are only available in PHP 7; many apps that use Thrift may
still be on PHP 5.x
> Generated PHP for Thrift sets are incompatible with PHP
> ---
>
> Key: THRIFT-4070
> URL: https://issues.apache.org/jira/browse/THRIFT-4070
> Project: Thrift
> Issue Type: Bug
> Components: PHP - Compiler
>Reporter: David Reiman
>
> In the `TBase` class that all Thrift generated code inherits from, there is a
> `_writeList` method that takes a boolean of whether or not the "list" in
> question is a set. The assumption here is that since PHP has no built-in Set
> data type, we can duplicate the uniqueness constraint of Sets by looking at
> the keys of a PHP associative array. Here's the associated code in
> `_writeList`:
> ```
> foreach ($var as $key => $val) {
> $elem = $set ? $key : $val;
> if (isset($ewrite)) {
> $xfer += $output->$ewrite($elem);
> } else {
> switch ($etype) {
> case TType::STRUCT:
> $xfer += $elem->write($output);
> break;
> ```
> I want to point out again that if we're using a `TType::SET`, the `$set`
> variable will be `true`, and `$elem` will be the `$key`, not the `$value`.
> Here's the problem, from PHP array documentation
> (http://php.net/manual/en/language.types.array.php):
> "The key can either be an integer or a string. The value can be of any
> type...Arrays and objects can not be used as keys. Doing so will result in a
> warning: Illegal offset type."
> In other words, it is impossible to implement a Thrift set of anything other
> than strings or integers given the current implementation of PHP generated
> code.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1185: Thrift 3369 - Third try to merge SSL c_glib
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1185 Thank you for the effort --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
RE: Need help to cross compile thrift to armel on Ubuntu 14.04LTS
I haven't tried a cross compile however there might be some useful tips out there from others: http://stackoverflow.com/questions/14743482/how-to-cross-compile-thrift-for-arm http://stackoverflow.com/questions/17799753/cross-compiling-apache-thrift-program-for-armhf Note in the thrift master right now, we did remove those two AC_ entries from configure. They cause a warning during bootstrap but it was done to alow for clang static analysis. Sorry I can't be of more help... - Jim -Original Message- From: Samba Siva Karthik Bollam [mailto:sambabol...@hotmail.com] Sent: Wednesday, February 8, 2017 9:37 PM To: dev@thrift.apache.org Subject: Need help to cross compile thrift to armel on Ubuntu 14.04LTS Hi I am trying to cross compile thrift to armel using ./configure --host=arm-linux-gnueabi --without-java --without-qt4 --without-python --with-c_glib --with-cpp --without-test make But I am getting errors make[4]: Entering directory `/home/XCode/thrift/thrift/lib/cpp/test' ../../../compiler/cpp/thrift --gen cpp ../../../test/DebugProtoTest.thrift /lib/ld-linux.so.3: No such file or directory I would appreciate if anyone can help me to get the cross compile Karthik --- PRIVACY STATEMENT: This message is a PRIVATE communication. This message and all attachments are a private communication sent by SimpliVity and are considered to be confidential or protected by privilege. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the information contained in or attached to this message is strictly prohibited. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. ---
[GitHub] thrift issue #1185: Thrift 3369 - Third try to merge SSL c_glib
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1185 Thanks, I'll wait for the CI build results before I comment. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859738#comment-15859738 ] ASF GitHub Bot commented on THRIFT-3369: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/930 Re-rebased > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1185: Thrift 3369 - Third try to merge SSL c_glib
GitHub user gadLinux opened a pull request: https://github.com/apache/thrift/pull/1185 Thrift 3369 - Third try to merge SSL c_glib This pull request is the third try to merge against master. It implements SSL on c_glib with certificate pining included. The old pull request is 930. https://github.com/apache/thrift/pull/930 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gadLinux/thrift thrift-3369 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1185.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1185 commit b1815ec42f848798422765d955cea0a815fcb525 Author: Gonzalo Aguilar Delgado Date: 2016-03-07T12:42:44Z Implement basic version of the TLS transport commit d4c6207d9dabc138ff06a2b21a4477a5c440187c Author: Gonzalo Aguilar Delgado Date: 2016-03-07T14:27:22Z Certificate pinning features incorporated commit b691372edfadfc124152645ec527686a960cb84b Author: Gonzalo Aguilar Delgado Date: 2016-03-07T14:29:10Z Add test for certificate pinning commit f09d8eb55246638d8078857d7ef84459caf84c5d Author: Gonzalo Aguilar Delgado Date: 2016-03-07T14:30:10Z Add level2 test public key chain commit 2003ea188de1be4a13e8b2e859cc3b3d1a39e541 Author: Gonzalo Aguilar Delgado Date: 2016-03-07T20:49:42Z Fix dependency of ssl for tests commit 0f8699ddc3e7f5d2b8c8c36283b0c520d30f7ddf Author: Gonzalo Aguilar Delgado Date: 2016-08-04T23:33:29Z Enhace code, fix some issues and plug some bugs. Fix pull request #930 commit d0f2ac1a957912a59131b2e93028e3022d2a9f82 Author: Gonzalo Aguilar Delgado Date: 2016-08-04T23:40:57Z Fix style commit 01dcd95dda883f65ce6baa296815f964ce6f3904 Author: Gonzalo Aguilar Delgado Date: 2016-08-04T23:58:10Z Add file to cmake commit 5d9cb52119872f431f187f7166b374e6488b6229 Author: Gonzalo Aguilar Delgado Date: 2016-08-05T09:09:18Z Fix tests and the bug that produced it. commit d070e6dc6502e4e9cb8ba5ef3a68c0c00a09800f Author: Gonzalo Aguilar Delgado Date: 2016-12-29T11:42:04Z Fix tests so we don't include tests that require a server until server is ready. Fix compilation with cmake commit 40ec9d1bb9469a59ebfe9fea308cb9cebca8157d Author: Gonzalo Aguilar Delgado Date: 2016-12-29T11:46:30Z Fix tests in cmake commit cada6b8a8907ac00ed9c6995b1d88efd9f0471cc Author: Gonzalo Aguilar Delgado Date: 2017-01-26T16:18:16Z Remove the public key in favor of the existing one. Re-add the test that was unintentionally removed. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #930: THRIFT-3369 : Implement SSL/TLS support on C with ...
Github user gadLinux closed the pull request at: https://github.com/apache/thrift/pull/930 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859742#comment-15859742 ] ASF GitHub Bot commented on THRIFT-3369: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/930 I will reopen the merge > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #930: THRIFT-3369 : Implement SSL/TLS support on C with c_glib
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/930 Re-rebased --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #930: THRIFT-3369 : Implement SSL/TLS support on C with c_glib
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/930 I will reopen the merge --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859743#comment-15859743 ] ASF GitHub Bot commented on THRIFT-3369: Github user gadLinux closed the pull request at: https://github.com/apache/thrift/pull/930 > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4060) Thrift printTo ostream overload mechanism breaks down when types are nested
[
https://issues.apache.org/jira/browse/THRIFT-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859670#comment-15859670
]
James E. King, III commented on THRIFT-4060:
[~hcorg], I would appreciate your input on this change since you implemented
THRIFT-3336 and I reviewed it. In particular, I'm trying to decide if there is
any value in the printTo mechanism. It is the standard way for someone to
create an overridable conversion to a stream in C++ since you cannot make
operator << virtual (see:
http://stackoverflow.com/questions/4571611/making-operator-virtual) and that is
what we ended up settling on, however that solution does not work in practice
for thrift generated code (see description of THRIFT-4060 for more info). My
inclination right now is to remove the printTo implementation and instead use
this annotation/compiler flag to control whether operator << is defined or just
declared as opposed to keeping both.
> Thrift printTo ostream overload mechanism breaks down when types are nested
> ---
>
> Key: THRIFT-4060
> URL: https://issues.apache.org/jira/browse/THRIFT-4060
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.9.3, 0.10.0
> Environment: Ubuntu 14.04 LTS
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> I'm in the middle of converting a project that provides some ostream
> operators (for logging purposes) for a number of thrift structures. The
> project was using 0.8.0 and in 0.9.3 some ostream operator overloads were
> added with THRIFT-3336. The solution that was provided here runs into
> complications if a thrift structure is contained within another one. Take
> this simple example:
> h4. Thrift
> {noformat}
> namespace cpp example.detail
> struct Lower {
>1: binary lowerBinary
> }
> struct Higher {
> 1: set lowers
> }
> {noformat}
> h4. C++
> {noformat}
> namespace example {
> class MyLower : public detail::Lower
> {
> virtual void printTo(std::ostream& os) const override;
> }
> class MyHigher : public detail::Higher
> {
> virtual void printTo(std::ostream& os) const override
> {
> os << lowers;
> // here's the problem, lowers is a set when it
> serializes in,
> // not a set, so I cannot override it...
> }
> }
> }
> {noformat}
> I'm considering adding an annotation to the thrift IDL that the compiler will
> recognize that allows someone to say, "I am going to provide my own
> operator<< for this structure, don't generate one". This would replace the
> printTo mechanism that was added in THRIFT-3336.
> Here is an example:
> {noformat}
> namespace cpp example.detail
> struct MyLower {
>1: binary lowerBinary
> } (cpp.customostream)
> struct MyHigher {
> 1: set lowers
> }
> {noformat}
> The annotation {{cpp.customostream}} (or the compiler option {{--gen
> cpp:no_ostream_operators}} for global effect) tells the compiler to emit only
> the declaration of the {{operator <<}} but does not emit a definition
> (implementation). It would be up to the implementation building against the
> generated code to provide an operator << if such an operator is needed for
> conversion to a stream (cout, lexical_cast to string, etc..).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (THRIFT-4060) Thrift printTo ostream overload mechanism breaks down when types are nested
[
https://issues.apache.org/jira/browse/THRIFT-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-4060:
---
Description:
I'm in the middle of converting a project that provides some ostream operators
(for logging purposes) for a number of thrift structures. The project was
using 0.8.0 and in 0.9.3 some ostream operator overloads were added with
THRIFT-3336. The solution that was provided here runs into complications if a
thrift structure is contained within another one. Take this simple example:
h4. Thrift
{noformat}
namespace cpp example.detail
struct Lower {
1: binary lowerBinary
}
struct Higher {
1: set lowers
}
{noformat}
h4. C++
{noformat}
namespace example {
class MyLower : public detail::Lower
{
virtual void printTo(std::ostream& os) const override;
}
class MyHigher : public detail::Higher
{
virtual void printTo(std::ostream& os) const override
{
os << lowers;
// here's the problem, lowers is a set when it
serializes in,
// not a set, so I cannot override it...
}
}
}
{noformat}
I'm considering adding an annotation to the thrift IDL that the compiler will
recognize that allows someone to say, "I am going to provide my own operator<<
for this structure, don't generate one". This would replace the printTo
mechanism that was added in THRIFT-3336.
Here is an example:
{noformat}
namespace cpp example.detail
struct MyLower {
1: binary lowerBinary
} (cpp.customostream)
struct MyHigher {
1: set lowers
}
{noformat}
The annotation {{cpp.customostream}} (or the compiler option {{--gen
cpp:no_ostream_operators}} for global effect) tells the compiler to emit only
the declaration of the {{operator <<}} but does not emit a definition
(implementation). It would be up to the implementation building against the
generated code to provide an operator << if such an operator is needed for
conversion to a stream (cout, lexical_cast to string, etc..).
was:
I'm in the middle of converting a project that provides some ostream operators
(for logging purposes) for a number of thrift structures. The project was
using 0.8.0 and in 0.9.3 some ostream operator overloads were added with
THRIFT-3336. The solution that was provided here runs into complications if a
thrift structure is contained within another one. Take this simple example:
h4. Thrift
{noformat}
namespace cpp example.detail
struct Lower {
1: binary lowerBinary
}
struct Higher {
1: set lowers
}
{noformat}
h4. C++
{noformat}
namespace example {
class Lower : public detail::Lower
{
virtual void printTo(std::ostream& os) const override;
}
class Higher : public detail::Higher
{
virtual void printTo(std::ostream& os) const override
{
os << lowers; // WHOOPS!
// I cannot say os << lowers, since lowers is an example::detail
concept
// it will print the thrift operator output here
}
}
}
{noformat}
I'm considering adding an anotation to the thrift IDL that the compiler will
recognize that allows someone to say, "I am going to provide my own operator<<
for this structure, don't generate one".
This will allow existing projects with this issue to maintain compatibility
without major refactoring. Here is an example:
{noformat}
namespace cpp example.detail
struct Lower {
1: binary lowerBinary
} (cpp.customostream)
struct Higher {
1: set lowers
}
{noformat}
For Lower, this would omit any operator << by the compiler, and thus also would
not emit a printTo override for Lower. It would be up to the implementation
building against the generated code to provide an operator <<.
> Thrift printTo ostream overload mechanism breaks down when types are nested
> ---
>
> Key: THRIFT-4060
> URL: https://issues.apache.org/jira/browse/THRIFT-4060
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.9.3, 0.10.0
> Environment: Ubuntu 14.04 LTS
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> I'm in the middle of converting a project that provides some ostream
> operators (for logging purposes) for a number of thrift structures. The
> project was using 0.8.0 and in 0.9.3 some ostream operator overloads were
> added with THRIFT-3336. The solution that was provided here runs into
> complications if a thrift structure is contained within another one. Take
> this simple example:
> h4. Thrift
> {noformat}
> namespace cpp example.detail
> struct Lower {
>1: binary lowerBinary
> }
> struct Higher {
> 1: set lowers
> }
> {noformat}
> h4. C++
> {noformat}
> namespace example {
> class MyLower : public detail::Lower
> {
> virtual void printTo(std::ostream& os) const override;
> }
> class MyHigher
[jira] [Commented] (THRIFT-3351) Publishing Dart Bindings for Thrift to Pub (pub.dartlang.org)
[ https://issues.apache.org/jira/browse/THRIFT-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859646#comment-15859646 ] Mark Erickson commented on THRIFT-3351: --- Hi [~jfarrell] - now that 0.10.0 is out with Dart included, can we push the dart library to the Dart pub server? > Publishing Dart Bindings for Thrift to Pub (pub.dartlang.org) > - > > Key: THRIFT-3351 > URL: https://issues.apache.org/jira/browse/THRIFT-3351 > Project: Thrift > Issue Type: Story > Components: Dart - Library >Reporter: Evan Weible >Assignee: Jake Farrell > > The thrift bindings for the Dart language are in progress here: > https://github.com/apache/thrift/pull/608 > In order to utilize them in Dart, the Dart package would need to be published > to https://pub.dartlang.org. This is a relatively simple process - from the > `thrift/lib/dart/` directory it would only require running `pub publish`. > More information here: https://www.dartlang.org/tools/pub/cmd/pub-lish.html > Since we're creating the Dart bindings for Thrift, we are also more than > willing to publish them to Pub - but we wanted to give the apache thrift team > the opportunity to handle this process. Ownership of the publishing process > can be shared by adding multiple email addresses to the uploader list, and > said list can be updated at any time. > How do you wish to proceed with this? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4081) Provide a MinGW 64-bit Appveyor CI build for better pull request validation
James E. King, III created THRIFT-4081: -- Summary: Provide a MinGW 64-bit Appveyor CI build for better pull request validation Key: THRIFT-4081 URL: https://issues.apache.org/jira/browse/THRIFT-4081 Project: Thrift Issue Type: Improvement Components: Build Process Affects Versions: 0.10.0 Environment: Appveyor Reporter: James E. King, III We current build in Visual Studio 2015 on Appveyor. We do not use the CI environment to verify that MinGW still builds successfully. I would recommend that we add a CI build job to Appveyor and/or extend the existing job to build with the latest MinGW 64-bit environment which includes gcc-6.3.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4073) enum files are still being generated with unused imports
[ https://issues.apache.org/jira/browse/THRIFT-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859626#comment-15859626 ] ASF GitHub Bot commented on THRIFT-4073: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1182 > enum files are still being generated with unused imports > > > Key: THRIFT-4073 > URL: https://issues.apache.org/jira/browse/THRIFT-4073 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler >Affects Versions: 0.10.0 >Reporter: Christopher Tubbs >Assignee: James E. King, III > Fix For: 0.11.0 > > > I love that import statements are no longer being generated, because it means > less "unused imports" warnings from my compiler and checkstyle rules. > However, it appears that the enum generation did not get as much care as > class file generation. There still remain some import statements in enum > files. All of them are unused because of the fully-qualified types being used > instead, so they are safe to delete. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (THRIFT-4073) enum files are still being generated with unused imports
[ https://issues.apache.org/jira/browse/THRIFT-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4073. Resolution: Fixed Assignee: James E. King, III Fix Version/s: 0.11.0 Passed CI, merged, thanks! > enum files are still being generated with unused imports > > > Key: THRIFT-4073 > URL: https://issues.apache.org/jira/browse/THRIFT-4073 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler >Affects Versions: 0.10.0 >Reporter: Christopher Tubbs >Assignee: James E. King, III > Fix For: 0.11.0 > > > I love that import statements are no longer being generated, because it means > less "unused imports" warnings from my compiler and checkstyle rules. > However, it appears that the enum generation did not get as much care as > class file generation. There still remain some import statements in enum > files. All of them are unused because of the fully-qualified types being used > instead, so they are safe to delete. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1182: THRIFT-4073 enum files are still being generated ...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1182 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #1184: THRIFT-4075: better support for headers-only boos...
GitHub user jeking3 opened a pull request: https://github.com/apache/thrift/pull/1184 THRIFT-4075: better support for headers-only boost with mingw Also fixed a warning from gcc where an alignment pragma was in the wrong place. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jeking3/thrift THRIFT-4075 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1184.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1184 commit 764ab32d594840323da619bd0085f16456df8169 Author: James E. King, III Date: 2017-02-09T14:37:38Z THRIFT-4075: better support for headers-only boost with mingw --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4075) Better MinGW support for headers-only boost (without thread library)
[
https://issues.apache.org/jira/browse/THRIFT-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859621#comment-15859621
]
ASF GitHub Bot commented on THRIFT-4075:
GitHub user jeking3 opened a pull request:
https://github.com/apache/thrift/pull/1184
THRIFT-4075: better support for headers-only boost with mingw
Also fixed a warning from gcc where an alignment pragma was in the wrong
place.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jeking3/thrift THRIFT-4075
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/thrift/pull/1184.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1184
commit 764ab32d594840323da619bd0085f16456df8169
Author: James E. King, III
Date: 2017-02-09T14:37:38Z
THRIFT-4075: better support for headers-only boost with mingw
> Better MinGW support for headers-only boost (without thread library)
>
>
> Key: THRIFT-4075
> URL: https://issues.apache.org/jira/browse/THRIFT-4075
> Project: Thrift
> Issue Type: Improvement
> Components: Build Process, C++ - Library
>Affects Versions: 0.10.0
> Environment: MingW 5.3 / QtCreator (CMake)
>Reporter: Aurelien Regat-Barrel
>Assignee: James E. King, III
>Priority: Trivial
>
> Hello,
> I am building Thrift on Windows with QtCreator as a front-end on top of
> CMake. I am using MingW 5.3 (Qt 5.7).
> I saw that you are working on improving the build experience on Windows with
> MingW (#THRIFT-4046) so here are my suggestions :)
> - The doc says Boost 1.53 is required, but actually *Boost 1.63 works better*
> because they fixed some issues preventing the use of Boost as header only
> - I was able to build Thrift with *Boost as header only* with very small
> changes. **Boost threads is not required** for MingW 5.3 (it should also work
> with MingW 4.9). This makes the build process much simpler because we just
> have to unzip the boost package and that's all.
> - Therefore you should consider passing *-DWITH_BOOSTTHREADS=OFF* in the
> [README-MSYS2.md
> doc|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=build/cmake/README-MSYS2.md;h=06c0205056658e743352dabe9fbbc90e1eeaf49e;hb=2d6060d882069ed3e3d6302aa63ea7eb4bb155ad]
> - boost/cstdint.hpp is not required (*#define HAVE_STDINT_H*)
> Here's the changes I made to
> *thrift-0.10.0\lib\cpp\src\thrift\windows\config.h* to better support MingW
> and make it possible to use boost as header only.
> Since I don't know how to attach a patch here, I'll do it old school :)
> Before :
> {noformat}
> // use std::thread in MSVC11 (2012) or newer
> #if _MSC_VER >= 1700
> #define USE_STD_THREAD 1
> #else
> // otherwise use boost threads
> #define USE_BOOST_THREAD 1
> #endif
> // VS2010 or later has stdint.h
> #if _MSC_VER >= 1600
> #define HAVE_STDINT_H 1
> #endif
> {noformat}
> After :
> {noformat}
> // use std::thread in MSVC11 (2012) or newer
> #if defined(_MSC_VER) && (_MSC_VER >= 1700)
> #define USE_STD_THREAD 1
> #elif defined(__MINGW32__)
> #define USE_STD_THREAD 1
> #else
> // otherwise use boost threads
> #define USE_BOOST_THREAD 1
> #endif
> // VS2010 or later has stdint.h
> #if defined(_MSC_VER) && (_MSC_VER >= 1600)
> #define HAVE_STDINT_H 1
> #elif defined(__MINGW32__)
> #define HAVE_STDINT_H 1
> #endif
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1183: THRIFT-3622: remove auto_ptr use in the codebase ...
GitHub user jeking3 opened a pull request: https://github.com/apache/thrift/pull/1183 THRIFT-3622: remove auto_ptr use in the codebase because it is deprecated You can merge this pull request into a Git repository by running: $ git pull https://github.com/jeking3/thrift THRIFT-3622 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1183.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1183 commit b4b47051046f8d099e9eeeb8e5c565ec7cd8a055 Author: James E. King, III Date: 2017-02-09T14:36:01Z THRIFT-3622: remove auto_ptr use in the codebase because it is deprecated --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3622) Fix deprecated uses of std::auto_ptr
[
https://issues.apache.org/jira/browse/THRIFT-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859614#comment-15859614
]
ASF GitHub Bot commented on THRIFT-3622:
GitHub user jeking3 opened a pull request:
https://github.com/apache/thrift/pull/1183
THRIFT-3622: remove auto_ptr use in the codebase because it is deprecated
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jeking3/thrift THRIFT-3622
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/thrift/pull/1183.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1183
commit b4b47051046f8d099e9eeeb8e5c565ec7cd8a055
Author: James E. King, III
Date: 2017-02-09T14:36:01Z
THRIFT-3622: remove auto_ptr use in the codebase because it is deprecated
> Fix deprecated uses of std::auto_ptr
>
>
> Key: THRIFT-3622
> URL: https://issues.apache.org/jira/browse/THRIFT-3622
> Project: Thrift
> Issue Type: Task
> Components: C++ - Library
>Reporter: John Sirois
>Assignee: James E. King, III
>
> We have some in lib/cpp, like so:
> {noformat}
> JSONProtoTest.cpp:35:13: warning: ‘template class std::auto_ptr’ is
> deprecated [-Wdeprecated-declarations]
> static std::auto_ptr ooe;
> ^
> In file included from /usr/include/c++/5.3.0/bits/locale_conv.h:41:0,
> from /usr/include/c++/5.3.0/locale:43,
> from /usr/include/c++/5.3.0/iomanip:43,
> from JSONProtoTest.cpp:22:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4064) Update node library dependencies
[ https://issues.apache.org/jira/browse/THRIFT-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859597#comment-15859597 ] ASF GitHub Bot commented on THRIFT-4064: Github user zertosh commented on the issue: https://github.com/apache/thrift/pull/1175 The tests are failing because `run-browser`'s browserify can't find `utf-8-validate` (and it won't find `bufferutil` either. Those are optional dependencies of `ws`. You can't seem to configure `run-browser` to tell it to ignore those modules. So I'm going to try adding them to devDeps. > Update node library dependencies > > > Key: THRIFT-4064 > URL: https://issues.apache.org/jira/browse/THRIFT-4064 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.10.0 >Reporter: Andres Suarez >Assignee: James E. King, III > > ws@0.4.32 is really old and presents issues for users using modern versions > of Node (see > https://github.com/apache/thrift/pull/672#issuecomment-276678791). Its should > be updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1175: THRIFT-4064 Update node library dependencies
Github user zertosh commented on the issue: https://github.com/apache/thrift/pull/1175 The tests are failing because `run-browser`'s browserify can't find `utf-8-validate` (and it won't find `bufferutil` either. Those are optional dependencies of `ws`. You can't seem to configure `run-browser` to tell it to ignore those modules. So I'm going to try adding them to devDeps. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3622) Fix deprecated uses of std::auto_ptr
[
https://issues.apache.org/jira/browse/THRIFT-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859592#comment-15859592
]
James E. King, III commented on THRIFT-3622:
Well that was more fun that it needed to be. was
introduced in boost 1.57 and before then an implementation exists in
but that implementation provides
no default deleter. Only one class (TFileTransport) uses the auto_ptr
"release" concept. I have auto_ptr removed and compatible with all boost
versions locally, will submit a PR to get CI validation.
> Fix deprecated uses of std::auto_ptr
>
>
> Key: THRIFT-3622
> URL: https://issues.apache.org/jira/browse/THRIFT-3622
> Project: Thrift
> Issue Type: Task
> Components: C++ - Library
>Reporter: John Sirois
>Assignee: James E. King, III
>
> We have some in lib/cpp, like so:
> {noformat}
> JSONProtoTest.cpp:35:13: warning: ‘template class std::auto_ptr’ is
> deprecated [-Wdeprecated-declarations]
> static std::auto_ptr ooe;
> ^
> In file included from /usr/include/c++/5.3.0/bits/locale_conv.h:41:0,
> from /usr/include/c++/5.3.0/locale:43,
> from /usr/include/c++/5.3.0/iomanip:43,
> from JSONProtoTest.cpp:22:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (THRIFT-3622) Fix deprecated uses of std::auto_ptr
[
https://issues.apache.org/jira/browse/THRIFT-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859551#comment-15859551
]
James E. King, III edited comment on THRIFT-3622 at 2/9/17 2:11 PM:
The easiest fix is to modify the code to include {{}} and
use a {{boost::unique_ptr}} in place of a {{std::auto_ptr}}. If the pointer
never needs to be released and used raw (like passing to a third party C
library), a boost::scoped_ptr is a simpler wrapper which guarantees destruction
when falling out of scope.
This matches the rest of our current code (using boost concepts).
was (Author: jking3):
The easiest fix is to modify the code to include {{}} and
use a {{boost::scoped_ptr}} in place of a {{std::auto_ptr}}.
This matches the rest of our current code.
> Fix deprecated uses of std::auto_ptr
>
>
> Key: THRIFT-3622
> URL: https://issues.apache.org/jira/browse/THRIFT-3622
> Project: Thrift
> Issue Type: Task
> Components: C++ - Library
>Reporter: John Sirois
>Assignee: James E. King, III
>
> We have some in lib/cpp, like so:
> {noformat}
> JSONProtoTest.cpp:35:13: warning: ‘template class std::auto_ptr’ is
> deprecated [-Wdeprecated-declarations]
> static std::auto_ptr ooe;
> ^
> In file included from /usr/include/c++/5.3.0/bits/locale_conv.h:41:0,
> from /usr/include/c++/5.3.0/locale:43,
> from /usr/include/c++/5.3.0/iomanip:43,
> from JSONProtoTest.cpp:22:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4080) Unix sockets can get stuck forever
[
https://issues.apache.org/jira/browse/THRIFT-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859564#comment-15859564
]
David Fankhauser commented on THRIFT-4080:
--
Unfortunately I don't have much time right now. I took a look at the python
implementation to see if I could fix it quickly, but the deprecated argument
parsing of the TSSLServerSocket constructor (would need the timeout there) is a
mess and I have no idea whats going on there. So quickly fixing it is off the
table.
> Unix sockets can get stuck forever
> --
>
> Key: THRIFT-4080
> URL: https://issues.apache.org/jira/browse/THRIFT-4080
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Ubuntu 14.04
>Reporter: David Fankhauser
>Priority: Critical
>
> I had the problem that if the network connection is really bad the server
> sometimes does not accept more connections. "Really bad" means that a simple
> ping event sent via thrift could take 15 seconds.
> Having this issue for nearly 2 years now I could finally figure it out:
> There is no timeout when the socket receives data. After a connection is
> established and the socket object is created, the connection can drop which
> yields to the socket blocking forever.
> I added a timeout in the TSocket accept function which makes the socket throw
> a resource not available error after 30 seconds:
> def accept(self):
> client, addr = self.handle.accept()
> -- added timeout of 30.0 seconds
> client.setsockopt(socket.SOL_SOCKET, socket.SO_RCVTIMEO,
> struct.pack('LL', 30, 0))
> result = TSocket()
> result.setHandle(client)
> return result
> Gives this error:
> buff = self.handle.recv(sz)
> error: [Errno 11] Resource temporarily unavailable
> I also tried using python socket's settimeout() function which does not work.
> Only setting the receive timeout times out dropped connections.
> This bug does not appear on stable connections. However, I have 4 devices
> that are connected via WiFi and my ThreadedServer gets stuck about 4-5 times
> a day. The ThreadedServer has 5 threads, thus all 5 sockets get stuck all
> the time...
> FYI here is the strace of the stuck socket:
> [pid 2698] futex(0x7faf5d80, FUTEX_WAIT_PRIVATE, 0, NULL
> [pid 2697] read(4,
> [pid 2693] accept(7, {sa_family=AF_INET6, sin6_port=htons(39911),
> inet_pton(AF_INET6, ":::46.125.249.41", &sin6_addr), sin6_flowinfo=0,
> sin6_scope_id=0}, [28]) = 6
> [pid 2693] recvfrom(6,
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-3622) Fix deprecated uses of std::auto_ptr
[
https://issues.apache.org/jira/browse/THRIFT-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859551#comment-15859551
]
James E. King, III commented on THRIFT-3622:
The easiest fix is to modify the code to include {{}} and
use a {{boost::scoped_ptr}} in place of a {{std::auto_ptr}}.
This matches the rest of our current code.
> Fix deprecated uses of std::auto_ptr
>
>
> Key: THRIFT-3622
> URL: https://issues.apache.org/jira/browse/THRIFT-3622
> Project: Thrift
> Issue Type: Task
> Components: C++ - Library
>Reporter: John Sirois
>Assignee: James E. King, III
>
> We have some in lib/cpp, like so:
> {noformat}
> JSONProtoTest.cpp:35:13: warning: ‘template class std::auto_ptr’ is
> deprecated [-Wdeprecated-declarations]
> static std::auto_ptr ooe;
> ^
> In file included from /usr/include/c++/5.3.0/bits/locale_conv.h:41:0,
> from /usr/include/c++/5.3.0/locale:43,
> from /usr/include/c++/5.3.0/iomanip:43,
> from JSONProtoTest.cpp:22:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (THRIFT-3622) Fix deprecated uses of std::auto_ptr
[
https://issues.apache.org/jira/browse/THRIFT-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III reopened THRIFT-3622:
Assignee: James E. King, III
Seen under MinGW with gcc 6.3.0 - if we don't correct these, it will ultimately
cause compile errors when the deprcation becomes removal.
{noformat}
[ 87%] Building CXX object
lib/cpp/test/CMakeFiles/JSONProtoTest.dir/JSONProtoTest.cpp.obj
C:\workspace\thrift\lib\cpp\test\JSONProtoTest.cpp:35:13: warning:
'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
static std::auto_ptr ooe;
^~~~
In file included from
C:/msys64/mingw64/include/c++/6.3.0/bits/locale_conv.h:41:0,
from C:/msys64/mingw64/include/c++/6.3.0/locale:43,
from C:/msys64/mingw64/include/c++/6.3.0/iomanip:43,
from C:\workspace\thrift\lib\cpp\test\JSONProtoTest.cpp:22:
C:/msys64/mingw64/include/c++/6.3.0/bits/unique_ptr.h:49:28: note: declared here
template class auto_ptr;
^~~~
C:\workspace\thrift\lib\cpp\test\JSONProtoTest.cpp:68:13: warning:
'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
static std::auto_ptr n;
^~~~
In file included from
C:/msys64/mingw64/include/c++/6.3.0/bits/locale_conv.h:41:0,
from C:/msys64/mingw64/include/c++/6.3.0/locale:43,
from C:/msys64/mingw64/include/c++/6.3.0/iomanip:43,
from C:\workspace\thrift\lib\cpp\test\JSONProtoTest.cpp:22:
C:/msys64/mingw64/include/c++/6.3.0/bits/unique_ptr.h:49:28: note: declared here
template class auto_ptr;
^~~~
C:\workspace\thrift\lib\cpp\test\JSONProtoTest.cpp:108:13: warning:
'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
static std::auto_ptr hm;
^~~~
In file included from
C:/msys64/mingw64/include/c++/6.3.0/bits/locale_conv.h:41:0,
from C:/msys64/mingw64/include/c++/6.3.0/locale:43,
from C:/msys64/mingw64/include/c++/6.3.0/iomanip:43,
from C:\workspace\thrift\lib\cpp\test\JSONProtoTest.cpp:22:
C:/msys64/mingw64/include/c++/6.3.0/bits/unique_ptr.h:49:28: note: declared here
template class auto_ptr;
^~~~
{noformat}
> Fix deprecated uses of std::auto_ptr
>
>
> Key: THRIFT-3622
> URL: https://issues.apache.org/jira/browse/THRIFT-3622
> Project: Thrift
> Issue Type: Task
> Components: C++ - Library
>Reporter: John Sirois
>Assignee: James E. King, III
>
> We have some in lib/cpp, like so:
> {noformat}
> JSONProtoTest.cpp:35:13: warning: ‘template class std::auto_ptr’ is
> deprecated [-Wdeprecated-declarations]
> static std::auto_ptr ooe;
> ^
> In file included from /usr/include/c++/5.3.0/bits/locale_conv.h:41:0,
> from /usr/include/c++/5.3.0/locale:43,
> from /usr/include/c++/5.3.0/iomanip:43,
> from JSONProtoTest.cpp:22:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (THRIFT-4075) Better MinGW support for headers-only boost (without thread library)
[
https://issues.apache.org/jira/browse/THRIFT-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-4075:
---
Summary: Better MinGW support for headers-only boost (without thread
library) (was: Better MingW support)
> Better MinGW support for headers-only boost (without thread library)
>
>
> Key: THRIFT-4075
> URL: https://issues.apache.org/jira/browse/THRIFT-4075
> Project: Thrift
> Issue Type: Improvement
> Components: Build Process, C++ - Library
>Affects Versions: 0.10.0
> Environment: MingW 5.3 / QtCreator (CMake)
>Reporter: Aurelien Regat-Barrel
>Assignee: James E. King, III
>Priority: Trivial
>
> Hello,
> I am building Thrift on Windows with QtCreator as a front-end on top of
> CMake. I am using MingW 5.3 (Qt 5.7).
> I saw that you are working on improving the build experience on Windows with
> MingW (#THRIFT-4046) so here are my suggestions :)
> - The doc says Boost 1.53 is required, but actually *Boost 1.63 works better*
> because they fixed some issues preventing the use of Boost as header only
> - I was able to build Thrift with *Boost as header only* with very small
> changes. **Boost threads is not required** for MingW 5.3 (it should also work
> with MingW 4.9). This makes the build process much simpler because we just
> have to unzip the boost package and that's all.
> - Therefore you should consider passing *-DWITH_BOOSTTHREADS=OFF* in the
> [README-MSYS2.md
> doc|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=build/cmake/README-MSYS2.md;h=06c0205056658e743352dabe9fbbc90e1eeaf49e;hb=2d6060d882069ed3e3d6302aa63ea7eb4bb155ad]
> - boost/cstdint.hpp is not required (*#define HAVE_STDINT_H*)
> Here's the changes I made to
> *thrift-0.10.0\lib\cpp\src\thrift\windows\config.h* to better support MingW
> and make it possible to use boost as header only.
> Since I don't know how to attach a patch here, I'll do it old school :)
> Before :
> {noformat}
> // use std::thread in MSVC11 (2012) or newer
> #if _MSC_VER >= 1700
> #define USE_STD_THREAD 1
> #else
> // otherwise use boost threads
> #define USE_BOOST_THREAD 1
> #endif
> // VS2010 or later has stdint.h
> #if _MSC_VER >= 1600
> #define HAVE_STDINT_H 1
> #endif
> {noformat}
> After :
> {noformat}
> // use std::thread in MSVC11 (2012) or newer
> #if defined(_MSC_VER) && (_MSC_VER >= 1700)
> #define USE_STD_THREAD 1
> #elif defined(__MINGW32__)
> #define USE_STD_THREAD 1
> #else
> // otherwise use boost threads
> #define USE_BOOST_THREAD 1
> #endif
> // VS2010 or later has stdint.h
> #if defined(_MSC_VER) && (_MSC_VER >= 1600)
> #define HAVE_STDINT_H 1
> #elif defined(__MINGW32__)
> #define HAVE_STDINT_H 1
> #endif
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4080) Unix sockets can get stuck forever
[
https://issues.apache.org/jira/browse/THRIFT-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859458#comment-15859458
]
James E. King, III commented on THRIFT-4080:
Both the C++ and Java TSocket implementations allow the receive and connect
timeout to be specified optionally. If you can do the same for python and
submit a pull request, that would be great. A setting like this should be in
control of the consuming application. Information for contributing with a
github pull request (now that you have a Jira ticket) can be found here:
https://thrift.apache.org/docs/HowToContribute
> Unix sockets can get stuck forever
> --
>
> Key: THRIFT-4080
> URL: https://issues.apache.org/jira/browse/THRIFT-4080
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Ubuntu 14.04
>Reporter: David Fankhauser
>Priority: Critical
>
> I had the problem that if the network connection is really bad the server
> sometimes does not accept more connections. "Really bad" means that a simple
> ping event sent via thrift could take 15 seconds.
> Having this issue for nearly 2 years now I could finally figure it out:
> There is no timeout when the socket receives data. After a connection is
> established and the socket object is created, the connection can drop which
> yields to the socket blocking forever.
> I added a timeout in the TSocket accept function which makes the socket throw
> a resource not available error after 30 seconds:
> def accept(self):
> client, addr = self.handle.accept()
> -- added timeout of 30.0 seconds
> client.setsockopt(socket.SOL_SOCKET, socket.SO_RCVTIMEO,
> struct.pack('LL', 30, 0))
> result = TSocket()
> result.setHandle(client)
> return result
> Gives this error:
> buff = self.handle.recv(sz)
> error: [Errno 11] Resource temporarily unavailable
> I also tried using python socket's settimeout() function which does not work.
> Only setting the receive timeout times out dropped connections.
> This bug does not appear on stable connections. However, I have 4 devices
> that are connected via WiFi and my ThreadedServer gets stuck about 4-5 times
> a day. The ThreadedServer has 5 threads, thus all 5 sockets get stuck all
> the time...
> FYI here is the strace of the stuck socket:
> [pid 2698] futex(0x7faf5d80, FUTEX_WAIT_PRIVATE, 0, NULL
> [pid 2697] read(4,
> [pid 2693] accept(7, {sa_family=AF_INET6, sin6_port=htons(39911),
> inet_pton(AF_INET6, ":::46.125.249.41", &sin6_addr), sin6_flowinfo=0,
> sin6_scope_id=0}, [28]) = 6
> [pid 2693] recvfrom(6,
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4079) [Regression] Generated perl code that returns structures from included thrift files is missing a necessary use clause
[
https://issues.apache.org/jira/browse/THRIFT-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859451#comment-15859451
]
ASF GitHub Bot commented on THRIFT-4079:
Github user asfgit closed the pull request at:
https://github.com/apache/thrift/pull/1181
> [Regression] Generated perl code that returns structures from included thrift
> files is missing a necessary use clause
> -
>
> Key: THRIFT-4079
> URL: https://issues.apache.org/jira/browse/THRIFT-4079
> Project: Thrift
> Issue Type: Bug
> Components: Perl - Compiler
>Affects Versions: 0.10.0
> Environment: Ubuntu 14.04 LTS (perl 5.18.2) with thrift 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
> Fix For: 0.11.0
>
> Attachments: THRIFT-4079-example.tgz
>
>
> I made a very simple example which I will attach, however in a nutshell if I
> define a structure in one thrift file like this:
> {{ForeignInfo.thrift:}}
> {noformat}
> namespace perl org.fiction.rpc
> struct ForeignInfo
> {
> 1: string someData
> }
> {noformat}
> Then I define a service in another namespace like this:
> {{SomeService.thrift:}}
> {noformat}
> namespace perl org.real
> include "ForeignInfo.thrift"
> service Company
> {
> ForeignInfo.ForeignInfo getForeignInfoList();
> }
> {noformat}
> Then I compile both of them, the resulting generated perl code in
> {{gen-perl/org/real/Company.pm}} has the following use clauses in it:
> {noformat}
> require 5.6.0;
> use strict;
> use warnings;
> use Thrift;
> use org::real::Types;
> {noformat}
> Later on in the file we have:
> {noformat}
> SWITCH: for($fid)
> {
> /^0$/ && do{ if ($ftype == TType::STRUCT) {
> $self->{success} = new org::fiction::rpc::ForeignInfo();
> $xfer += $self->{success}->read($input);
> } else {
> $xfer += $input->skip($ftype);
> }
> last; };
> $xfer += $input->skip($ftype);
> }
> {noformat}
> If you put a simple wrapper around this call, the client gets an exception:
> {noformat}
> Undefined subroutine &org::fiction::rpc::ForeignInfo called at
> gen-perl/org/real/Company.pm line 98
> {noformat}
> Line 98 is where {{org::fiction::rpc::ForeignInfo}} is mentioned. Without a
> use clause for the Types defined by the include it cannot be used.
> If I add this line to the generated code in Company.pm:
> {noformat}
> use org::fiction::rpc::Types;
> {noformat}
> Then everything works.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (THRIFT-4079) Generated perl code that returns structures from included thrift files is missing a necessary use clause
[
https://issues.apache.org/jira/browse/THRIFT-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-4079:
---
Summary: Generated perl code that returns structures from included thrift
files is missing a necessary use clause (was: [Regression] Generated perl code
that returns structures from included thrift files is missing a necessary use
clause)
> Generated perl code that returns structures from included thrift files is
> missing a necessary use clause
>
>
> Key: THRIFT-4079
> URL: https://issues.apache.org/jira/browse/THRIFT-4079
> Project: Thrift
> Issue Type: Bug
> Components: Perl - Compiler
>Affects Versions: 0.10.0
> Environment: Ubuntu 14.04 LTS (perl 5.18.2) with thrift 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
> Fix For: 0.11.0
>
> Attachments: THRIFT-4079-example.tgz
>
>
> I made a very simple example which I will attach, however in a nutshell if I
> define a structure in one thrift file like this:
> {{ForeignInfo.thrift:}}
> {noformat}
> namespace perl org.fiction.rpc
> struct ForeignInfo
> {
> 1: string someData
> }
> {noformat}
> Then I define a service in another namespace like this:
> {{SomeService.thrift:}}
> {noformat}
> namespace perl org.real
> include "ForeignInfo.thrift"
> service Company
> {
> ForeignInfo.ForeignInfo getForeignInfoList();
> }
> {noformat}
> Then I compile both of them, the resulting generated perl code in
> {{gen-perl/org/real/Company.pm}} has the following use clauses in it:
> {noformat}
> require 5.6.0;
> use strict;
> use warnings;
> use Thrift;
> use org::real::Types;
> {noformat}
> Later on in the file we have:
> {noformat}
> SWITCH: for($fid)
> {
> /^0$/ && do{ if ($ftype == TType::STRUCT) {
> $self->{success} = new org::fiction::rpc::ForeignInfo();
> $xfer += $self->{success}->read($input);
> } else {
> $xfer += $input->skip($ftype);
> }
> last; };
> $xfer += $input->skip($ftype);
> }
> {noformat}
> If you put a simple wrapper around this call, the client gets an exception:
> {noformat}
> Undefined subroutine &org::fiction::rpc::ForeignInfo called at
> gen-perl/org/real/Company.pm line 98
> {noformat}
> Line 98 is where {{org::fiction::rpc::ForeignInfo}} is mentioned. Without a
> use clause for the Types defined by the include it cannot be used.
> If I add this line to the generated code in Company.pm:
> {noformat}
> use org::fiction::rpc::Types;
> {noformat}
> Then everything works.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1181: THRIFT-4079 add missing use clauses for included ...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1181 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (THRIFT-4079) [Regression] Generated perl code that returns structures from included thrift files is missing a necessary use clause
[
https://issues.apache.org/jira/browse/THRIFT-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-4079.
Resolution: Fixed
Fix Version/s: 0.11.0
> [Regression] Generated perl code that returns structures from included thrift
> files is missing a necessary use clause
> -
>
> Key: THRIFT-4079
> URL: https://issues.apache.org/jira/browse/THRIFT-4079
> Project: Thrift
> Issue Type: Bug
> Components: Perl - Compiler
>Affects Versions: 0.10.0
> Environment: Ubuntu 14.04 LTS (perl 5.18.2) with thrift 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
> Fix For: 0.11.0
>
> Attachments: THRIFT-4079-example.tgz
>
>
> I made a very simple example which I will attach, however in a nutshell if I
> define a structure in one thrift file like this:
> {{ForeignInfo.thrift:}}
> {noformat}
> namespace perl org.fiction.rpc
> struct ForeignInfo
> {
> 1: string someData
> }
> {noformat}
> Then I define a service in another namespace like this:
> {{SomeService.thrift:}}
> {noformat}
> namespace perl org.real
> include "ForeignInfo.thrift"
> service Company
> {
> ForeignInfo.ForeignInfo getForeignInfoList();
> }
> {noformat}
> Then I compile both of them, the resulting generated perl code in
> {{gen-perl/org/real/Company.pm}} has the following use clauses in it:
> {noformat}
> require 5.6.0;
> use strict;
> use warnings;
> use Thrift;
> use org::real::Types;
> {noformat}
> Later on in the file we have:
> {noformat}
> SWITCH: for($fid)
> {
> /^0$/ && do{ if ($ftype == TType::STRUCT) {
> $self->{success} = new org::fiction::rpc::ForeignInfo();
> $xfer += $self->{success}->read($input);
> } else {
> $xfer += $input->skip($ftype);
> }
> last; };
> $xfer += $input->skip($ftype);
> }
> {noformat}
> If you put a simple wrapper around this call, the client gets an exception:
> {noformat}
> Undefined subroutine &org::fiction::rpc::ForeignInfo called at
> gen-perl/org/real/Company.pm line 98
> {noformat}
> Line 98 is where {{org::fiction::rpc::ForeignInfo}} is mentioned. Without a
> use clause for the Types defined by the include it cannot be used.
> If I add this line to the generated code in Company.pm:
> {noformat}
> use org::fiction::rpc::Types;
> {noformat}
> Then everything works.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1181: THRIFT-4079 add missing use clauses for included thrift ...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1181 Job 3357.7 failure appears environmental: make[3]: write error --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4079) [Regression] Generated perl code that returns structures from included thrift files is missing a necessary use clause
[
https://issues.apache.org/jira/browse/THRIFT-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859431#comment-15859431
]
ASF GitHub Bot commented on THRIFT-4079:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1181
Job 3357.7 failure appears environmental: make[3]: write error
> [Regression] Generated perl code that returns structures from included thrift
> files is missing a necessary use clause
> -
>
> Key: THRIFT-4079
> URL: https://issues.apache.org/jira/browse/THRIFT-4079
> Project: Thrift
> Issue Type: Bug
> Components: Perl - Compiler
>Affects Versions: 0.10.0
> Environment: Ubuntu 14.04 LTS (perl 5.18.2) with thrift 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
> Attachments: THRIFT-4079-example.tgz
>
>
> I made a very simple example which I will attach, however in a nutshell if I
> define a structure in one thrift file like this:
> {{ForeignInfo.thrift:}}
> {noformat}
> namespace perl org.fiction.rpc
> struct ForeignInfo
> {
> 1: string someData
> }
> {noformat}
> Then I define a service in another namespace like this:
> {{SomeService.thrift:}}
> {noformat}
> namespace perl org.real
> include "ForeignInfo.thrift"
> service Company
> {
> ForeignInfo.ForeignInfo getForeignInfoList();
> }
> {noformat}
> Then I compile both of them, the resulting generated perl code in
> {{gen-perl/org/real/Company.pm}} has the following use clauses in it:
> {noformat}
> require 5.6.0;
> use strict;
> use warnings;
> use Thrift;
> use org::real::Types;
> {noformat}
> Later on in the file we have:
> {noformat}
> SWITCH: for($fid)
> {
> /^0$/ && do{ if ($ftype == TType::STRUCT) {
> $self->{success} = new org::fiction::rpc::ForeignInfo();
> $xfer += $self->{success}->read($input);
> } else {
> $xfer += $input->skip($ftype);
> }
> last; };
> $xfer += $input->skip($ftype);
> }
> {noformat}
> If you put a simple wrapper around this call, the client gets an exception:
> {noformat}
> Undefined subroutine &org::fiction::rpc::ForeignInfo called at
> gen-perl/org/real/Company.pm line 98
> {noformat}
> Line 98 is where {{org::fiction::rpc::ForeignInfo}} is mentioned. Without a
> use clause for the Types defined by the include it cannot be used.
> If I add this line to the generated code in Company.pm:
> {noformat}
> use org::fiction::rpc::Types;
> {noformat}
> Then everything works.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (THRIFT-4080) Unix sockets can get stuck forever
[
https://issues.apache.org/jira/browse/THRIFT-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Fankhauser updated THRIFT-4080:
-
Description:
I had the problem that if the network connection is really bad the server
sometimes does not accept more connections. "Really bad" means that a simple
ping event sent via thrift could take 15 seconds.
Having this issue for nearly 2 years now I could finally figure it out:
There is no timeout when the socket receives data. After a connection is
established and the socket object is created, the connection can drop which
yields to the socket blocking forever.
I added a timeout in the TSocket accept function which makes the socket throw a
resource not available error after 30 seconds:
def accept(self):
client, addr = self.handle.accept()
-- added timeout of 30.0 seconds
client.setsockopt(socket.SOL_SOCKET, socket.SO_RCVTIMEO,
struct.pack('LL', 30, 0))
result = TSocket()
result.setHandle(client)
return result
Gives this error:
buff = self.handle.recv(sz)
error: [Errno 11] Resource temporarily unavailable
I also tried using python socket's settimeout() function which does not work.
Only setting the receive timeout times out dropped connections.
This bug does not appear on stable connections. However, I have 4 devices that
are connected via WiFi and my ThreadedServer gets stuck about 4-5 times a day.
The ThreadedServer has 5 threads, thus all 5 sockets get stuck all the time...
FYI here is the strace of the stuck socket:
[pid 2698] futex(0x7faf5d80, FUTEX_WAIT_PRIVATE, 0, NULL
[pid 2697] read(4,
[pid 2693] accept(7, {sa_family=AF_INET6, sin6_port=htons(39911),
inet_pton(AF_INET6, ":::46.125.249.41", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, [28]) = 6
[pid 2693] recvfrom(6,
was:
I had the problem that if the network connection is really bad the server
sometimes does not accept more connections. "Really bad" means that a simple
ping event sent via thrift could take 15 seconds.
Having this issue for nearly 2 years now I could finally figure it out:
There is no timeout when the socket receives data. After a connection is
established and the socket object is created, the connection can drop which
yields to the socket blocking forever.
I added a timeout in the TSocket accept function which makes the socket throw a
resource not available error after 30 seconds:
def accept(self):
client, addr = self.handle.accept()
# added timeout of 30.0 seconds
client.setsockopt(socket.SOL_SOCKET, socket.SO_RCVTIMEO,
struct.pack('LL', 30, 0))
result = TSocket()
result.setHandle(client)
return result
Gives this error:
buff = self.handle.recv(sz)
error: [Errno 11] Resource temporarily unavailable
I also tried using python socket's settimeout() function which does not work.
Only setting the receive timeout times out dropped connections.
This bug does not appear on stable connections. However, I have 4 devices that
are connected via WiFi and my ThreadedServer gets stuck about 4-5 times a day.
The ThreadedServer has 5 threads, thus all 5 sockets get stuck all the time...
FYI here is the strace of the stuck socket:
[pid 2698] futex(0x7faf5d80, FUTEX_WAIT_PRIVATE, 0, NULL
[pid 2697] read(4,
[pid 2693] accept(7, {sa_family=AF_INET6, sin6_port=htons(39911),
inet_pton(AF_INET6, ":::46.125.249.41", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, [28]) = 6
[pid 2693] recvfrom(6,
> Unix sockets can get stuck forever
> --
>
> Key: THRIFT-4080
> URL: https://issues.apache.org/jira/browse/THRIFT-4080
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Ubuntu 14.04
>Reporter: David Fankhauser
>Priority: Critical
>
> I had the problem that if the network connection is really bad the server
> sometimes does not accept more connections. "Really bad" means that a simple
> ping event sent via thrift could take 15 seconds.
> Having this issue for nearly 2 years now I could finally figure it out:
> There is no timeout when the socket receives data. After a connection is
> established and the socket object is created, the connection can drop which
> yields to the socket blocking forever.
> I added a timeout in the TSocket accept function which makes the socket throw
> a resource not available error after 30 seconds:
> def accept(self):
> client, addr = self.handle.accept()
> -- added timeout of 30.0 seconds
> client.setsockopt(socket.SOL_SOCKET, socket.SO_RCVTIMEO,
> struct.pack('LL', 30, 0))
> result = TSocket()
> result.setHandle(client)
> return result
> Gives this error:
> buff = self.handle.recv(sz)
> error: [Errno 11] Res
[jira] [Created] (THRIFT-4080) Unix sockets can get stuck forever
David Fankhauser created THRIFT-4080:
Summary: Unix sockets can get stuck forever
Key: THRIFT-4080
URL: https://issues.apache.org/jira/browse/THRIFT-4080
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.10.0
Environment: Ubuntu 14.04
Reporter: David Fankhauser
Priority: Critical
I had the problem that if the network connection is really bad the server
sometimes does not accept more connections. "Really bad" means that a simple
ping event sent via thrift could take 15 seconds.
Having this issue for nearly 2 years now I could finally figure it out:
There is no timeout when the socket receives data. After a connection is
established and the socket object is created, the connection can drop which
yields to the socket blocking forever.
I added a timeout in the TSocket accept function which makes the socket throw a
resource not available error after 30 seconds:
def accept(self):
client, addr = self.handle.accept()
# added timeout of 30.0 seconds
client.setsockopt(socket.SOL_SOCKET, socket.SO_RCVTIMEO,
struct.pack('LL', 30, 0))
result = TSocket()
result.setHandle(client)
return result
Gives this error:
buff = self.handle.recv(sz)
error: [Errno 11] Resource temporarily unavailable
I also tried using python socket's settimeout() function which does not work.
Only setting the receive timeout times out dropped connections.
This bug does not appear on stable connections. However, I have 4 devices that
are connected via WiFi and my ThreadedServer gets stuck about 4-5 times a day.
The ThreadedServer has 5 threads, thus all 5 sockets get stuck all the time...
FYI here is the strace of the stuck socket:
[pid 2698] futex(0x7faf5d80, FUTEX_WAIT_PRIVATE, 0, NULL
[pid 2697] read(4,
[pid 2693] accept(7, {sa_family=AF_INET6, sin6_port=htons(39911),
inet_pton(AF_INET6, ":::46.125.249.41", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, [28]) = 6
[pid 2693] recvfrom(6,
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
