[jira] [Commented] (THRIFT-4037) [CMake] Use a single build system for thrift to make development easier
[ https://issues.apache.org/jira/browse/THRIFT-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17624028#comment-17624028 ] James E. King III commented on THRIFT-4037: --- I would say you could do this as long as it supports every language. If cmake does not have release parity with autotools, should put effort into fixing that first and making sure autotools still builds in GHA. - Jim > [CMake] Use a single build system for thrift to make development easier > --- > > Key: THRIFT-4037 > URL: https://issues.apache.org/jira/browse/THRIFT-4037 > Project: Thrift > Issue Type: Wish > Components: Build Process >Affects Versions: 0.10.0 > Environment: All >Reporter: James E. King III >Assignee: James E. King III >Priority: Critical > Labels: cmake > Time Spent: 20m > Remaining Estimate: 0h > > h1. Background > The thrift project currently carries two build systems. The original build > system is based on autoconf and is used to build a complete deliverable > including extensive cross-language testing. > The other build system was introduced a few years ago, with roots tracing > back to THRIFT-797. CMake allows thrift to build natively on multiple > platforms - unix and windows. Autoconf is no longer under active development > with the last release in 2012, and it does not allow for native windows > builds using native tools that are used by a majority of consumers. > Maintaining two build systems for a project incurs a lot of overhead. Every > change that touches the build system needs to be done twice, in two > completely different ways. We need twice as many CI jobs to verify that all > of the builds are working, whereas with a single cmake build environment we > could likely use a single CI build job per platform that does everything > using the docker image on linux and appveyor on windows. > h1. Proposal > We should officially deprecate autoconf in favor of cmake, and continue (more > aggressively) the effort to make the cmake build environment as functional as > the autoconf build environment. During this transition, folks will be > required to make changes to both build systems (which are proven out mostly > through the Travis CI build jobs; only CMake is used on AppVeyor). > h1. Acceptance Criteria > # All existing platforms, targets, and tests are converted to use cmake > ## Including cross-compilation > # All CI builds are converted to use cmake > # autoconf build environment is removed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5546) Automate package release to pypi
James E. King III created THRIFT-5546: - Summary: Automate package release to pypi Key: THRIFT-5546 URL: https://issues.apache.org/jira/browse/THRIFT-5546 Project: Thrift Issue Type: Improvement Components: Build Process Reporter: James E. King III Assignee: James E. King III Add a GitHub Actions workflow that triggers on prereleased and released action types and automates getting published packages up to pypi and test pypi. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (THRIFT-4802) Automatic library deployment on online CDN/Repository services
[
https://issues.apache.org/jira/browse/THRIFT-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17420299#comment-17420299
]
James E. King III commented on THRIFT-4802:
---
Fast forward a couple years, this would likely be tied to publishing a release
on GitHub using GitHub Actions. I am going to try to move the CI services
there to restore build quality checks.
> Automatic library deployment on online CDN/Repository services
> --
>
> Key: THRIFT-4802
> URL: https://issues.apache.org/jira/browse/THRIFT-4802
> Project: Thrift
> Issue Type: Improvement
> Components: Deployment
>Affects Versions: 0.12.0
>Reporter: Thibault Piana
>Priority: Major
> Labels: cdn, deploy,deployment, library
> Attachments: Workflow.png
>
>
> Hello everyone,
> This thread follows some other threads dealing with concerns about online
> libraries (THRIFT-4688, THRIFT-4687), as well as emails being sent to the
> user mailing list about the Docker container on DockerHub.
> If I understand the situation correctly, at the moment, with each new version
> of the software, you must prepare and update each library on each website
> independently.
> In addition, each of those libraries is managed by different people, with
> whom contact is not always easy.
> Also, I would like to propose here a system that would offer the following
> advantages:
> - No more worrying about who is maintaining each platform/CDN/Repositories...
> - No more manual uploading on each platform at each release
> - Allow anyone to develop an extension to put a Thrift package online on a
> particular site (For example, a version for Yocto as I requested in a recent
> email), and be sure this package will be updated at each new release.
> I will try to explain my idea in the following.
> h2. Vocabulary
> * *CDN :* Content delivery network
> * *Manager :* An algorithm to upload content to a CDN/online repository
> * *Orchestrator :* The algorithm that orchestrates the execution of
> managers, provides credentials, manages manager feedback, and generates the
> final report
> * *Package* : The library/component we want to upload on the CDN
> In the following, all online resources providers/repositories (like Pypi,
> NPMJs, DockerHub ...) will be called "CDN"
> h2. General principle
> The idea would be to develop a single interface for module deployment, with
> an orchestrator to automatically configure and perform these deployments.
> The organization would be like this :
> * A Keepass database will store all passwords/identifiers required for each
> platform (NPMJS, Pypi, DockerHub, ...) :
> ** Each module will specify what credentials it needs from this database.
> ** This database could be committed directly on the repo, to be sure each
> committers have the most recent version.
> ** The master password of this database will only be known by committers (or
> project chair).
> I think KeePass is quite perfect for this, Keepass databases are very
> lightweight, highly secure, and almost impossible to brute-force.
> * For each CDN, a manager is in charge of bundling (create the package to
> upload from Thrift current release sources), uploading and checking the
> package on the CDN :
> ** First, the orchestrator load required IDs from the KeePass database
> ** The orchestrator creates a temporary directory where the manager will be
> able to bundle everything it needs.
> *** The manager receives credentials, a path to a temporary directory and a
> path to Thrift sources
> *** The manager checks online if the current version of the package already
> exists online. If not, it will upload it
> *** The manager prepares the bundled package, upload it and check if
> everything went well.
> All these steps could be executed in a dedicated Docker/Vagrant environment
> containing all needed libraries to bundle the package (So that the
> person/commiter executing the script does not have to download 500
> dependencies).
> The algorithm diagram is provided in attached (it's a draft)
> The directory structure of this solution could be something like this (I
> chose Python arbitrarily here):
> {code:java}
> root
> └── deployment/
> ├── access.kdbx
> ├── deploy.py
> ├── libraries # Some managers
> │ ├── javascript
> │ │ ├── npm.py
> │ │ ├── bower.py
> │ │ └── a_random_cdn.py
> │ ├── nodejs
> │ │ └── npm.py
> │ └── python
> │ └── pypi.js
> │ └── ...
> └── miscellaneous # Some other managers
> ├── docker
> │ └── docker.py
> └── yocto
> └── yocto.py
> └── ...{code}
> I am not a regular contributor on open source projects. So I don't know if
> I'm making my proposal in the best way.
[jira] [Resolved] (THRIFT-5055) Fix build-cpan-dist.sh to create a CPAN distribution correctly
[
https://issues.apache.org/jira/browse/THRIFT-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III resolved THRIFT-5055.
---
Fix Version/s: 0.16.0
Resolution: Fixed
Removed --hard-dereference from the script.
> Fix build-cpan-dist.sh to create a CPAN distribution correctly
> --
>
> Key: THRIFT-5055
> URL: https://issues.apache.org/jira/browse/THRIFT-5055
> Project: Thrift
> Issue Type: Bug
> Components: Perl - Library
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Major
> Fix For: 0.16.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I tried to run build-cpan-dist.sh to create a CPAN distribution, but it
> failed as follows:
> {code}
> thrift$ dockerrun thrift/thrift-build:ubuntu-xenial
> root@c933c00aefca:/thrift/src# cd lib/perl
> root@c933c00aefca:/thrift/src/lib/perl# ./build-cpan-dist.sh
> (snip)
> + tar cvzf --hard-dereference Thrift-0.14.0.tar.gz Thrift-0.14.0
> tar: Thrift-0.14.0.tar.gz: Cannot stat: No such file or directory
> (snip)
> tar: Exiting with failure status due to previous errors
> root@c933c00aefca:/thrift/src/lib/perl# echo $?
> 2
> {code}
> It seems that the {{--hard-dereference}} option is considered as a filename.
> Moving it after {{Thrift-0.14.0.tar.gz}} resolved the problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (THRIFT-4911) Push wheel to PyPi
[ https://issues.apache.org/jira/browse/THRIFT-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4911. - > Push wheel to PyPi > -- > > Key: THRIFT-4911 > URL: https://issues.apache.org/jira/browse/THRIFT-4911 > Project: Thrift > Issue Type: New Feature > Components: Python - Library > Environment: pypi >Reporter: Nathaniel Waisbrot >Assignee: James E. King III >Priority: Major > Labels: packaging > > [Wheels|https://pythonwheels.com/] are Python's preferred method of packaging > libraries in binary form. It would be great if Thrift was published in > wheel-form as well as source to PyPi. > I understand this is blocked by https://github.com/pypa/warehouse/issues/5346 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (THRIFT-4687) Add thrift 0.12.0 to pypi and/or enable more maintainers
[ https://issues.apache.org/jira/browse/THRIFT-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4687. - Fix Version/s: 0.12.0 Assignee: James E. King III Resolution: Fixed Uploaded a while ago. > Add thrift 0.12.0 to pypi and/or enable more maintainers > > > Key: THRIFT-4687 > URL: https://issues.apache.org/jira/browse/THRIFT-4687 > Project: Thrift > Issue Type: Request > Components: Python - Library >Affects Versions: 0.12.0 > Environment: pypi >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > Fix For: 0.12.0 > > > [~jfarrell] please either update pypi for the latest thrift 0.12.0 release or > find a way for the committer team to join an organizatio on pypi so any of us > making a release can do it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (THRIFT-4991) Please release python library thrift 0.13.0 to PyPI
[
https://issues.apache.org/jira/browse/THRIFT-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III closed THRIFT-4991.
-
Fix Version/s: 0.13.0
Assignee: James E. King III
Resolution: Fixed
Uploaded a while ago.
> Please release python library thrift 0.13.0 to PyPI
> ---
>
> Key: THRIFT-4991
> URL: https://issues.apache.org/jira/browse/THRIFT-4991
> Project: Thrift
> Issue Type: Request
> Components: Python - Library
>Affects Versions: 0.13.0
>Reporter: Yan QiDong
>Assignee: James E. King III
>Priority: Major
> Fix For: 0.13.0
>
>
> My current work depends on the feature in {{0.13.0}}, but it is not released.
> The tag {{0.13.0}} is already created in GitHub. I hope the python library
> could be released soon.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (THRIFT-4911) Push wheel to PyPi
[ https://issues.apache.org/jira/browse/THRIFT-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4911. --- Assignee: James E. King III Resolution: Won't Fix I'm not certain we're going to be distributing binary wheels at all. It is exceedingly hard to do so. We put source distributions up on pypi. > Push wheel to PyPi > -- > > Key: THRIFT-4911 > URL: https://issues.apache.org/jira/browse/THRIFT-4911 > Project: Thrift > Issue Type: New Feature > Components: Python - Library > Environment: pypi >Reporter: Nathaniel Waisbrot >Assignee: James E. King III >Priority: Major > Labels: packaging > > [Wheels|https://pythonwheels.com/] are Python's preferred method of packaging > libraries in binary form. It would be great if Thrift was published in > wheel-form as well as source to PyPi. > I understand this is blocked by https://github.com/pypa/warehouse/issues/5346 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (THRIFT-4491) Haskell library 0.11 not uploaded to hackage
[ https://issues.apache.org/jira/browse/THRIFT-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4491. - Resolution: Done > Haskell library 0.11 not uploaded to hackage > > > Key: THRIFT-4491 > URL: https://issues.apache.org/jira/browse/THRIFT-4491 > Project: Thrift > Issue Type: Task > Components: Haskell - Library >Affects Versions: 0.10.0 >Reporter: Heli Wang >Assignee: James E. King III >Priority: Major > > Our project uses the thrift package uploaded to hackage > ([https://hackage.haskell.org/package/thrift),] but the latest available > version, 0.10.0, doesn't include a fix we need > ([https://github.com/apache/thrift/pull/1145)]. It looks like this is > included with 0.11.0, can that version be uploaded to hackage? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (THRIFT-4872) Recursion on TServerSocket::listen()
[ https://issues.apache.org/jira/browse/THRIFT-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4872. - > Recursion on TServerSocket::listen() > > > Key: THRIFT-4872 > URL: https://issues.apache.org/jira/browse/THRIFT-4872 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.3 >Reporter: Daniel Haensse >Assignee: James E. King III >Priority: Major > Attachments: thrift-0.12.0_TserverSocket_listen_recursion.patch > > > In a Windows based environment with 500 PC running dozends of thrift > connections per node, we suffered problem with recursion on > TServerSocket::listen(). Unfortunately we can't provide setup to reproduce > the problem. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (THRIFT-4872) Recursion on TServerSocket::listen()
[ https://issues.apache.org/jira/browse/THRIFT-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4872. --- Resolution: Won't Fix No reply for about 6 months; resolving won't fix. > Recursion on TServerSocket::listen() > > > Key: THRIFT-4872 > URL: https://issues.apache.org/jira/browse/THRIFT-4872 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.3 >Reporter: Daniel Haensse >Assignee: James E. King III >Priority: Major > Attachments: thrift-0.12.0_TserverSocket_listen_recursion.patch > > > In a Windows based environment with 500 PC running dozends of thrift > connections per node, we suffered problem with recursion on > TServerSocket::listen(). Unfortunately we can't provide setup to reproduce > the problem. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (THRIFT-4904) Python TSocket read() and write() allow low level exceptions to escape
[ https://issues.apache.org/jira/browse/THRIFT-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III reassigned THRIFT-4904: - Assignee: James E. King III > Python TSocket read() and write() allow low level exceptions to escape > -- > > Key: THRIFT-4904 > URL: https://issues.apache.org/jira/browse/THRIFT-4904 > Project: Thrift > Issue Type: Bug > Components: Python - Library >Affects Versions: 0.12.0 >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > > The calls to socket send() and recv() inside write() and read() were allowing > exceptions to escape: > - OSError > - socket.error > - ssl.Error > These need to be captured and translated to an appropriate > TTransportException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (THRIFT-4904) Python TSocket read() and write() allow low level exceptions to escape
[ https://issues.apache.org/jira/browse/THRIFT-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III reassigned THRIFT-4904: - Assignee: (was: James E. King III) > Python TSocket read() and write() allow low level exceptions to escape > -- > > Key: THRIFT-4904 > URL: https://issues.apache.org/jira/browse/THRIFT-4904 > Project: Thrift > Issue Type: Bug > Components: Python - Library >Affects Versions: 0.12.0 >Reporter: James E. King III >Priority: Major > > The calls to socket send() and recv() inside write() and read() were allowing > exceptions to escape: > - OSError > - socket.error > - ssl.Error > These need to be captured and translated to an appropriate > TTransportException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (THRIFT-4904) Python TSocket read() and write() allow low level exceptions to escape
[ https://issues.apache.org/jira/browse/THRIFT-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III reassigned THRIFT-4904: - Assignee: (was: James E. King III) > Python TSocket read() and write() allow low level exceptions to escape > -- > > Key: THRIFT-4904 > URL: https://issues.apache.org/jira/browse/THRIFT-4904 > Project: Thrift > Issue Type: Bug > Components: Python - Library >Affects Versions: 0.12.0 >Reporter: James E. King III >Priority: Major > > The calls to socket send() and recv() inside write() and read() were allowing > exceptions to escape: > - OSError > - socket.error > - ssl.Error > These need to be captured and translated to an appropriate > TTransportException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (THRIFT-4750) Publish 0.12.0 as3 module to maven central
[ https://issues.apache.org/jira/browse/THRIFT-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4750. - > Publish 0.12.0 as3 module to maven central > -- > > Key: THRIFT-4750 > URL: https://issues.apache.org/jira/browse/THRIFT-4750 > Project: Thrift > Issue Type: Task > Components: AS3 - Library >Affects Versions: 0.12.0 >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > Fix For: 0.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The ActionScript module can be built in CI (compiled) and it can be published > with some tooling changes (ant -> gradle) to go to Maven Central. The latest > version on Maven Central is 0.9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (THRIFT-4998) Version 0.13.0 is not available on Maven Central
[ https://issues.apache.org/jira/browse/THRIFT-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4998. - > Version 0.13.0 is not available on Maven Central > > > Key: THRIFT-4998 > URL: https://issues.apache.org/jira/browse/THRIFT-4998 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.13.0 >Reporter: Georg Schmidt-Dumont >Assignee: James E. King III >Priority: Critical > Fix For: 0.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When upgrading to version 0.13.0 this morning I found that this version is > not available on Maven Central. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (THRIFT-4998) Version 0.13.0 is not available on Maven Central
[ https://issues.apache.org/jira/browse/THRIFT-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4998: -- Fix Version/s: (was: 0.14.0) 0.13.0 > Version 0.13.0 is not available on Maven Central > > > Key: THRIFT-4998 > URL: https://issues.apache.org/jira/browse/THRIFT-4998 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.13.0 >Reporter: Georg Schmidt-Dumont >Assignee: James E. King III >Priority: Critical > Fix For: 0.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When upgrading to version 0.13.0 this morning I found that this version is > not available on Maven Central. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (THRIFT-4687) Add thrift 0.12.0 to pypi and/or enable more maintainers
[ https://issues.apache.org/jira/browse/THRIFT-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976168#comment-16976168 ] James E. King III commented on THRIFT-4687: --- Looks like I was granted owner privilege on it finally! [~jensg] send me your pypi username so I can add you as well, that way we'll have at least 2 owners in there. I still cannot modify any Jira tickets so I cannot close this. > Add thrift 0.12.0 to pypi and/or enable more maintainers > > > Key: THRIFT-4687 > URL: https://issues.apache.org/jira/browse/THRIFT-4687 > Project: Thrift > Issue Type: Request > Components: Python - Library >Affects Versions: 0.12.0 > Environment: pypi >Reporter: James E. King III >Assignee: Jake Farrell >Priority: Critical > > [~jfarrell] please either update pypi for the latest thrift 0.12.0 release or > find a way for the committer team to join an organizatio on pypi so any of us > making a release can do it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (THRIFT-4998) Version 0.13.0 is not available on Maven Central
[ https://issues.apache.org/jira/browse/THRIFT-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976152#comment-16976152 ] James E. King III edited comment on THRIFT-4998 at 11/17/19 9:13 PM: - Looks like things have changed with Maven. I can't find the staging vs production management interface I used to use. I've filed a ticket to ask what to do and get set up in what looks like the replacement management system for this stuff ([https://oss.sonatype.org/]) NOTE the correct location is: [https://repository.apache.org/] was (Author: jking): Looks like things have changed with Maven. I can't find the staging vs production management interface I used to use. I've filed a ticket to ask what to do and get set up in what looks like the replacement management system for this stuff ([https://oss.sonatype.org/]) > Version 0.13.0 is not available on Maven Central > > > Key: THRIFT-4998 > URL: https://issues.apache.org/jira/browse/THRIFT-4998 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.13.0 >Reporter: Georg Schmidt-Dumont >Assignee: James E. King III >Priority: Critical > > When upgrading to version 0.13.0 this morning I found that this version is > not available on Maven Central. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (THRIFT-4998) Version 0.13.0 is not available on Maven Central
[ https://issues.apache.org/jira/browse/THRIFT-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976160#comment-16976160 ] James E. King III commented on THRIFT-4998: --- Okay I think I got it up there on Maven successfully. > Version 0.13.0 is not available on Maven Central > > > Key: THRIFT-4998 > URL: https://issues.apache.org/jira/browse/THRIFT-4998 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.13.0 >Reporter: Georg Schmidt-Dumont >Assignee: James E. King III >Priority: Critical > > When upgrading to version 0.13.0 this morning I found that this version is > not available on Maven Central. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (THRIFT-4998) Version 0.13.0 is not available on Maven Central
[ https://issues.apache.org/jira/browse/THRIFT-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976152#comment-16976152 ] James E. King III commented on THRIFT-4998: --- Looks like things have changed with Maven. I can't find the staging vs production management interface I used to use. I've filed a ticket to ask what to do and get set up in what looks like the replacement management system for this stuff ([https://oss.sonatype.org/]) > Version 0.13.0 is not available on Maven Central > > > Key: THRIFT-4998 > URL: https://issues.apache.org/jira/browse/THRIFT-4998 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.13.0 >Reporter: Georg Schmidt-Dumont >Assignee: James E. King III >Priority: Critical > > When upgrading to version 0.13.0 this morning I found that this version is > not available on Maven Central. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (THRIFT-4998) Version 0.13.0 is not available on Maven Central
[ https://issues.apache.org/jira/browse/THRIFT-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975987#comment-16975987 ] James E. King III commented on THRIFT-4998: --- [~jensg] for some reason I cannot modify the state of this Jira item even though it is assigned to me? > Version 0.13.0 is not available on Maven Central > > > Key: THRIFT-4998 > URL: https://issues.apache.org/jira/browse/THRIFT-4998 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.13.0 >Reporter: Georg Schmidt-Dumont >Assignee: James E. King III >Priority: Critical > > When upgrading to version 0.13.0 this morning I found that this version is > not available on Maven Central. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (THRIFT-4677) UnicodeDecodeError in Python3
[
https://issues.apache.org/jira/browse/THRIFT-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904618#comment-16904618
]
James E. King III commented on THRIFT-4677:
---
Thrift only handles strings as UTF8 internally. I think you will need to
convert your string to UTF8 binary before you attempt to transmit it by Thrift.
For example I used the online tool [https://mothereff.in/utf-8] and pasted in
your string of '任务尚未运行。' and I got:
{{\xE4\xBB\xBB\xE5\x8A\xA1\xE5\xB0\x9A\xE6\x9C\xAA\xE8\xBF\x90\xE8\xA1\x8C\xE3\x80\x82}}
But it looks like the strings are not stored in UTF8 in your database, so
between reading them out and putting them in to a thrift struct for
transmission, convert them to UTF8.
> UnicodeDecodeError in Python3
> -
>
> Key: THRIFT-4677
> URL: https://issues.apache.org/jira/browse/THRIFT-4677
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
> Environment: Operating System: Windows 10 Pro (Simplified Chinese)
> Python Interpreter: Python 3.6.6
> {{osquery}} Version: 3.3.0
> {{osquery-python}} Version: 3.0.5
>
>Reporter: Jarry Shaw
>Priority: Major
> Attachments: compat.py, osquery_all_mp.py
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> This is an issue occurred when using
> [osquery-python|https://github.com/osquery/osquery-python] (Python binding of
> [osquery|https://osquery.io/] by Facebook).
> When querying, {{UnicodeDecodeError}} raised with error message: "{{'utf-8'
> codec can't decode byte 0xc3 in position 0: invalid continuation byte}}" from
> {{thrift.compat.binary_to_str}}, which is because the encoding of {{bin_val}}
> parameter should be "{{gbk}}".
> Possible approaches are:
> * add a parameter for user to determine encodings
> * get the system encoding through {{locale.getpreferredencoding()}}
> * call {{bin_val.decode}} with {{errors='replace'}} or {{errors='ignore'}}
> parameter
> * introduce {{chardet}} to try and resolve encoding problems
> The attachment is my hack solution to this issue (through not perfect).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (THRIFT-4116) Thrift de-capitalizes the name of IsSet property in Cocoa
[ https://issues.apache.org/jira/browse/THRIFT-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4116. - > Thrift de-capitalizes the name of IsSet property in Cocoa > - > > Key: THRIFT-4116 > URL: https://issues.apache.org/jira/browse/THRIFT-4116 > Project: Thrift > Issue Type: Bug > Components: Cocoa - Compiler >Affects Versions: 0.10.0 >Reporter: Aleksandr Skobelev >Assignee: James E. King III >Priority: Critical > Fix For: 0.13.0 > > Attachments: Thrift-4116-demo.zip, thrift-0.10.0.patch > > > If a struct contains fields with capitalized names, Thrift compiler for Cocoa > wrongly generates IsSet Objective-C property started with lowercase > character. In the same time it keeps the uppercase latter in the name of the > corresponding instance variable. This breaks the compilation of the > generated code. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (THRIFT-4802) Automatic library deployment on online CDN/Repository services
[
https://issues.apache.org/jira/browse/THRIFT-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4802:
--
Priority: Major (was: Critical)
> Automatic library deployment on online CDN/Repository services
> --
>
> Key: THRIFT-4802
> URL: https://issues.apache.org/jira/browse/THRIFT-4802
> Project: Thrift
> Issue Type: Improvement
> Components: Deployment
>Affects Versions: 0.12.0
>Reporter: Thibault Piana
>Priority: Major
> Labels: cdn, deploy,deployment, library
> Attachments: Workflow.png
>
>
> Hello everyone,
> This thread follows some other threads dealing with concerns about online
> libraries (THRIFT-4688, THRIFT-4687), as well as emails being sent to the
> user mailing list about the Docker container on DockerHub.
> If I understand the situation correctly, at the moment, with each new version
> of the software, you must prepare and update each library on each website
> independently.
> In addition, each of those libraries is managed by different people, with
> whom contact is not always easy.
> Also, I would like to propose here a system that would offer the following
> advantages:
> - No more worrying about who is maintaining each platform/CDN/Repositories...
> - No more manual uploading on each platform at each release
> - Allow anyone to develop an extension to put a Thrift package online on a
> particular site (For example, a version for Yocto as I requested in a recent
> email), and be sure this package will be updated at each new release.
> I will try to explain my idea in the following.
> h2. Vocabulary
> * *CDN :* Content delivery network
> * *Manager :* An algorithm to upload content to a CDN/online repository
> * *Orchestrator :* The algorithm that orchestrates the execution of
> managers, provides credentials, manages manager feedback, and generates the
> final report
> * *Package* : The library/component we want to upload on the CDN
> In the following, all online resources providers/repositories (like Pypi,
> NPMJs, DockerHub ...) will be called "CDN"
> h2. General principle
> The idea would be to develop a single interface for module deployment, with
> an orchestrator to automatically configure and perform these deployments.
> The organization would be like this :
> * A Keepass database will store all passwords/identifiers required for each
> platform (NPMJS, Pypi, DockerHub, ...) :
> ** Each module will specify what credentials it needs from this database.
> ** This database could be committed directly on the repo, to be sure each
> committers have the most recent version.
> ** The master password of this database will only be known by committers (or
> project chair).
> I think KeePass is quite perfect for this, Keepass databases are very
> lightweight, highly secure, and almost impossible to brute-force.
> * For each CDN, a manager is in charge of bundling (create the package to
> upload from Thrift current release sources), uploading and checking the
> package on the CDN :
> ** First, the orchestrator load required IDs from the KeePass database
> ** The orchestrator creates a temporary directory where the manager will be
> able to bundle everything it needs.
> *** The manager receives credentials, a path to a temporary directory and a
> path to Thrift sources
> *** The manager checks online if the current version of the package already
> exists online. If not, it will upload it
> *** The manager prepares the bundled package, upload it and check if
> everything went well.
> All these steps could be executed in a dedicated Docker/Vagrant environment
> containing all needed libraries to bundle the package (So that the
> person/commiter executing the script does not have to download 500
> dependencies).
> The algorithm diagram is provided in attached (it's a draft)
> The directory structure of this solution could be something like this (I
> chose Python arbitrarily here):
> {code:java}
> root
> └── deployment/
> ├── access.kdbx
> ├── deploy.py
> ├── libraries # Some managers
> │ ├── javascript
> │ │ ├── npm.py
> │ │ ├── bower.py
> │ │ └── a_random_cdn.py
> │ ├── nodejs
> │ │ └── npm.py
> │ └── python
> │ └── pypi.js
> │ └── ...
> └── miscellaneous # Some other managers
> ├── docker
> │ └── docker.py
> └── yocto
> └── yocto.py
> └── ...{code}
> I am not a regular contributor on open source projects. So I don't know if
> I'm making my proposal in the best way. But I really like this project and I
> would like to help improve it
> I had this idea based on what had been put in place in a project I was
> recently leading. It is not perfect but does the job
[jira] [Updated] (THRIFT-3108) Defaulted struct parameters on a service generates invalid Haskell.
[
https://issues.apache.org/jira/browse/THRIFT-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-3108:
--
Priority: Major (was: Critical)
> Defaulted struct parameters on a service generates invalid Haskell.
> ---
>
> Key: THRIFT-3108
> URL: https://issues.apache.org/jira/browse/THRIFT-3108
> Project: Thrift
> Issue Type: Bug
> Components: Haskell - Compiler
> Environment: GHC 7.6.3
> GHC 7.8.4
>Reporter: Sean Parsons
>Priority: Major
>
> If we have a service definition that looks something like:
> {code:none}
> struct ServiceRequest {
> 1: optional bool shouldWork;
> }
> service MyService{
> void myService(1:ServiceRequest request = {});
> }
> {code}
> The code generation relating to the service call includes an invocation like
> this:
> {code:none}
> ... = default_ServiceRequest{}
> {code}
> Which is invalid as empty record updates are not allowed.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-4852) The recv function of void functions doesn't throw custom exceptions
[
https://issues.apache.org/jira/browse/THRIFT-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4852:
--
Priority: Major (was: Critical)
> The recv function of void functions doesn't throw custom exceptions
> ---
>
> Key: THRIFT-4852
> URL: https://issues.apache.org/jira/browse/THRIFT-4852
> Project: Thrift
> Issue Type: Bug
> Components: Lua - Compiler
>Affects Versions: 0.12.0
>Reporter: Yu Gan
>Priority: Major
>
> In thrift/compiler/cpp/src/thrift/generate/t_lua_generator.cc:621, it only
> throws custom exceptions when the function is not void. However, void
> function could still return exceptions to the caller service, as long as the
> function is not oneway.
> {code}
> // Return the result if it's not a void function
> if (!(*f_iter)->get_returntype()->is_void()) {
> out << indent() << "if result.success ~= nil then" << endl <<
> indent() << " return result.success"
> << endl;
> // Throw custom exceptions
> const std::vector& xf =
> (*f_iter)->get_xceptions()->get_members();
> vector::const_iterator x_iter;
> for (x_iter = xf.begin(); x_iter != xf.end(); ++x_iter) {
> out << indent() << "elseif result." << (*x_iter)->get_name() << "
> then" << endl
> << indent() << " error(result." << (*x_iter)->get_name() <<
> ")" << endl;
> }
> out << indent() << "end" << endl << indent()
> << "error(TApplicationException:new{errorCode = "
> << "TApplicationException.MISSING_RESULT})" << endl;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-3990) [node.js] Exception swallowed by deserialization function
[ https://issues.apache.org/jira/browse/THRIFT-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-3990: -- Priority: Major (was: Critical) > [node.js] Exception swallowed by deserialization function > - > > Key: THRIFT-3990 > URL: https://issues.apache.org/jira/browse/THRIFT-3990 > Project: Thrift > Issue Type: Bug > Components: Node.js - Compiler >Affects Versions: 0.9.3 >Reporter: Dan >Priority: Major > > As a client with generated node.js idls, when I receive data from a server > that isn't what the idl expects, then an exception is thrown that is > swallowed by the connection (it doesn't even get emitted and handled by the > connection object). This causes the client's process to crash and clients > upstream to hang as a result. What is desired is to catch this exception and > return it in the callback as an error so that the client can handle the > exception. Examples to come. > Example stacktrace: > ``` > Error: Invalid type: -128 > at TBinaryProtocol.skip > (.../node_modules/thrift/lib/nodejs/lib/thrift/binary_protocol.js:354:13) > at Object.Bill.read > (.../thrift/fn_data_access/gen-nodejs/bills_types.js:1682:15) > at Object.FetchBillsResult.read > (.../thrift/fn_data_access/gen-nodejs/bills_types.js:2024:18) > at Object.BillsDataAccess_fetchBills_result.read > (.../thrift/fn_data_access/gen-nodejs/BillsDataAccess.js:534:22) > at Object.BillsDataAccessClient.recv_fetchBills > (.../thrift/fn_data_access/gen-nodejs/BillsDataAccess.js:714:10) > at decodeCallback > (.../node_modules/thrift/lib/nodejs/lib/thrift/http_connection.js:146:41) > at > .../node_modules/thrift/lib/nodejs/lib/thrift/buffered_transport.js:48:5 > at IncomingMessage. > (.../node_modules/thrift/lib/nodejs/lib/thrift/http_connection.js:198:46) > at emitNone (events.js:91:20) > at IncomingMessage.emit (events.js:185:7) > at endReadableNT (_stream_readable.js:974:12) > at _combinedTickCallback (internal/process/next_tick.js:74:11) > at process._tickDomainCallback (internal/process/next_tick.js:122:9) > ``` -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (THRIFT-4214) map key treated as hex value in JavaScript
[
https://issues.apache.org/jira/browse/THRIFT-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4214:
--
Priority: Major (was: Critical)
> map key treated as hex value in JavaScript
> -
>
> Key: THRIFT-4214
> URL: https://issues.apache.org/jira/browse/THRIFT-4214
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Compiler, Node.js - Library
>Affects Versions: 0.10.0
>Reporter: Teodor Atroshenko
>Priority: Major
> Labels: easyfix
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The service is defined with the following function:
> {code:javascript}
> map someFunctionName()
> {code}
> The --gen js:node code:
> {code:javascript}
> output.writeFieldBegin('success', Thrift.Type.MAP, 0);
> output.writeMapBegin(Thrift.Type.I64, Thrift.Type.DOUBLE,
> Thrift.objectLength(this.success));
> for (var kiter18 in this.success)
> {
> if (this.success.hasOwnProperty(kiter18))
> {
> var viter19 = this.success[kiter18];
> output.writeI64(kiter18);
> output.writeDouble(viter19);
> }
> }
> output.writeMapEnd();
> output.writeFieldEnd();
> {code}
> String {{kiter18}} is passed to {{output.writeI64}}. Only *TBinaryProtocol*
> is affected by this. The function
> [defenition|https://github.com/apache/thrift/blob/19baeefd8c38d62085891d7956349601f79448b3/lib/nodejs/lib/thrift/binary_protocol.js#L137]:
> {code:javascript}
> TBinaryProtocol.prototype.writeI64 = function(i64) {
> if (i64.buffer) {
> this.trans.write(i64.buffer);
> } else {
> this.trans.write(new Int64(i64).buffer);
> }
> };
> {code}
> *Int64*
> [constructor|https://github.com/broofa/node-int64/blob/master/Int64.js#L49]
> accepts the following arguments:
> * new Int64(buffer\[, offset=0]) - Existing Buffer with byte offset
> * new Int64(Uint8Array\[, offset=0]) - Existing Uint8Array with a byte offset
> * new Int64(string) - Hex string (throws if n is outside int64
> range)
> * new Int64(number) - Number (throws if n is outside int64 range)
> * new Int64(hi, lo) - Raw bits as two 32-bit values
> What happens, is that JavaScript object keys are always Strings, so the
> generated function passes the object key as-is (in String representation) and
> *Int64* library assumes it's a hex string and converts it to a different
> 64-bit integer.
> For example {{"4398046511580"}} becomes {{\[Int64 value:1189123005158784
> octets:00 04 39 80 46 51 15 80]}}
> This also happens when returning {{list}}, however in lists it can be
> bypassed by calling {{Number()}} on all Array elements before passing it to
> Thrift's {{result()}} function.
> To solve this, the compiler can be adding {{Number()}} around everything that
> is a decimal number that is passed to {{writeI64}}; and if {{writeI64}} will
> never be called with an actual hex string, then js library can be updated to
> include the {{Number()}} call around *Int64* constructor argument.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-3218) Large responses when using a MultiplexedProcessor fail to find client after first read.
[
https://issues.apache.org/jira/browse/THRIFT-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-3218:
--
Priority: Major (was: Critical)
> Large responses when using a MultiplexedProcessor fail to find client after
> first read.
> ---
>
> Key: THRIFT-3218
> URL: https://issues.apache.org/jira/browse/THRIFT-3218
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.9.2
>Reporter: Bradley Holbrook
>Assignee: Randy Abernethy
>Priority: Major
> Labels: easyfix, javascript
>
> Receiving a large response using a multiplexed processor fails to complete
> the read because the service is prematurely deleted in the connection data
> listener callback. Below shows the problem code and the solution deployed to
> solve it.
> {code:javascript|title=Original connection.js client creation}
> while (true) {
> var header = message.readMessageBegin();
> var dummy_seqid = header.rseqid * -1;
> var client = self.client;
> //The Multiplexed Protocol stores a hash of seqid to service names
> // in seqId2Service. If the SeqId is found in the hash we need to
> // lookup the appropriate client for this call.
> // The connection.client object is a single client object when not
> // multiplexing, when using multiplexing it is a service name keyed
> // hash of client objects.
> //NOTE: The 2 way interdependencies between protocols, transports,
> // connections and clients in the Node.js implementation are
> irregular
> // and make the implementation difficult to extend and maintain. We
> // should bring this stuff inline with typical thrift I/O stack
> // operation soon.
> // --ra
> var service_name = self.seqId2Service[header.rseqid];
> if (service_name) {
> client = self.client[service_name];
> delete self.seqId2Service[header.rseqid];
> }
> // ...
> }
> {code}
> {code:javascript|title=Working connection.js client creation}
> while (true) {
> var header = message.readMessageBegin();
> var dummy_seqid = header.rseqid * -1;
> var client = self.client;
> //The Multiplexed Protocol stores a hash of seqid to service names
> // in seqId2Service. If the SeqId is found in the hash we need to
> // lookup the appropriate client for this call.
> // The connection.client object is a single client object when not
> // multiplexing, when using multiplexing it is a service name keyed
> // hash of client objects.
> //NOTE: The 2 way interdependencies between protocols, transports,
> // connections and clients in the Node.js implementation are
> irregular
> // and make the implementation difficult to extend and maintain. We
> // should bring this stuff inline with typical thrift I/O stack
> // operation soon.
> // --ra
> var service_name = self.seqId2Service[header.rseqid];
> if (service_name) {
> client = self.client[service_name];
> }
> // ...
> }
> if(self.seqId2Service[header.rseqid]) {
> delete self.seqId2Service[header.rseqid];
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Issue Comment Deleted] (THRIFT-3218) Large responses when using a MultiplexedProcessor fail to find client after first read.
[
https://issues.apache.org/jira/browse/THRIFT-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-3218:
--
Comment: was deleted
(was: Scratch that... perhaps still critical. :))
> Large responses when using a MultiplexedProcessor fail to find client after
> first read.
> ---
>
> Key: THRIFT-3218
> URL: https://issues.apache.org/jira/browse/THRIFT-3218
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.9.2
>Reporter: Bradley Holbrook
>Assignee: Randy Abernethy
>Priority: Critical
> Labels: easyfix, javascript
>
> Receiving a large response using a multiplexed processor fails to complete
> the read because the service is prematurely deleted in the connection data
> listener callback. Below shows the problem code and the solution deployed to
> solve it.
> {code:javascript|title=Original connection.js client creation}
> while (true) {
> var header = message.readMessageBegin();
> var dummy_seqid = header.rseqid * -1;
> var client = self.client;
> //The Multiplexed Protocol stores a hash of seqid to service names
> // in seqId2Service. If the SeqId is found in the hash we need to
> // lookup the appropriate client for this call.
> // The connection.client object is a single client object when not
> // multiplexing, when using multiplexing it is a service name keyed
> // hash of client objects.
> //NOTE: The 2 way interdependencies between protocols, transports,
> // connections and clients in the Node.js implementation are
> irregular
> // and make the implementation difficult to extend and maintain. We
> // should bring this stuff inline with typical thrift I/O stack
> // operation soon.
> // --ra
> var service_name = self.seqId2Service[header.rseqid];
> if (service_name) {
> client = self.client[service_name];
> delete self.seqId2Service[header.rseqid];
> }
> // ...
> }
> {code}
> {code:javascript|title=Working connection.js client creation}
> while (true) {
> var header = message.readMessageBegin();
> var dummy_seqid = header.rseqid * -1;
> var client = self.client;
> //The Multiplexed Protocol stores a hash of seqid to service names
> // in seqId2Service. If the SeqId is found in the hash we need to
> // lookup the appropriate client for this call.
> // The connection.client object is a single client object when not
> // multiplexing, when using multiplexing it is a service name keyed
> // hash of client objects.
> //NOTE: The 2 way interdependencies between protocols, transports,
> // connections and clients in the Node.js implementation are
> irregular
> // and make the implementation difficult to extend and maintain. We
> // should bring this stuff inline with typical thrift I/O stack
> // operation soon.
> // --ra
> var service_name = self.seqId2Service[header.rseqid];
> if (service_name) {
> client = self.client[service_name];
> }
> // ...
> }
> if(self.seqId2Service[header.rseqid]) {
> delete self.seqId2Service[header.rseqid];
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-4623) Python compiler generates inoperable definitions for default-valued classes in same thrift file
[
https://issues.apache.org/jira/browse/THRIFT-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4623:
--
Priority: Major (was: Critical)
> Python compiler generates inoperable definitions for default-valued classes
> in same thrift file
> ---
>
> Key: THRIFT-4623
> URL: https://issues.apache.org/jira/browse/THRIFT-4623
> Project: Thrift
> Issue Type: Bug
> Components: Python - Compiler
>Affects Versions: 0.11.0
>Reporter: Matt Anthony
>Priority: Major
>
> Consider a thrift file as
>
>
> struct A {
> i32 value;
> }
>
> struct B {
> A itm = {}
> }
>
>
> The thrift compiler will generate class definitions for A and B, without
> `self.thrift_spec` defined, and at the end of the ttypes.py file will go back
> and populate the thrift_spec objects. However, in the __init__ method of B,
> the default value for `itm` would attempt to be set as `A(**{})`, which will
> crash with error `AttributeError: 'ObservationInfo' object has no attribute
> 'thrift_spec'`. This makes sense since at the time the default object is
> being established, there is no thrift_spec object.
> Removing the default value removes the error, but this is not correct
> behavior. The most obvious fix is that the `thrift_spec` object of each class
> needs to be defined within the class as the class is written, not at the end
> of the file after all the class objects are established. Moreover, that is
> generally good practice and is actually part of the PEP prescriptions for
> python (referencing objects before initialization in a class is a highlighted
> warning, for this very reason).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (THRIFT-4677) UnicodeDecodeError in Python3
[
https://issues.apache.org/jira/browse/THRIFT-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897658#comment-16897658
]
James E. King III commented on THRIFT-4677:
---
There isn't a lot of information in this, especially to reproduce it. I'm
going to lower the severity.
> UnicodeDecodeError in Python3
> -
>
> Key: THRIFT-4677
> URL: https://issues.apache.org/jira/browse/THRIFT-4677
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
> Environment: Operating System: Windows 10 Pro (Simplified Chinese)
> Python Interpreter: Python 3.6.6
> {{osquery}} Version: 3.3.0
> {{osquery-python}} Version: 3.0.5
>
>Reporter: Jarry Shaw
>Priority: Critical
> Attachments: compat.py
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> This is an issue occurred when using
> [osquery-python|https://github.com/osquery/osquery-python] (Python binding of
> [osquery|https://osquery.io/] by Facebook).
> When querying, {{UnicodeDecodeError}} raised with error message: "{{'utf-8'
> codec can't decode byte 0xc3 in position 0: invalid continuation byte}}" from
> {{thrift.compat.binary_to_str}}, which is because the encoding of {{bin_val}}
> parameter should be "{{gbk}}".
> Possible approaches are:
> * add a parameter for user to determine encodings
> * get the system encoding through {{locale.getpreferredencoding()}}
> * call {{bin_val.decode}} with {{errors='replace'}} or {{errors='ignore'}}
> parameter
> * introduce {{chardet}} to try and resolve encoding problems
> The attachment is my hack solution to this issue (through not perfect).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-4677) UnicodeDecodeError in Python3
[
https://issues.apache.org/jira/browse/THRIFT-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4677:
--
Priority: Major (was: Critical)
> UnicodeDecodeError in Python3
> -
>
> Key: THRIFT-4677
> URL: https://issues.apache.org/jira/browse/THRIFT-4677
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
> Environment: Operating System: Windows 10 Pro (Simplified Chinese)
> Python Interpreter: Python 3.6.6
> {{osquery}} Version: 3.3.0
> {{osquery-python}} Version: 3.0.5
>
>Reporter: Jarry Shaw
>Priority: Major
> Attachments: compat.py
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> This is an issue occurred when using
> [osquery-python|https://github.com/osquery/osquery-python] (Python binding of
> [osquery|https://osquery.io/] by Facebook).
> When querying, {{UnicodeDecodeError}} raised with error message: "{{'utf-8'
> codec can't decode byte 0xc3 in position 0: invalid continuation byte}}" from
> {{thrift.compat.binary_to_str}}, which is because the encoding of {{bin_val}}
> parameter should be "{{gbk}}".
> Possible approaches are:
> * add a parameter for user to determine encodings
> * get the system encoding through {{locale.getpreferredencoding()}}
> * call {{bin_val.decode}} with {{errors='replace'}} or {{errors='ignore'}}
> parameter
> * introduce {{chardet}} to try and resolve encoding problems
> The attachment is my hack solution to this issue (through not perfect).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[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
]
James E. King III updated THRIFT-4080:
--
Priority: Major (was: Critical)
> 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: Major
>
> 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", _addr), sin6_flowinfo=0,
> sin6_scope_id=0}, [28]) = 6
> [pid 2693] recvfrom(6,
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[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=16897657#comment-16897657
]
James E. King III commented on THRIFT-4080:
---
The title is about unix sockets; how does this affect Unix sockets?
> 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", _addr), sin6_flowinfo=0,
> sin6_scope_id=0}, [28]) = 6
> [pid 2693] recvfrom(6,
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (THRIFT-3604) NuGet release should include compiler, and say 'official'
[ https://issues.apache.org/jira/browse/THRIFT-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897653#comment-16897653 ] James E. King III commented on THRIFT-3604: --- This issue is still open for 0.13.0 and will look at changing the release plans. > NuGet release should include compiler, and say 'official' > - > > Key: THRIFT-3604 > URL: https://issues.apache.org/jira/browse/THRIFT-3604 > Project: Thrift > Issue Type: Improvement > Components: Deployment >Affects Versions: 0.9.3 > Environment: Nuget, for users of Visual Studio >Reporter: david bennett >Priority: Major > Fix For: 0.13.0 > > > The current NuGet release includes a library but no compiler. It should > include a compiler that matches the library. > This affects users who wish to use an automated build process based on > MsBuild and package restore, and who do not wish to check the compiler into > their source tree. > Side-note: the community version does include a compiler, is older, but has > many more downloads. The official version should clearly state that (a) it > contains a compiler (b) it is the official version. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-4874) Thrift 0.12.0 Source Distribution (.tar.gz) Contains Hardlinks - Extract Fails
[ https://issues.apache.org/jira/browse/THRIFT-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897652#comment-16897652 ] James E. King III commented on THRIFT-4874: --- This issue is still open for 0.13.0 - will have to take a look at the distribution packages to see where they come from. > Thrift 0.12.0 Source Distribution (.tar.gz) Contains Hardlinks - Extract Fails > -- > > Key: THRIFT-4874 > URL: https://issues.apache.org/jira/browse/THRIFT-4874 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.12.0 >Reporter: Daniel Jewell >Assignee: James E. King III >Priority: Blocker > Fix For: 0.13.0 > > > Hello! > The source release tarball of Thrift contains hardlinks - which makes it > impossible to extract on a platform where you cannot create hardlinks (e.g. > on a non-root Android device). (e.g. the archive was not created with > --hard-dereference) > I discovered this as a knock-on effect of trying to build Apache Arrow C++ on > Android (in Termux)... The build fails because the Thrift tarball can't be > extracted because of the hardlinks. > Best, > -Daniel -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-4907) strong named assemblies wanted
[ https://issues.apache.org/jira/browse/THRIFT-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897651#comment-16897651 ] James E. King III commented on THRIFT-4907: --- This issue is still open for 0.13.0. > strong named assemblies wanted > -- > > Key: THRIFT-4907 > URL: https://issues.apache.org/jira/browse/THRIFT-4907 > Project: Thrift > Issue Type: Bug > Components: C# - Library, netcore - Library, netstd - Library >Affects Versions: 0.12.0 >Reporter: Benjamin Kraemer >Assignee: Jens Geyer >Priority: Blocker > Fix For: 0.13.0 > > > In THRIFT-2947, a strong name should have been added to > [https://www.nuget.org/packages/ApacheThrift/0.12.0.1] > Looking at the DLL, it's not signed at all. The assembly name is still > `Thrift, Version=0.12.0.0, Culture=neutral, PublicKeyToken=null` and > therefore missing the `PublicKeyToken` part. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (THRIFT-4871) unresolved boost::mutex::scoped_lock dependencies on armhf
[
https://issues.apache.org/jira/browse/THRIFT-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III resolved THRIFT-4871.
---
Resolution: Not A Problem
Assignee: James E. King III
0.13.0 code uses the std namespace and not boost, unless you specifically ask
for it.
> unresolved boost::mutex::scoped_lock dependencies on armhf
> --
>
> Key: THRIFT-4871
> URL: https://issues.apache.org/jira/browse/THRIFT-4871
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.12.0
>Reporter: Daniel Haensse
>Assignee: James E. King III
>Priority: Trivial
> Fix For: 0.13.0
>
>
> It seems like on certain platforms that for the boost::mutex::scoped_lock is
> not included in the boost lib and that libboost_atomic must be included as
> well (boost 1.62).
> I tried to compile thrift on the current Raspian distro and it did not work
> without the LIBS=-lboost_atomic parameter, see below.
> {{{color:#00}_*$ export CXXFLAGS="-DFORCE_BOOST_SMART_PTR
> -DFORCE_BOOST_FUNCTIONAL"*_{color}}}
> {{{color:#00}_*$ ./bootstrap.sh*_{color}}}{{{color:#00}_*$
> ./configure -ls-without-java LIBS=-lboost_atomic*_{color}}}
> {{{color:#00}_*$ make -j3 VERBOSE=1*_{color}}}
> {{{color:#00}_*$ make install*_{color}}}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-4871) unresolved boost::mutex::scoped_lock dependencies on armhf
[
https://issues.apache.org/jira/browse/THRIFT-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4871:
--
Fix Version/s: (was: 0.12.0)
0.13.0
> unresolved boost::mutex::scoped_lock dependencies on armhf
> --
>
> Key: THRIFT-4871
> URL: https://issues.apache.org/jira/browse/THRIFT-4871
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.12.0
>Reporter: Daniel Haensse
>Priority: Trivial
> Fix For: 0.13.0
>
>
> It seems like on certain platforms that for the boost::mutex::scoped_lock is
> not included in the boost lib and that libboost_atomic must be included as
> well (boost 1.62).
> I tried to compile thrift on the current Raspian distro and it did not work
> without the LIBS=-lboost_atomic parameter, see below.
> {{{color:#00}_*$ export CXXFLAGS="-DFORCE_BOOST_SMART_PTR
> -DFORCE_BOOST_FUNCTIONAL"*_{color}}}
> {{{color:#00}_*$ ./bootstrap.sh*_{color}}}{{{color:#00}_*$
> ./configure -ls-without-java LIBS=-lboost_atomic*_{color}}}
> {{{color:#00}_*$ make -j3 VERBOSE=1*_{color}}}
> {{{color:#00}_*$ make install*_{color}}}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-4730) Remove pthread and boost::thread library support and use std::thread for C++11
[ https://issues.apache.org/jira/browse/THRIFT-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4730: -- Component/s: C++ - Library > Remove pthread and boost::thread library support and use std::thread for C++11 > -- > > Key: THRIFT-4730 > URL: https://issues.apache.org/jira/browse/THRIFT-4730 > Project: Thrift > Issue Type: Improvement > Components: C++ - Library >Reporter: yuanyuan chen >Assignee: James E. King III >Priority: Major > Labels: Breaking-Change > Fix For: 0.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Using C++11 std::thread and std::mutex instead of pthread to enhance > portability across different platforms (especially Windows). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (THRIFT-4845) PHP's TCurlClient ignores timeout values smaller that 1 second
[ https://issues.apache.org/jira/browse/THRIFT-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4845: -- Component/s: PHP - Library > PHP's TCurlClient ignores timeout values smaller that 1 second > -- > > Key: THRIFT-4845 > URL: https://issues.apache.org/jira/browse/THRIFT-4845 > Project: Thrift > Issue Type: Bug > Components: PHP - Library > Environment: PHP 7.* >Reporter: Jeremy Mikkola >Assignee: James E. King III >Priority: Minor > Fix For: 0.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Presently, if you specify a fractional timeout (e.g. 0.2) with > setTimeoutSecs(), it is ignored and the request is allowed to take an > arbitrary amount of time. > > Specifying integer timeouts works as expected (e.g. 1, 2, or more seconds). > > This happens because [this > line|https://github.com/apache/thrift/blob/c9b1e29bc9e0702d7441383358d565e1e76ccea7/lib/php/lib/Transport/TCurlClient.php#L233] > uses CURLOPT_TIMEOUT instead of CURLOPT_TIMEOUT_MS. > > I have a patch I'll submit after creating this ticket. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (THRIFT-4842) Multiplexed protocol has a memory leak in set c_glib
[ https://issues.apache.org/jira/browse/THRIFT-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4842: -- Component/s: C glib - Library > Multiplexed protocol has a memory leak in set c_glib > > > Key: THRIFT-4842 > URL: https://issues.apache.org/jira/browse/THRIFT-4842 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.12.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar >Priority: Major > Fix For: 0.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The multiplexed protocol is affected by a memory leak in set property in the > c_gllib version when setting the service to be multiplexed. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (THRIFT-4773) TSaslTransport should relay underlying TTransportException to TSaslTransportException
[
https://issues.apache.org/jira/browse/THRIFT-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4773:
--
Component/s: Java - Library
> TSaslTransport should relay underlying TTransportException to
> TSaslTransportException
> --
>
> Key: THRIFT-4773
> URL: https://issues.apache.org/jira/browse/THRIFT-4773
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Library
>Reporter: Qinghui Xu
>Assignee: James E. King III
>Priority: Major
> Fix For: 0.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For java lib:
> Currently when opening TsaslTransport, it will raise TSaslTransportException
> if the underlying transport throws an TTransportException, without relaying
> the root cause. This is confusing sometimes when user tries to trouble shoot
> the problem.
> We got some stack trace like this, but could not see about the true root
> cause:
> {code:java}
> 19/02/06 15:46:55 [HiveServer2-Handler-Pool: Thread-666]: ERROR
> server.TThreadPoolServer: Error occurred during processing of message.
> java.lang.RuntimeException:
> org.apache.thrift.transport.TSaslTransportException: No data or no sasl data
> in the stream
> at
> org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:219)
> at
> org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge.java:793)
> at
> org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory$1.run(HadoopThriftAuthBridge.java:790)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1900)
> at
> org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory.getTransport(HadoopThriftAuthBridge.java:790)
> at
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:269)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.thrift.transport.TSaslTransportException: No data or no
> sasl data in the stream
> at
> org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:328)
> at
> org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41)
> at
> org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:216)
> ... 10 more{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-4846) C++ generator should topologically sort struct definitions and error on cycles
[
https://issues.apache.org/jira/browse/THRIFT-4846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4846:
--
Component/s: C++ - Compiler
> C++ generator should topologically sort struct definitions and error on cycles
> --
>
> Key: THRIFT-4846
> URL: https://issues.apache.org/jira/browse/THRIFT-4846
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Reporter: Todd Lipcon
>Assignee: Todd Lipcon
>Priority: Major
> Attachments: thrift-4846.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> C++ (and maybe other languages?) treat Thrift struct-typed fields as plain
> struct members of the containing struct. Currently, the generator outputs the
> types in the same order as they're defined in the underlying Thrift field,
> which means that a file like:
> {code}
> struct A {
> 1: B foo;
> }
> struct B {
> }
> {code}
> will generate C++ code that fails to compile.
> We should topologically-sort the structs before outputting the definitions so
> that the generated code compiles correctly.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-4864) CI fails at netstd
[
https://issues.apache.org/jira/browse/THRIFT-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4864:
--
Component/s: Build Process
> CI fails at netstd
> --
>
> Key: THRIFT-4864
> URL: https://issues.apache.org/jira/browse/THRIFT-4864
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> Failed TJSONProtocol_Can_Create_Instance_Test
> Error Message:
> Test method
> Thrift.Tests.Protocols.TJSONProtocolTests.TJSONProtocol_Can_Create_Instance_Test
> threw exception:
> Castle.DynamicProxy.InvalidProxyConstructorArgumentsException: Can not
> instantiate proxy of class: Thrift.Transport.Client.THttpTransport.
> Could not find a constructor that would match given arguments:
> System.Uri
>
> Stack Trace:
> at Castle.DynamicProxy.ProxyGenerator.CreateClassProxyInstance(Type
> proxyType, List`1 proxyArguments, Type classToProxy, Object[]
> constructorArguments)
>at
> NSubstitute.Proxies.CastleDynamicProxy.CastleDynamicProxyFactory.GenerateProxy(ICallRouter
> callRouter, Type typeToProxy, Type[] additionalInterfaces, Object[]
> constructorArguments)
>at NSubstitute.Substitute.For[T](Object[] constructorArguments)
>at
> Thrift.Tests.Protocols.TJSONProtocolTests.TJSONProtocol_Can_Create_Instance_Test()
> in
> /thrift/src/lib/netstd/Tests/Thrift.Tests/Protocols/TJsonProtocolTests.cs:line
> 39
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-4874) Thrift 0.12.0 Source Distribution (.tar.gz) Contains Hardlinks - Extract Fails
[ https://issues.apache.org/jira/browse/THRIFT-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4874: -- Component/s: Build Process > Thrift 0.12.0 Source Distribution (.tar.gz) Contains Hardlinks - Extract Fails > -- > > Key: THRIFT-4874 > URL: https://issues.apache.org/jira/browse/THRIFT-4874 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.12.0 >Reporter: Daniel Jewell >Assignee: James E. King III >Priority: Blocker > Fix For: 0.13.0 > > > Hello! > The source release tarball of Thrift contains hardlinks - which makes it > impossible to extract on a platform where you cannot create hardlinks (e.g. > on a non-root Android device). (e.g. the archive was not created with > --hard-dereference) > I discovered this as a knock-on effect of trying to build Apache Arrow C++ on > Android (in Termux)... The build fails because the Thrift tarball can't be > extracted because of the hardlinks. > Best, > -Daniel -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (THRIFT-4875) Thrift compiler generates invalid Haskell code
[
https://issues.apache.org/jira/browse/THRIFT-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4875:
--
Component/s: Haskell - Compiler
> Thrift compiler generates invalid Haskell code
> --
>
> Key: THRIFT-4875
> URL: https://issues.apache.org/jira/browse/THRIFT-4875
> Project: Thrift
> Issue Type: Bug
> Components: Haskell - Compiler
>Affects Versions: 0.12.0
>Reporter: g. unabetida
>Priority: Minor
>
> With the following .thrift file:
> {code:java}
> struct Dummy {
> 1: string dummy;
> }
> const Dummy emptyDummy = { }{code}
> the Thrift compiler generates Haskell code with an empty record update:
> {code:java}
> emptyDummy :: Dummy
> emptyDummy = default_Dummy{}{code}
> This doesn't compile. I think removing {} fixes the problem?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (THRIFT-4877) TNonblockingServerTransport not implemented in C#
[
https://issues.apache.org/jira/browse/THRIFT-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897641#comment-16897641
]
James E. King III commented on THRIFT-4877:
---
The title is correct: "I've try my best to convert the java code of non-block
server to the corresponding C# code but I found that there seems to be no
TNonblockingServerTransport in C#."
> TNonblockingServerTransport not implemented in C#
> -
>
> Key: THRIFT-4877
> URL: https://issues.apache.org/jira/browse/THRIFT-4877
> Project: Thrift
> Issue Type: Improvement
> Components: netstd - Library
>Affects Versions: 0.12.0
> Environment: VS2017 Community
> Windows 10 x64
>Reporter: Shannon Chow
>Priority: Major
>
> When using Apache Thrift [[https://github.com/apache/thrift]] to create a non
> blocking server in C#, the following Classes/Types cannot be recognized:
> {{TNonblockingServerTransport TNonblockingServer}}
>
> {{All trials were based on the official C# tutorial. A more detailed
> description(if needed) is followed:}}
> {{[https://stackoverflow.com/questions/56404899/tnonblockingservertransport-cannot-be-recognized-when-using-thrift-c-sharp]}}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-4877) TNonblockingServerTransport not implemented in C#
[
https://issues.apache.org/jira/browse/THRIFT-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4877:
--
Component/s: netstd - Library
> TNonblockingServerTransport not implemented in C#
> -
>
> Key: THRIFT-4877
> URL: https://issues.apache.org/jira/browse/THRIFT-4877
> Project: Thrift
> Issue Type: Improvement
> Components: netstd - Library
>Affects Versions: 0.12.0
> Environment: VS2017 Community
> Windows 10 x64
>Reporter: Shannon Chow
>Priority: Major
>
> When using Apache Thrift [[https://github.com/apache/thrift]] to create a non
> blocking server in C#, the following Classes/Types cannot be recognized:
> {{TNonblockingServerTransport TNonblockingServer}}
>
> {{All trials were based on the official C# tutorial. A more detailed
> description(if needed) is followed:}}
> {{[https://stackoverflow.com/questions/56404899/tnonblockingservertransport-cannot-be-recognized-when-using-thrift-c-sharp]}}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (THRIFT-4887) Thrift will OOM at a low concurrency if fields added and old client requests new server
[ https://issues.apache.org/jira/browse/THRIFT-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4887. - > Thrift will OOM at a low concurrency if fields added and old client requests > new server > --- > > Key: THRIFT-4887 > URL: https://issues.apache.org/jira/browse/THRIFT-4887 > Project: Thrift > Issue Type: Bug > Environment: Almost all versions from 0.8.0 to the newest > 0.13.0-snapshot, and verify on 0.9.3/0.11.0. > Almost all languages, and verified on Go/Java >Reporter: aqingsir >Assignee: James E. King III >Priority: Major > Attachments: readI32.jpg > > Time Spent: 40m > Remaining Estimate: 0h > > (Could see more on [https://github.com/aqingsao/thrift-oom]) > //background > A serious issue occured in our prod env and finally it came out to be the > changement of some fields in an IDL file, old client still requested new > server and crashed due to OOM. > IDL changement could be stated as: Return value of the interface is a list, > element of which is a struct object and has 5 fields. A new field is added to > the middle of the struct. > // to reproduce > In this case a low concurency of 10 will reproduce this issue, you could find > a demo project on: [https://github.com/aqingsao/thrift-oom] > // reason > Thrift tries to consume all data in inputstream by skipping fields that are > redundant or have a type mismatch. But it won't consume subsequent fields if > there's an exception. > In such a case Thrift does nothing the underlying inputstream, so trouble > comes to the next request who reuses this connection, as the cursor still > points to some middle position of the inputstream. > As Thrift always starts with a readI32() method for any response, which means > the length of the method's name. Unbelievable the length could be as large as > 184549632, which is about 176M. This explains why OOM occurs even at a > concurrency of 10 > // how to fix > Always clear inputstream in TSocket if there are any redundant data at the > end of a method call. > I'll submit a PR soon for Java version. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (THRIFT-4889) [Java] Add SASL support for non-blocking server
[ https://issues.apache.org/jira/browse/THRIFT-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4889: -- Component/s: Java - Library > [Java] Add SASL support for non-blocking server > --- > > Key: THRIFT-4889 > URL: https://issues.apache.org/jira/browse/THRIFT-4889 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Reporter: Qinghui Xu >Priority: Major > > Currently, it seems the sasl is available only for blocking server. But in > some circumstances the server cannot handle the workload/nb of connections > with the blocking IO, we need SASL support to secure the non-blocking IO > servers in such situations. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-4912) Configuring with $JAVA_PREFIX leads to $JAVA_PREFIX/usr/local/lib
[ https://issues.apache.org/jira/browse/THRIFT-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894702#comment-16894702 ] James E. King III commented on THRIFT-4912: --- The case for PREFIX should also be fixed; if PREFIX is set (and JAVA_PREFIX is not set) then JAVA_PREFIX should become $PREFIX/lib, correct? > Configuring with $JAVA_PREFIX leads to $JAVA_PREFIX/usr/local/lib > -- > > Key: THRIFT-4912 > URL: https://issues.apache.org/jira/browse/THRIFT-4912 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.12.0 >Reporter: Ben Pavon >Priority: Minor > > While configuring thrift-0.12.0 on Red Hat Linux and targeting Java and Perl, > I used --prefix and defined $JAVA_PREFIX and $PERL_PREFIX in order to control > where Thrift is installed. Both --prefix and $PERL_PREFIX worked as intended. > However, setting $JAVA_PREFIX resulted in $JAVA_PREFIX/usr/local/lib. This is > because of the following code in the configure script: > if test "x$JAVA_PREFIX" != x; then : > JAVA_PREFIX="$JAVA_PREFIX/usr/local/lib" > elif test "x$PREFIX" != x; then : > JAVA_PREFIX="$PREFIX/usr/local/lib" > else > JAVA_PREFIX="/usr/local/lib" > fi > I believe the above code should be replaced with one that sets $JAVA_PREFIX > to /usr/local/lib only if it is not defined. > > > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (THRIFT-4910) ./configure: line 14116: syntax error near unexpected token `QT5,'
[ https://issues.apache.org/jira/browse/THRIFT-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4910. - Resolution: Information Provided Assignee: James E. King III > ./configure: line 14116: syntax error near unexpected token `QT5,' > -- > > Key: THRIFT-4910 > URL: https://issues.apache.org/jira/browse/THRIFT-4910 > Project: Thrift > Issue Type: Question > Components: Build Process >Affects Versions: 0.13.0 > Environment: Ubuntu 19.04 >Reporter: Rocco Corsi >Assignee: James E. King III >Priority: Minor > Attachments: config.log, configure.out.txt, console.txt, > console_20190723_1436.txt > > > Testing build of latest master branch on Ubuntu 19.04 > Failing on configure > ... > checking whether yytext is a pointer... yes > checking whether ln -s works... yes > checking for gawk... (cached) mawk > checking for ranlib... (cached) ranlib > checking whether g++ supports C++11 features with -std=c++11... yes > ./configure: line 14116: syntax error near unexpected token `QT5,' > ./configure: line 14116: ` PKG_CHECK_MODULES(QT5, Qt5Core >= 5.0, > Qt5Network >= 5.0,' > Might there be something wrong in my environment, wrong version of something > (e.g. I have automake 1.16.1-4) > > Attached my console log output and config.log file. > > Current commit: > commit 4c847372eb9af8ec0b21ace31840eaabfdf32660 (HEAD -> master, > origin/master, origin/HEAD) > Author: guozhu cheng > Date: Mon Jul 15 19:46:25 2019 +0800 > THRIFT-4908: remove reader in Golang's TBinaryProtocol > > Client: go > > This closes #1831. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-4910) ./configure: line 14116: syntax error near unexpected token `QT5,'
[ https://issues.apache.org/jira/browse/THRIFT-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893045#comment-16893045 ] James E. King III commented on THRIFT-4910: --- While it would be nice to add a check for that package somewhere in the startup process, this is the first time I've heard of it, so I'm inclined not to make any changes. > ./configure: line 14116: syntax error near unexpected token `QT5,' > -- > > Key: THRIFT-4910 > URL: https://issues.apache.org/jira/browse/THRIFT-4910 > Project: Thrift > Issue Type: Question > Components: Build Process >Affects Versions: 0.13.0 > Environment: Ubuntu 19.04 >Reporter: Rocco Corsi >Priority: Minor > Attachments: config.log, configure.out.txt, console.txt, > console_20190723_1436.txt > > > Testing build of latest master branch on Ubuntu 19.04 > Failing on configure > ... > checking whether yytext is a pointer... yes > checking whether ln -s works... yes > checking for gawk... (cached) mawk > checking for ranlib... (cached) ranlib > checking whether g++ supports C++11 features with -std=c++11... yes > ./configure: line 14116: syntax error near unexpected token `QT5,' > ./configure: line 14116: ` PKG_CHECK_MODULES(QT5, Qt5Core >= 5.0, > Qt5Network >= 5.0,' > Might there be something wrong in my environment, wrong version of something > (e.g. I have automake 1.16.1-4) > > Attached my console log output and config.log file. > > Current commit: > commit 4c847372eb9af8ec0b21ace31840eaabfdf32660 (HEAD -> master, > origin/master, origin/HEAD) > Author: guozhu cheng > Date: Mon Jul 15 19:46:25 2019 +0800 > THRIFT-4908: remove reader in Golang's TBinaryProtocol > > Client: go > > This closes #1831. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-4910) ./configure: line 14116: syntax error near unexpected token `QT5,'
[ https://issues.apache.org/jira/browse/THRIFT-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892755#comment-16892755 ] James E. King III commented on THRIFT-4910: --- See the accepted answer here, it may help: [https://askubuntu.com/questions/468661/how-to-fix-pkg-prog-pkg-config-command-not-found-error] > ./configure: line 14116: syntax error near unexpected token `QT5,' > -- > > Key: THRIFT-4910 > URL: https://issues.apache.org/jira/browse/THRIFT-4910 > Project: Thrift > Issue Type: Question > Components: Build Process >Affects Versions: 0.13.0 > Environment: Ubuntu 19.04 >Reporter: Rocco Corsi >Priority: Minor > Attachments: config.log, configure.out.txt, console.txt, > console_20190723_1436.txt > > > Testing build of latest master branch on Ubuntu 19.04 > Failing on configure > ... > checking whether yytext is a pointer... yes > checking whether ln -s works... yes > checking for gawk... (cached) mawk > checking for ranlib... (cached) ranlib > checking whether g++ supports C++11 features with -std=c++11... yes > ./configure: line 14116: syntax error near unexpected token `QT5,' > ./configure: line 14116: ` PKG_CHECK_MODULES(QT5, Qt5Core >= 5.0, > Qt5Network >= 5.0,' > Might there be something wrong in my environment, wrong version of something > (e.g. I have automake 1.16.1-4) > > Attached my console log output and config.log file. > > Current commit: > commit 4c847372eb9af8ec0b21ace31840eaabfdf32660 (HEAD -> master, > origin/master, origin/HEAD) > Author: guozhu cheng > Date: Mon Jul 15 19:46:25 2019 +0800 > THRIFT-4908: remove reader in Golang's TBinaryProtocol > > Client: go > > This closes #1831. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (THRIFT-4910) ./configure: line 14116: syntax error near unexpected token `QT5,'
[ https://issues.apache.org/jira/browse/THRIFT-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891551#comment-16891551 ] James E. King III edited comment on THRIFT-4910 at 7/24/19 2:53 AM: I do not have any problems using Disco other than OCaml and Swift languages had to be disabled in the docker image in order to build / bootstrap / configure. See [https://github.com/apache/thrift/commit/90a044659878f3581aba922dbde1ed4bd7918678] For information about using the docker build containers: [https://github.com/apache/thrift/blob/master/build/docker/README.md] was (Author: jking3): I do not have any problems using Disco other than OCaml and Swift languages had to be disabled in the docker image in order to build / bootstrap / configure. See [https://github.com/apache/thrift/commit/90a044659878f3581aba922dbde1ed4bd7918678] For information about using the docker build containers: [https://github.com/apache/thrift/blob/master/build/docker/README.md] > ./configure: line 14116: syntax error near unexpected token `QT5,' > -- > > Key: THRIFT-4910 > URL: https://issues.apache.org/jira/browse/THRIFT-4910 > Project: Thrift > Issue Type: Question > Components: Build Process >Affects Versions: 0.13.0 > Environment: Ubuntu 19.04 >Reporter: Rocco Corsi >Priority: Minor > Attachments: config.log, configure.out.txt, console.txt, > console_20190723_1436.txt > > > Testing build of latest master branch on Ubuntu 19.04 > Failing on configure > ... > checking whether yytext is a pointer... yes > checking whether ln -s works... yes > checking for gawk... (cached) mawk > checking for ranlib... (cached) ranlib > checking whether g++ supports C++11 features with -std=c++11... yes > ./configure: line 14116: syntax error near unexpected token `QT5,' > ./configure: line 14116: ` PKG_CHECK_MODULES(QT5, Qt5Core >= 5.0, > Qt5Network >= 5.0,' > Might there be something wrong in my environment, wrong version of something > (e.g. I have automake 1.16.1-4) > > Attached my console log output and config.log file. > > Current commit: > commit 4c847372eb9af8ec0b21ace31840eaabfdf32660 (HEAD -> master, > origin/master, origin/HEAD) > Author: guozhu cheng > Date: Mon Jul 15 19:46:25 2019 +0800 > THRIFT-4908: remove reader in Golang's TBinaryProtocol > > Client: go > > This closes #1831. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (THRIFT-4910) ./configure: line 14116: syntax error near unexpected token `QT5,'
[ https://issues.apache.org/jira/browse/THRIFT-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891551#comment-16891551 ] James E. King III edited comment on THRIFT-4910 at 7/24/19 2:53 AM: I do not have any problems using Disco other than OCaml and Swift languages had to be disabled in the docker image in order to build / bootstrap / configure. See [https://github.com/apache/thrift/commit/90a044659878f3581aba922dbde1ed4bd7918678] For information about using the docker build containers: [https://github.com/apache/thrift/blob/master/build/docker/README.md] was (Author: jking3): I do not have any problems using Disco other than OCaml and Swift languages had to be disabled in the docker image in order to build / bootstrap / configure. See https://github.com/apache/thrift/commit/90a044659878f3581aba922dbde1ed4bd7918678 > ./configure: line 14116: syntax error near unexpected token `QT5,' > -- > > Key: THRIFT-4910 > URL: https://issues.apache.org/jira/browse/THRIFT-4910 > Project: Thrift > Issue Type: Question > Components: Build Process >Affects Versions: 0.13.0 > Environment: Ubuntu 19.04 >Reporter: Rocco Corsi >Priority: Minor > Attachments: config.log, configure.out.txt, console.txt, > console_20190723_1436.txt > > > Testing build of latest master branch on Ubuntu 19.04 > Failing on configure > ... > checking whether yytext is a pointer... yes > checking whether ln -s works... yes > checking for gawk... (cached) mawk > checking for ranlib... (cached) ranlib > checking whether g++ supports C++11 features with -std=c++11... yes > ./configure: line 14116: syntax error near unexpected token `QT5,' > ./configure: line 14116: ` PKG_CHECK_MODULES(QT5, Qt5Core >= 5.0, > Qt5Network >= 5.0,' > Might there be something wrong in my environment, wrong version of something > (e.g. I have automake 1.16.1-4) > > Attached my console log output and config.log file. > > Current commit: > commit 4c847372eb9af8ec0b21ace31840eaabfdf32660 (HEAD -> master, > origin/master, origin/HEAD) > Author: guozhu cheng > Date: Mon Jul 15 19:46:25 2019 +0800 > THRIFT-4908: remove reader in Golang's TBinaryProtocol > > Client: go > > This closes #1831. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-4910) ./configure: line 14116: syntax error near unexpected token `QT5,'
[ https://issues.apache.org/jira/browse/THRIFT-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891551#comment-16891551 ] James E. King III commented on THRIFT-4910: --- I do not have any problems using Disco other than OCaml and Swift languages had to be disabled in the docker image in order to build / bootstrap / configure. See https://github.com/apache/thrift/commit/90a044659878f3581aba922dbde1ed4bd7918678 > ./configure: line 14116: syntax error near unexpected token `QT5,' > -- > > Key: THRIFT-4910 > URL: https://issues.apache.org/jira/browse/THRIFT-4910 > Project: Thrift > Issue Type: Question > Components: Build Process >Affects Versions: 0.13.0 > Environment: Ubuntu 19.04 >Reporter: Rocco Corsi >Priority: Minor > Attachments: config.log, configure.out.txt, console.txt, > console_20190723_1436.txt > > > Testing build of latest master branch on Ubuntu 19.04 > Failing on configure > ... > checking whether yytext is a pointer... yes > checking whether ln -s works... yes > checking for gawk... (cached) mawk > checking for ranlib... (cached) ranlib > checking whether g++ supports C++11 features with -std=c++11... yes > ./configure: line 14116: syntax error near unexpected token `QT5,' > ./configure: line 14116: ` PKG_CHECK_MODULES(QT5, Qt5Core >= 5.0, > Qt5Network >= 5.0,' > Might there be something wrong in my environment, wrong version of something > (e.g. I have automake 1.16.1-4) > > Attached my console log output and config.log file. > > Current commit: > commit 4c847372eb9af8ec0b21ace31840eaabfdf32660 (HEAD -> master, > origin/master, origin/HEAD) > Author: guozhu cheng > Date: Mon Jul 15 19:46:25 2019 +0800 > THRIFT-4908: remove reader in Golang's TBinaryProtocol > > Client: go > > This closes #1831. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-4910) ./configure: line 14116: syntax error near unexpected token `QT5,'
[ https://issues.apache.org/jira/browse/THRIFT-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891523#comment-16891523 ] James E. King III commented on THRIFT-4910: --- Was this from a git clone of github apache/thrift master? Did you run ./bootstrap.sh to rebuild the configure script? Let me quickly make an ubuntu-disco docker image to see what's going on. > ./configure: line 14116: syntax error near unexpected token `QT5,' > -- > > Key: THRIFT-4910 > URL: https://issues.apache.org/jira/browse/THRIFT-4910 > Project: Thrift > Issue Type: Question > Components: Build Process >Affects Versions: 0.13.0 > Environment: Ubuntu 19.04 >Reporter: Rocco Corsi >Priority: Minor > Attachments: config.log, configure.out.txt, console.txt, > console_20190723_1436.txt > > > Testing build of latest master branch on Ubuntu 19.04 > Failing on configure > ... > checking whether yytext is a pointer... yes > checking whether ln -s works... yes > checking for gawk... (cached) mawk > checking for ranlib... (cached) ranlib > checking whether g++ supports C++11 features with -std=c++11... yes > ./configure: line 14116: syntax error near unexpected token `QT5,' > ./configure: line 14116: ` PKG_CHECK_MODULES(QT5, Qt5Core >= 5.0, > Qt5Network >= 5.0,' > Might there be something wrong in my environment, wrong version of something > (e.g. I have automake 1.16.1-4) > > Attached my console log output and config.log file. > > Current commit: > commit 4c847372eb9af8ec0b21ace31840eaabfdf32660 (HEAD -> master, > origin/master, origin/HEAD) > Author: guozhu cheng > Date: Mon Jul 15 19:46:25 2019 +0800 > THRIFT-4908: remove reader in Golang's TBinaryProtocol > > Client: go > > This closes #1831. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-4910) ./configure: line 14116: syntax error near unexpected token `QT5,'
[ https://issues.apache.org/jira/browse/THRIFT-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891222#comment-16891222 ] James E. King III commented on THRIFT-4910: --- You should be able to run ./bootstrap.sh and ./configure without qt5. It is an optional C++ component. > ./configure: line 14116: syntax error near unexpected token `QT5,' > -- > > Key: THRIFT-4910 > URL: https://issues.apache.org/jira/browse/THRIFT-4910 > Project: Thrift > Issue Type: Question > Components: Build Process >Affects Versions: 0.13.0 > Environment: Ubuntu 19.04 >Reporter: Rocco Corsi >Priority: Minor > Attachments: config.log, console.txt > > > Testing build of latest master branch on Ubuntu 19.04 > Failing on configure > ... > checking whether yytext is a pointer... yes > checking whether ln -s works... yes > checking for gawk... (cached) mawk > checking for ranlib... (cached) ranlib > checking whether g++ supports C++11 features with -std=c++11... yes > ./configure: line 14116: syntax error near unexpected token `QT5,' > ./configure: line 14116: ` PKG_CHECK_MODULES(QT5, Qt5Core >= 5.0, > Qt5Network >= 5.0,' > Might there be something wrong in my environment, wrong version of something > (e.g. I have automake 1.16.1-4) > > Attached my console log output and config.log file. > > Current commit: > commit 4c847372eb9af8ec0b21ace31840eaabfdf32660 (HEAD -> master, > origin/master, origin/HEAD) > Author: guozhu cheng > Date: Mon Jul 15 19:46:25 2019 +0800 > THRIFT-4908: remove reader in Golang's TBinaryProtocol > > Client: go > > This closes #1831. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-4910) ./configure: line 14116: syntax error near unexpected token `QT5,'
[
https://issues.apache.org/jira/browse/THRIFT-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890896#comment-16890896
]
James E. King III commented on THRIFT-4910:
---
What version of qt5-default do you have?
{noformat}
(dpkg -l | grep qt5){noformat}
> ./configure: line 14116: syntax error near unexpected token `QT5,'
> --
>
> Key: THRIFT-4910
> URL: https://issues.apache.org/jira/browse/THRIFT-4910
> Project: Thrift
> Issue Type: Question
> Components: Build Process
>Affects Versions: 0.13.0
> Environment: Ubuntu 19.04
>Reporter: Rocco Corsi
>Priority: Minor
> Attachments: config.log, console.txt
>
>
> Testing build of latest master branch on Ubuntu 19.04
> Failing on configure
> ...
> checking whether yytext is a pointer... yes
> checking whether ln -s works... yes
> checking for gawk... (cached) mawk
> checking for ranlib... (cached) ranlib
> checking whether g++ supports C++11 features with -std=c++11... yes
> ./configure: line 14116: syntax error near unexpected token `QT5,'
> ./configure: line 14116: ` PKG_CHECK_MODULES(QT5, Qt5Core >= 5.0,
> Qt5Network >= 5.0,'
> Might there be something wrong in my environment, wrong version of something
> (e.g. I have automake 1.16.1-4)
>
> Attached my console log output and config.log file.
>
> Current commit:
> commit 4c847372eb9af8ec0b21ace31840eaabfdf32660 (HEAD -> master,
> origin/master, origin/HEAD)
> Author: guozhu cheng
> Date: Mon Jul 15 19:46:25 2019 +0800
> THRIFT-4908: remove reader in Golang's TBinaryProtocol
>
> Client: go
>
> This closes #1831.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-3165) Disable unsafe TLSv1.0 and TLSv1.1 by default
[
https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-3165:
--
Labels: Breaking-Change SSL SSLSocketFactory Security TLS (was: SSL
SSLSocketFactory Security TLS)
> Disable unsafe TLSv1.0 and TLSv1.1 by default
> -
>
> Key: THRIFT-3165
> URL: https://issues.apache.org/jira/browse/THRIFT-3165
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: James E. King III
>Assignee: James E. King III
>Priority: Major
> Labels: Breaking-Change, SSL, SSLSocketFactory, Security, TLS
>
> Thrift provides an SSL implementation and implements some best practices (for
> example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
> library to control the protocol negotiation is unnecessarily complex.
> The current behavior is to use an enumeration to set the protocol level. The
> methods these call are deprecated in OpenSSL 1.1 and do not provide the
> desired control.
> The proposed new behavior is to:
> * Remove SSLProtocol
> * Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
> disable certain behaviors, like negotiation protocol levels.
> For example the following SSLContext subclass will allow connections at
> TLSv1.1 or later, whereas the default will only allow TLSv1.2 or later:
> {noformat}
> class CustomSSLContext : public SSLContext
> {
> public:
> CustomSSLContext() : SSLContext()
> {
> // SSLContext disables SSLv2, SSLv3, TLSv1_0, and TLSv1_1
> SSL_CTX_clear_options(get(), SSL_OP_NO_TLSv1_1);
> }
> };
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Issue Comment Deleted] (THRIFT-3165) Disable unsafe TLSv1.0 and TLSv1.1 by default
[
https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-3165:
--
Comment: was deleted
(was: Security moves along, and that made our title less than useful. It was:
Improve SSL Security in thrift by requiring TLS v1.2 by default
However really what we want to do is let the consumer control this.
In most languages we already disable SSLv2 and SSLv3.
Best practices now recommend only allowing TLSv1_3 or later, however Thrift
allows TLSv1_0 or later.
I modified the TSSLSocket code in C++ to eliminate SSLProtocol. If someone
wants to control the negotiation they need to subclass SSLContext and set the
options themselves, otherwise we'll be forever updating TSSLSocket with
protocol enhancements.)
> Disable unsafe TLSv1.0 and TLSv1.1 by default
> -
>
> Key: THRIFT-3165
> URL: https://issues.apache.org/jira/browse/THRIFT-3165
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: James E. King III
>Assignee: James E. King III
>Priority: Major
> Labels: SSL, SSLSocketFactory, Security, TLS
>
> Thrift provides an SSL implementation and implements some best practices (for
> example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
> library to control the protocol negotiation is unnecessarily complex.
> The current behavior is to use an enumeration to set the protocol level. The
> methods these call are deprecated in OpenSSL 1.1 and do not provide the
> desired control.
> The proposed new behavior is to:
> * Remove SSLProtocol
> * Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
> disable certain behaviors, like negotiation protocol levels.
> For example the following SSLContext subclass will allow connections at
> TLSv1.1 or later, whereas the default will only allow TLSv1.2 or later:
> {noformat}
> class CustomSSLContext : public SSLContext
> {
> public:
> CustomSSLContext() : SSLContext()
> {
> // SSLContext disables SSLv2, SSLv3, TLSv1_0, and TLSv1_1
> SSL_CTX_clear_options(get(), SSL_OP_NO_TLSv1_1);
> }
> };
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (THRIFT-3165) Disable unsafe TLSv1.0 and TLSv1.1 by default
[
https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III reassigned THRIFT-3165:
-
Assignee: James E. King III
> Disable unsafe TLSv1.0 and TLSv1.1 by default
> -
>
> Key: THRIFT-3165
> URL: https://issues.apache.org/jira/browse/THRIFT-3165
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: James E. King III
>Assignee: James E. King III
>Priority: Major
> Labels: SSL, SSLSocketFactory, Security, TLS
>
> Thrift provides an SSL implementation and implements some best practices (for
> example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
> library to control the protocol negotiation is unnecessarily complex.
> The current behavior is to use an enumeration to set the protocol level. The
> methods these call are deprecated in OpenSSL 1.1 and do not provide the
> desired control.
> The proposed new behavior is to:
> * Remove SSLProtocol
> * Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
> disable certain behaviors, like negotiation protocol levels.
> For example the following SSLContext subclass will allow connections at
> TLSv1.1 or later, whereas the default will only allow TLSv1.2 or later:
> {noformat}
> class CustomSSLContext : public SSLContext
> {
> public:
> CustomSSLContext() : SSLContext()
> {
> // SSLContext disables SSLv2, SSLv3, TLSv1_0, and TLSv1_1
> SSL_CTX_clear_options(get(), SSL_OP_NO_TLSv1_1);
> }
> };
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-3165) Disable unsafe TLSv1.0 and TLSv1.1 by default
[
https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-3165:
--
Description:
Thrift provides an SSL implementation and implements some best practices (for
example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
library to control the protocol negotiation is unnecessarily complex.
The current behavior is to use an enumeration to set the protocol level. The
methods these call are deprecated in OpenSSL 1.1 and do not provide the desired
control.
The proposed new behavior is to:
* Remove SSLProtocol
* Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
disable certain behaviors, like negotiation protocol levels.
For example the following SSLContext subclass will allow connections at TLSv1.1
or later, whereas the default will only allow TLSv1.2 or later:
{noformat}
class CustomSSLContext : public SSLContext
{
public:
CustomSSLContext() : SSLContext()
{
// SSLContext disables SSLv2, SSLv3, TLSv1_0, and TLSv1_1
SSL_CTX_clear_options(get(), SSL_OP_NO_TLSv1_1);
}
};
{noformat}
was:
Thrift provides an SSL implementation and implements some best practices (for
example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
library to control the protocol negotiation is unnecessarily complex.
The current behavior is to use an enumeration to set the protocol level. The
methods these call are deprecated in OpenSSL 1.1 and do not provide the desired
control.
The proposed new behavior is to:
* Remove SSLProtocol
* Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
disable certain behaviors, like negotiation protocol levels.
For example the following SSLContext subclass will ensure connections are at
TLSv1_2 or later:
{noformat}
class SSLContextOnlyTLSv12OrLater : public SSLContext
{
public:
SSLContextOnlyTLSv12OrLater() : SSLContext()
{
// SSLContext already disables SSLv2 and SSLv3
SSL_CTX_set_options(get(), SSL_OP_NO_TLSv1); // This is TLSv1_0
SSL_CTX_set_options(get(), SSL_OP_NO_TLSv1_1);
}
};
{noformat}
> Disable unsafe TLSv1.0 and TLSv1.1 by default
> -
>
> Key: THRIFT-3165
> URL: https://issues.apache.org/jira/browse/THRIFT-3165
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: James E. King III
>Priority: Major
> Labels: SSL, SSLSocketFactory, Security, TLS
>
> Thrift provides an SSL implementation and implements some best practices (for
> example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
> library to control the protocol negotiation is unnecessarily complex.
> The current behavior is to use an enumeration to set the protocol level. The
> methods these call are deprecated in OpenSSL 1.1 and do not provide the
> desired control.
> The proposed new behavior is to:
> * Remove SSLProtocol
> * Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
> disable certain behaviors, like negotiation protocol levels.
> For example the following SSLContext subclass will allow connections at
> TLSv1.1 or later, whereas the default will only allow TLSv1.2 or later:
> {noformat}
> class CustomSSLContext : public SSLContext
> {
> public:
> CustomSSLContext() : SSLContext()
> {
> // SSLContext disables SSLv2, SSLv3, TLSv1_0, and TLSv1_1
> SSL_CTX_clear_options(get(), SSL_OP_NO_TLSv1_1);
> }
> };
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-3165) Disable unsafe TLSv1.0 and TLSv1.1 by default
[
https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-3165:
--
Summary: Disable unsafe TLSv1.0 and TLSv1.1 by default (was: Remove
TSSLSocket::SSLProtocol and require subclass of SSLContext to control TLS
negotiation)
> Disable unsafe TLSv1.0 and TLSv1.1 by default
> -
>
> Key: THRIFT-3165
> URL: https://issues.apache.org/jira/browse/THRIFT-3165
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: James E. King III
>Priority: Major
> Labels: SSL, SSLSocketFactory, Security, TLS
>
> Thrift provides an SSL implementation and implements some best practices (for
> example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
> library to control the protocol negotiation is unnecessarily complex.
> The current behavior is to use an enumeration to set the protocol level. The
> methods these call are deprecated in OpenSSL 1.1 and do not provide the
> desired control.
> The proposed new behavior is to:
> * Remove SSLProtocol
> * Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
> disable certain behaviors, like negotiation protocol levels.
> For example the following SSLContext subclass will ensure connections are at
> TLSv1_2 or later:
> {noformat}
> class SSLContextOnlyTLSv12OrLater : public SSLContext
> {
> public:
> SSLContextOnlyTLSv12OrLater() : SSLContext()
> {
> // SSLContext already disables SSLv2 and SSLv3
> SSL_CTX_set_options(get(), SSL_OP_NO_TLSv1); // This is TLSv1_0
> SSL_CTX_set_options(get(), SSL_OP_NO_TLSv1_1);
> }
> };
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-3165) Remove TSSLSocket::SSLProtocol and require subclass of SSLContext to control TLS negotiation
[
https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-3165:
--
Description:
Thrift provides an SSL implementation and implements some best practices (for
example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
library to control the protocol negotiation is unnecessarily complex.
The current behavior is to use an enumeration to set the protocol level. The
methods these call are deprecated in OpenSSL 1.1 and do not provide the desired
control.
The proposed new behavior is to:
* Remove SSLProtocol
* Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
disable certain behaviors, like negotiation protocol levels.
For example the following SSLContext subclass will ensure connections are at
TLSv1_2 or later:
{noformat}
class SSLContextOnlyTLSv12OrLater : public SSLContext
{
public:
SSLContextOnlyTLSv12OrLater() : SSLContext()
{
// SSLContext already disables SSLv2 and SSLv3
SSL_CTX_set_options(get(), SSL_OP_NO_TLSv1); // This is TLSv1_0
SSL_CTX_set_options(get(), SSL_OP_NO_TLSv1_1);
}
};
{noformat}
was:
Thrift provides an SSL implementation and implements some best practices (for
example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
library to control the protocol negotiation is unnecessarily complex.
The current behavior is to use an enumeration to set the protocol level. The
methods these call are deprecated in OpenSSL 1.1 and do not provide the desired
control.
The proposed new behavior is to:
* Remove SSLProtocol
* Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
disable certain behaviors, like negotiation protocol levels.
For example the following SSLContext subclass will ensure connections are at
TLSv1_2 or later:
{noformat}
class SSLContextOnlyTLSv12OrLater : public SSLContext
{
public:
SSLContextOnlyTLSv12OrLater() : SSLContext()
{
// SSLContext already disables SSLv2 and SSLv3
SSL_CTX_set_options(ctx_, SSL_OP_NO_TLSv1); // This is TLSv1_0
SSL_CTX_set_options(ctx_, SSL_OP_NO_TLSv1_1);
}
};
{noformat}
> Remove TSSLSocket::SSLProtocol and require subclass of SSLContext to control
> TLS negotiation
>
>
> Key: THRIFT-3165
> URL: https://issues.apache.org/jira/browse/THRIFT-3165
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: James E. King III
>Priority: Major
> Labels: SSL, SSLSocketFactory, Security, TLS
>
> Thrift provides an SSL implementation and implements some best practices (for
> example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
> library to control the protocol negotiation is unnecessarily complex.
> The current behavior is to use an enumeration to set the protocol level. The
> methods these call are deprecated in OpenSSL 1.1 and do not provide the
> desired control.
> The proposed new behavior is to:
> * Remove SSLProtocol
> * Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
> disable certain behaviors, like negotiation protocol levels.
> For example the following SSLContext subclass will ensure connections are at
> TLSv1_2 or later:
> {noformat}
> class SSLContextOnlyTLSv12OrLater : public SSLContext
> {
> public:
> SSLContextOnlyTLSv12OrLater() : SSLContext()
> {
> // SSLContext already disables SSLv2 and SSLv3
> SSL_CTX_set_options(get(), SSL_OP_NO_TLSv1); // This is TLSv1_0
> SSL_CTX_set_options(get(), SSL_OP_NO_TLSv1_1);
> }
> };
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-3165) Remove TSSLSocket::SSLProtocol and require subclass of SSLContext to control TLS negotiation
[
https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-3165:
--
Description:
Thrift provides an SSL implementation and implements some best practices (for
example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
library to control the protocol negotiation is unnecessarily complex.
The current behavior is to use an enumeration to set the protocol level. The
methods these call are deprecated in OpenSSL 1.1 and do not provide the desired
control.
The proposed new behavior is to:
* Remove SSLProtocol
* Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
disable certain behaviors, like negotiation protocol levels.
For example the following SSLContext subclass will ensure connections are at
TLSv1_2 or later:
{noformat}
class SSLContextOnlyTLSv12OrLater : public SSLContext
{
public:
SSLContextOnlyTLSv12OrLater() : SSLContext()
{
// SSLContext already disables SSLv2 and SSLv3
SSL_CTX_set_options(ctx_, SSL_OP_NO_TLSv1); // This is TLSv1_0
SSL_CTX_set_options(ctx_, SSL_OP_NO_TLSv1_1);
}
};
{noformat}
was:
Thrift provides an SSL implementation and as such we need to ensure that thrift
as a distribution is not the source of a security risk. Currently there is no
uniformity across the library implementations to require a certain level of
security for SSL communications.
It is therefore proposed that the Thrift project require all SSL
implementations shipping with the distribution to require TLS 1.2 or later as
the accepted ciphers for a server socket. TLS 1.2 was defined in RFC 5246 in
August of 2008.
By shipping thrift with anything less, the finger can potentially be pointed
back at thrift as a project for not providing the proper security. By setting
the bar as high as possible on components in the package, the third party using
Thrift must make a conscious decision to add other ciphers that are not as
strong as TLS 1.2. Since the third party is making this decision, they are
fully accepting the consequences of their action.
Given this affects all SSL implementations, it could be done in one commit or
in multiple commits; if the work is to be split up then it should be done with
subtasks in Jira.
> Remove TSSLSocket::SSLProtocol and require subclass of SSLContext to control
> TLS negotiation
>
>
> Key: THRIFT-3165
> URL: https://issues.apache.org/jira/browse/THRIFT-3165
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: James E. King III
>Priority: Major
> Labels: SSL, SSLSocketFactory, Security, TLS
>
> Thrift provides an SSL implementation and implements some best practices (for
> example, SSLv2 and SSLv3 are disabled). The current mechanism in the C++
> library to control the protocol negotiation is unnecessarily complex.
> The current behavior is to use an enumeration to set the protocol level. The
> methods these call are deprecated in OpenSSL 1.1 and do not provide the
> desired control.
> The proposed new behavior is to:
> * Remove SSLProtocol
> * Require the consumer to subclass SSLContext and call SSL_CTX_set_option to
> disable certain behaviors, like negotiation protocol levels.
> For example the following SSLContext subclass will ensure connections are at
> TLSv1_2 or later:
> {noformat}
> class SSLContextOnlyTLSv12OrLater : public SSLContext
> {
> public:
> SSLContextOnlyTLSv12OrLater() : SSLContext()
> {
> // SSLContext already disables SSLv2 and SSLv3
> SSL_CTX_set_options(ctx_, SSL_OP_NO_TLSv1); // This is TLSv1_0
> SSL_CTX_set_options(ctx_, SSL_OP_NO_TLSv1_1);
> }
> };
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (THRIFT-3165) Remove TSSLSocket::SSLProtocol and require subclass of SSLContext to control TLS negotiation
[ https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-3165: -- Component/s: (was: Wish List) C++ - Library > Remove TSSLSocket::SSLProtocol and require subclass of SSLContext to control > TLS negotiation > > > Key: THRIFT-3165 > URL: https://issues.apache.org/jira/browse/THRIFT-3165 > Project: Thrift > Issue Type: Improvement > Components: C++ - Library >Affects Versions: 0.9.2 >Reporter: James E. King III >Priority: Major > Labels: SSL, SSLSocketFactory, Security, TLS > > Thrift provides an SSL implementation and as such we need to ensure that > thrift as a distribution is not the source of a security risk. Currently > there is no uniformity across the library implementations to require a > certain level of security for SSL communications. > It is therefore proposed that the Thrift project require all SSL > implementations shipping with the distribution to require TLS 1.2 or later as > the accepted ciphers for a server socket. TLS 1.2 was defined in RFC 5246 in > August of 2008. > By shipping thrift with anything less, the finger can potentially be pointed > back at thrift as a project for not providing the proper security. By > setting the bar as high as possible on components in the package, the third > party using Thrift must make a conscious decision to add other ciphers that > are not as strong as TLS 1.2. Since the third party is making this decision, > they are fully accepting the consequences of their action. > Given this affects all SSL implementations, it could be done in one commit or > in multiple commits; if the work is to be split up then it should be done > with subtasks in Jira. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-3165) Improve SSL Security in thrift by requiring TLS v1.2 by default
[ https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886609#comment-16886609 ] James E. King III commented on THRIFT-3165: --- Security moves along, and that made our title less than useful. It was: Improve SSL Security in thrift by requiring TLS v1.2 by default However really what we want to do is let the consumer control this. In most languages we already disable SSLv2 and SSLv3. Best practices now recommend only allowing TLSv1_3 or later, however Thrift allows TLSv1_0 or later. I modified the TSSLSocket code in C++ to eliminate SSLProtocol. If someone wants to control the negotiation they need to subclass SSLContext and set the options themselves, otherwise we'll be forever updating TSSLSocket with protocol enhancements. > Improve SSL Security in thrift by requiring TLS v1.2 by default > --- > > Key: THRIFT-3165 > URL: https://issues.apache.org/jira/browse/THRIFT-3165 > Project: Thrift > Issue Type: Improvement > Components: Wish List >Affects Versions: 0.9.2 >Reporter: James E. King III >Priority: Major > Labels: SSL, SSLSocketFactory, Security, TLS > > Thrift provides an SSL implementation and as such we need to ensure that > thrift as a distribution is not the source of a security risk. Currently > there is no uniformity across the library implementations to require a > certain level of security for SSL communications. > It is therefore proposed that the Thrift project require all SSL > implementations shipping with the distribution to require TLS 1.2 or later as > the accepted ciphers for a server socket. TLS 1.2 was defined in RFC 5246 in > August of 2008. > By shipping thrift with anything less, the finger can potentially be pointed > back at thrift as a project for not providing the proper security. By > setting the bar as high as possible on components in the package, the third > party using Thrift must make a conscious decision to add other ciphers that > are not as strong as TLS 1.2. Since the third party is making this decision, > they are fully accepting the consequences of their action. > Given this affects all SSL implementations, it could be done in one commit or > in multiple commits; if the work is to be split up then it should be done > with subtasks in Jira. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (THRIFT-3165) Remove TSSLSocket::SSLProtocol and require subclass of SSLContext to control TLS negotiation
[ https://issues.apache.org/jira/browse/THRIFT-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-3165: -- Summary: Remove TSSLSocket::SSLProtocol and require subclass of SSLContext to control TLS negotiation (was: Improve SSL Security in thrift by requiring TLS v1.2 by default) > Remove TSSLSocket::SSLProtocol and require subclass of SSLContext to control > TLS negotiation > > > Key: THRIFT-3165 > URL: https://issues.apache.org/jira/browse/THRIFT-3165 > Project: Thrift > Issue Type: Improvement > Components: Wish List >Affects Versions: 0.9.2 >Reporter: James E. King III >Priority: Major > Labels: SSL, SSLSocketFactory, Security, TLS > > Thrift provides an SSL implementation and as such we need to ensure that > thrift as a distribution is not the source of a security risk. Currently > there is no uniformity across the library implementations to require a > certain level of security for SSL communications. > It is therefore proposed that the Thrift project require all SSL > implementations shipping with the distribution to require TLS 1.2 or later as > the accepted ciphers for a server socket. TLS 1.2 was defined in RFC 5246 in > August of 2008. > By shipping thrift with anything less, the finger can potentially be pointed > back at thrift as a project for not providing the proper security. By > setting the bar as high as possible on components in the package, the third > party using Thrift must make a conscious decision to add other ciphers that > are not as strong as TLS 1.2. Since the third party is making this decision, > they are fully accepting the consequences of their action. > Given this affects all SSL implementations, it could be done in one commit or > in multiple commits; if the work is to be split up then it should be done > with subtasks in Jira. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (THRIFT-4907) strong named assemblies wanted
[ https://issues.apache.org/jira/browse/THRIFT-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16882847#comment-16882847 ] James E. King III commented on THRIFT-4907: --- Do the instructions for building need to be updated to add this reserved space? See: https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md > strong named assemblies wanted > -- > > Key: THRIFT-4907 > URL: https://issues.apache.org/jira/browse/THRIFT-4907 > Project: Thrift > Issue Type: Bug > Components: C# - Library, netcore - Library, netstd - Library >Affects Versions: 0.12.0 >Reporter: Benjamin Kraemer >Assignee: Jens Geyer >Priority: Blocker > Fix For: 0.13.0 > > > In THRIFT-2947, a strong name should have been added to > [https://www.nuget.org/packages/ApacheThrift/0.12.0.1] > Looking at the DLL, it's not signed at all. The assembly name is still > `Thrift, Version=0.12.0.0, Culture=neutral, PublicKeyToken=null` and > therefore missing the `PublicKeyToken` part. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (THRIFT-4907) C# code signing not working
[ https://issues.apache.org/jira/browse/THRIFT-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III reassigned THRIFT-4907: - Assignee: Jens Geyer > C# code signing not working > --- > > Key: THRIFT-4907 > URL: https://issues.apache.org/jira/browse/THRIFT-4907 > Project: Thrift > Issue Type: Bug > Components: Build Process, C# - Library, netcore - Library >Affects Versions: 0.12.0 >Reporter: Benjamin Kraemer >Assignee: Jens Geyer >Priority: Blocker > Fix For: 0.13.0 > > > In THRIFT-2947, a strong name should have been added to > [https://www.nuget.org/packages/ApacheThrift/0.12.0.1] > Looking at the DLL, it's not signed at all. The assembly name is still > `Thrift, Version=0.12.0.0, Culture=neutral, PublicKeyToken=null` and > therefore missing the `PublicKeyToken` part. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (THRIFT-4907) C# code signing not working
[ https://issues.apache.org/jira/browse/THRIFT-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4907: -- Fix Version/s: 0.13.0 > C# code signing not working > --- > > Key: THRIFT-4907 > URL: https://issues.apache.org/jira/browse/THRIFT-4907 > Project: Thrift > Issue Type: Bug > Components: Build Process, C# - Library, netcore - Library >Affects Versions: 0.12.0 >Reporter: Benjamin Kraemer >Priority: Blocker > Fix For: 0.13.0 > > > In THRIFT-2947, a strong name should have been added to > [https://www.nuget.org/packages/ApacheThrift/0.12.0.1] > Looking at the DLL, it's not signed at all. The assembly name is still > `Thrift, Version=0.12.0.0, Culture=neutral, PublicKeyToken=null` and > therefore missing the `PublicKeyToken` part. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4849) Do not Ignore InterruptedException
[
https://issues.apache.org/jira/browse/THRIFT-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III resolved THRIFT-4849.
---
Resolution: Fixed
Assignee: James E. King III
Fix Version/s: 0.13.0
> Do not Ignore InterruptedException
> --
>
> Key: THRIFT-4849
> URL: https://issues.apache.org/jira/browse/THRIFT-4849
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Library
>Affects Versions: 0.12.0
>Reporter: David Mollitor
>Assignee: James E. King III
>Priority: Minor
> Fix For: 0.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> } catch (InterruptedException e) {
> // for now, just silently ignore. technically this means we'll have
> less of
> // a graceful shutdown as a result.
> }
> {code}
> https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TNonblockingServer.java#L88-L91
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (THRIFT-4844) createConnection ignores connect_timeout option
[ https://issues.apache.org/jira/browse/THRIFT-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4844. --- Resolution: Fixed Assignee: James E. King III Fix Version/s: 0.13.0 > createConnection ignores connect_timeout option > --- > > Key: THRIFT-4844 > URL: https://issues.apache.org/jira/browse/THRIFT-4844 > Project: Thrift > Issue Type: Bug > Components: Node.js - Library >Affects Versions: 0.12.0 >Reporter: Filippo Malaguti >Assignee: James E. King III >Priority: Major > Fix For: 0.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > connect_timeout and timeout options passed to createConnection are ignored > during first connection attempt. > Checking the source code, connect_timeout seems to be used only during > reconnection retries, while timeout is applied to underlying socket only > after the connect event. > Probably it whould be better to pass the connection timeout directy to the > net.createConnection call. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4805) Suppress excessive logging of SASL TTransportExceptions in case of END_OF_FILE
[
https://issues.apache.org/jira/browse/THRIFT-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III resolved THRIFT-4805.
---
Resolution: Fixed
Fix Version/s: 0.13.0
> Suppress excessive logging of SASL TTransportExceptions in case of
> END_OF_FILE
> ---
>
> Key: THRIFT-4805
> URL: https://issues.apache.org/jira/browse/THRIFT-4805
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.12.0
>Reporter: Mithun Radhakrishnan
>Assignee: Mithun Radhakrishnan
>Priority: Major
> Labels: Breaking-Change
> Fix For: 0.13.0
>
> Attachments: THRIFT-4805.1.patch, THRIFT-4805.bonus.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This has to do with the fix checked in for THRIFT-3769 and THRIFT-2268, which
> was to mute the noise from {{TSaslTransportExceptions}} raised from
> load-balancer health-checks for Thrift services, such as the Hive metastore.
> Please consider [the code in
> TThreadPoolServer::run()|https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TThreadPoolServer.java#L322]:
> {code:java|title=TThreadPoolServer.java}
> } catch (TException tx) {
> LOGGER.error("Thrift error occurred during processing of message.",
> tx);
> } catch (Exception x) {
> // We'll usually receive RuntimeException types here
> // Need to unwrap to ascertain real causing exception before we
> choose to ignore
> Throwable realCause = x.getCause();
> // Ignore err-logging all transport-level/type exceptions
> if ((realCause != null && realCause instanceof TTransportException)
> || (x instanceof TTransportException)) {
> LOGGER.debug(
> "Received TTransportException during processing of message.
> Ignoring.",
> x);
> } else {
> // Log the exception at error level and continue
> LOGGER.error("Error occurred during processing of message.", x);
> }
> } finally {...}
> {code}
> The logic here is solid for {{RuntimeExceptions}} that wrap
> {{TTansportExceptions}}. But it slips up on handling the condition being
> checked for at
> [line#323|https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TThreadPoolServer.java#L323],
> i.e.:
> {code:java|title=TThreadPoolServer.java}
> || (x instanceof TTransportException)) {
> {code}
> The {{catch (Exception x)}} comes *after* the {{catch (TException tx)}}, so
> it's a guarantee that {{!(x instanceof TTransportException)}}. When a
> {{TTransportException}} (or {{TSaslTransportException}}) is thrown, it will
> be caught in the first catch block, and logged. This rather defeats the
> purpose of the fix. The error manifests with the following stack-trace
> filling up my logs:
> {noformat}
> org.apache.thrift.transport.TTransportException
> at
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
> at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
> at
> org.apache.thrift.transport.TSaslTransport.readLength(TSaslTransport.java:374)
> at
> org.apache.thrift.transport.TSaslTransport.readFrame(TSaslTransport.java:451)
> at
> org.apache.thrift.transport.TSaslTransport.read(TSaslTransport.java:433)
> at
> org.apache.thrift.transport.TSaslServerTransport.read(TSaslServerTransport.java:43)
> at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
> at
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
> at
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
> at
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:27)
> at
> org.apache.hive.service.cli.thrift.ThriftCLIMetricsProcessor.process(ThriftCLIMetricsProcessor.java:63)
> at
> org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingProcessor$2.run(HadoopThriftAuthBridge.java:777)
> at
> org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingProcessor$2.run(HadoopThriftAuthBridge.java:773)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1953)
> at
> org.apache.hadoop.hive.thrift.HadoopThriftAuthBridge$Server$TUGIAssumingProcessor.process(HadoopThriftAuthBridge.java:773)
> at
>
[jira] [Resolved] (THRIFT-4902) Swift compatibility with Swift 4.2, 5.0 and 5.1
[ https://issues.apache.org/jira/browse/THRIFT-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4902. --- Resolution: Fixed Assignee: James E. King III Fix Version/s: 0.13.0 > Swift compatibility with Swift 4.2, 5.0 and 5.1 > --- > > Key: THRIFT-4902 > URL: https://issues.apache.org/jira/browse/THRIFT-4902 > Project: Thrift > Issue Type: Improvement > Components: Swift - Library >Reporter: Antoine Cœur >Assignee: James E. King III >Priority: Minor > Fix For: 0.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > It was reported on Stack Overflow > ([https://stackoverflow.com/questions/56841613/how-to-import-thrift-0-12-into-xcode-to-support-swift-4-2]) > that Thrift doesn't work on Swift 4.2. I was able to confirmed that issue, > so I made a pull request to solve the problem: > [https://github.com/apache/thrift/pull/1827] > The pull request keeps compatibility with Swift 3 (which is deprecated and > won't be usable at all on macOS Catalina), and adds support to Swift 4.0, > 4.2, 5.0 and 5.1. > Related: THRIFT-4547. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (THRIFT-4905) Thrift D experimental async ssl hangs during tests
James E. King III created THRIFT-4905: - Summary: Thrift D experimental async ssl hangs during tests Key: THRIFT-4905 URL: https://issues.apache.org/jira/browse/THRIFT-4905 Project: Thrift Issue Type: Bug Components: D - Library Affects Versions: 0.12.0 Environment: ubuntu-bionic docker build environment Reporter: James E. King III While running the tests in Travis CI or locally in the docker build container under 2.083.1 or 2.086.1 I see the "async_test --ssl" test hang and never come back. A read of the async ssl code headers indicates it is experimental and "may not be safe". I had to begrudgingly disable this test to allow the CI builds to complete. Someone needs to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (THRIFT-4904) Python TSocket read() and write() allow low level exceptions to escape
[ https://issues.apache.org/jira/browse/THRIFT-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III reassigned THRIFT-4904: - Assignee: James E. King III > Python TSocket read() and write() allow low level exceptions to escape > -- > > Key: THRIFT-4904 > URL: https://issues.apache.org/jira/browse/THRIFT-4904 > Project: Thrift > Issue Type: Bug > Components: Python - Library >Affects Versions: 0.12.0 >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > > The calls to socket send() and recv() inside write() and read() were allowing > exceptions to escape: > - OSError > - socket.error > - ssl.Error > These need to be captured and translated to an appropriate > TTransportException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (THRIFT-4904) Python TSocket read() and write() allow low level exceptions to escape
James E. King III created THRIFT-4904: - Summary: Python TSocket read() and write() allow low level exceptions to escape Key: THRIFT-4904 URL: https://issues.apache.org/jira/browse/THRIFT-4904 Project: Thrift Issue Type: Bug Components: Python - Library Affects Versions: 0.12.0 Reporter: James E. King III The calls to socket send() and recv() inside write() and read() were allowing exceptions to escape: - OSError - socket.error - ssl.Error These need to be captured and translated to an appropriate TTransportException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (THRIFT-4903) erlang cross test server insanity test may not be correct
James E. King III created THRIFT-4903: - Summary: erlang cross test server insanity test may not be correct Key: THRIFT-4903 URL: https://issues.apache.org/jira/browse/THRIFT-4903 Project: Thrift Issue Type: Bug Components: Erlang - Library Affects Versions: 0.12.0 Environment: Using the ubuntu-bionic docker build environment with Erlang 22 in it. Reporter: James E. King III When doing "make precross" in test/erl I see these warnings: ``` src/test_thrift_server.erl:163: Warning: variable 'Hello' is unused src/test_thrift_server.erl:172: Warning: variable 'Crazy' is unused src/test_thrift_server.erl:172: Warning: a term is constructed, but never used src/test_thrift_server.erl:174: Warning: a term is constructed, but never used ``` Looking at the code, I would say that either these things are not supposed to exist or the test is not complete. Could someone look at which it is and correct it? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4830) Add to_string function for enum in C++ file generate
[ https://issues.apache.org/jira/browse/THRIFT-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4830. --- Resolution: Fixed Assignee: James E. King III Fix Version/s: 0.13.0 > Add to_string function for enum in C++ file generate > > > Key: THRIFT-4830 > URL: https://issues.apache.org/jira/browse/THRIFT-4830 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler >Reporter: Seyyed Soroosh Hosseinalipour >Assignee: James E. King III >Priority: Minor > Labels: features, performance, usability > Fix For: 0.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > ITNOA > I think it useful and have some performance benefits to generate to_string > function for enum beside of operator<< overloading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4842) Multiplexed protocol has a memory leak in set c_glib
[ https://issues.apache.org/jira/browse/THRIFT-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4842. --- Resolution: Fixed > Multiplexed protocol has a memory leak in set c_glib > > > Key: THRIFT-4842 > URL: https://issues.apache.org/jira/browse/THRIFT-4842 > Project: Thrift > Issue Type: Bug >Affects Versions: 0.12.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar >Priority: Major > Fix For: 0.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The multiplexed protocol is affected by a memory leak in set property in the > c_gllib version when setting the service to be multiplexed. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (THRIFT-4899) Generated TypeScript declarations incorrectly references types when there is more than 1 include
[
https://issues.apache.org/jira/browse/THRIFT-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4899:
--
Component/s: (was: JavaScript - Compiler)
Java - Compiler
> Generated TypeScript declarations incorrectly references types when there is
> more than 1 include
>
>
> Key: THRIFT-4899
> URL: https://issues.apache.org/jira/browse/THRIFT-4899
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.13.0
>Reporter: Phil Price
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a service or type definition has multiple includes that are referenced
> in method parameters or responses the TypeScript generator will generated
> code that will fail to compile with tsc. This is due to "external" types not
> being referenced from their import; an assumption is made that they are
> defined the the default ttypes for the service.
>
> With the following input
> {code:java}
> import "Other.thrift"
> struct MyStruct {
> 1:Other.OtherType field;
> }
> service MyService {
> Other.OtherResponse magic(1:Other.OtherRequest arg)
> }{code}
> The following generated TypeScript declaration is generated with 0.13.0 which
> will fail to compile with an invocation of "tsc *.d.ts"
> {code:java}
> // foo_types.d.ts
> import other_types = require("./other");
> declare class MyStruct {
> public field: OtherType; // !!! Compile failure, unknown type OtherType
> }
> // foo_service.d.ts
> import other_types = require("./other");
> class MyService {
> public magic(request: OtherRequest) : Promise // !!!
> Compile failure, unknown type OtherRequest, OtherResponse
> }
> {code}
> The expected output *should* be:
> {code:java}
> // foo_types.d.ts
> import other_types = require("./other");
> declare class MyStruct {
> public field: other_types.OtherType;
> }
> // foo_service.d.ts
> import other_types = require("./other");
> class MyService {
> public magic(request: other_types.OtherRequest) :
> Promise
> }
> {code}
> I have a fix for this with the following PR
> [https://github.com/apache/thrift/pull/1820]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (THRIFT-4899) Generated TypeScript declarations incorrectly references types when there is more than 1 include
[
https://issues.apache.org/jira/browse/THRIFT-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III resolved THRIFT-4899.
---
Resolution: Fixed
Assignee: James E. King III
Fix Version/s: 0.13.0
> Generated TypeScript declarations incorrectly references types when there is
> more than 1 include
>
>
> Key: THRIFT-4899
> URL: https://issues.apache.org/jira/browse/THRIFT-4899
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.13.0
>Reporter: Phil Price
>Assignee: James E. King III
>Priority: Major
> Fix For: 0.13.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a service or type definition has multiple includes that are referenced
> in method parameters or responses the TypeScript generator will generated
> code that will fail to compile with tsc. This is due to "external" types not
> being referenced from their import; an assumption is made that they are
> defined the the default ttypes for the service.
>
> With the following input
> {code:java}
> import "Other.thrift"
> struct MyStruct {
> 1:Other.OtherType field;
> }
> service MyService {
> Other.OtherResponse magic(1:Other.OtherRequest arg)
> }{code}
> The following generated TypeScript declaration is generated with 0.13.0 which
> will fail to compile with an invocation of "tsc *.d.ts"
> {code:java}
> // foo_types.d.ts
> import other_types = require("./other");
> declare class MyStruct {
> public field: OtherType; // !!! Compile failure, unknown type OtherType
> }
> // foo_service.d.ts
> import other_types = require("./other");
> class MyService {
> public magic(request: OtherRequest) : Promise // !!!
> Compile failure, unknown type OtherRequest, OtherResponse
> }
> {code}
> The expected output *should* be:
> {code:java}
> // foo_types.d.ts
> import other_types = require("./other");
> declare class MyStruct {
> public field: other_types.OtherType;
> }
> // foo_service.d.ts
> import other_types = require("./other");
> class MyService {
> public magic(request: other_types.OtherRequest) :
> Promise
> }
> {code}
> I have a fix for this with the following PR
> [https://github.com/apache/thrift/pull/1820]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (THRIFT-4896) cpp and c_glib include paths are added to source files when building
[ https://issues.apache.org/jira/browse/THRIFT-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4896. --- Resolution: Fixed Assignee: James E. King III Fix Version/s: 0.13.0 > cpp and c_glib include paths are added to source files when building > > > Key: THRIFT-4896 > URL: https://issues.apache.org/jira/browse/THRIFT-4896 > Project: Thrift > Issue Type: Bug > Components: Build Process >Reporter: Kevin Wojniak >Assignee: James E. King III >Priority: Major > Fix For: 0.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > AM_CPPFLAGS is used by cpp and c_glib. They both add their include > directories to AM_CPPFLAGS. However, since thrift header files names are > generic (e.g. Processor.h) and can be reused per language, like with cpp and > cocoa (as of 0.12), there is possibility for conflict due cpp and cocoa using > same header file names. Automake supports target_CPPFLAGS instead which > appears to limit the compile flags scope. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (THRIFT-4888) TSSLSocket::close() server crash
[
https://issues.apache.org/jira/browse/THRIFT-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4888:
--
Issue Type: Question (was: Bug)
> TSSLSocket::close() server crash
>
>
> Key: THRIFT-4888
> URL: https://issues.apache.org/jira/browse/THRIFT-4888
> Project: Thrift
> Issue Type: Question
> Components: C++ - Library
>Affects Versions: 0.10.0
>Reporter: Vladimir Nevzorov
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> *Client* gets info from the server and terminates succesfully.
> But *Server* crashes when *client* _TBufferedTransport_ calls close().
>
> Client code:
> {code:java}
> int main() {
> std::cout << "C++ client in network mode start..." << std::endl;
> shared_ptr acc_mgr(new AllowAllAccessManager());
> shared_ptr
> ssl_tx_transp_factory(
> new qkd_api_client::SSLSocketTransportFactory(CLIENT_TX_CERT_PATH,
> CLIENT_TX_KEY_PATH,
> TRUSTED_CA_PATH,
> acc_mgr)
> );
> shared_ptr transp_tx(
> new
> TBufferedTransport(ssl_tx_transp_factory->createSocket(TX_SERVER_ADDR,
> SERVER_PORT)));
> auto client_tx =
> qkd_network_api::v1::NetworkApiServiceClient(boost::shared_ptr(new
> TBinaryProtocol(transp_tx)));
> try {
> transp_tx->open();
> qkd_network_api::v1::Info info_tx;
> client_tx.get_by_length(info_tx, 22, 33);
> transp_tx->close()
> ...
> {code}
>
> Server output:
> {code:java}
> write 0x7f2a0992c1cd
> 0x7f2a07d65d05
> BIO_write 0x7f2a07d607cb
> 0x7f2a08165c9b
> 0x7f2a081664d0
> 0x7f2a0816e9b1
> 0x7f2a0816ce05
> SSL_shutdown 0x7f2a081770c9
> apache::thrift::transport::TSSLSocket::close 0x7f2a0842aa51
> apache::thrift::server::TConnectedClient::cleanup 0x7f2a08433196
> apache::thrift::server::TConnectedClient::run 0x7f2a08432d65
> apache::thrift::server::TThreadedServer::TConnectedClientRunner::run
> 0x7f2a0843a5f8
> apache::thrift::concurrency::PthreadThread::threadMain 0x7f2a0843e5ff
> start_thread 0x7f2a099234a4
> clone 0x7f2a051e2d0f
> {code}
>
> If client open() and close() transport without calling interface method -
> server works fine.
>
> {code:c++}
> ...
> transp_tx->open();
> // client_tx.get_by_length(info_tx, 22, 33);
> transp_tx->close()
> ...
> {code}
> When I use python client - all works fine.
>
> Help me, please.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (THRIFT-4888) TSSLSocket::close() server crash
[
https://issues.apache.org/jira/browse/THRIFT-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III resolved THRIFT-4888.
---
Resolution: Information Provided
Assignee: James E. King III
> TSSLSocket::close() server crash
>
>
> Key: THRIFT-4888
> URL: https://issues.apache.org/jira/browse/THRIFT-4888
> Project: Thrift
> Issue Type: Question
> Components: C++ - Library
>Affects Versions: 0.10.0
>Reporter: Vladimir Nevzorov
>Assignee: James E. King III
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> *Client* gets info from the server and terminates succesfully.
> But *Server* crashes when *client* _TBufferedTransport_ calls close().
>
> Client code:
> {code:java}
> int main() {
> std::cout << "C++ client in network mode start..." << std::endl;
> shared_ptr acc_mgr(new AllowAllAccessManager());
> shared_ptr
> ssl_tx_transp_factory(
> new qkd_api_client::SSLSocketTransportFactory(CLIENT_TX_CERT_PATH,
> CLIENT_TX_KEY_PATH,
> TRUSTED_CA_PATH,
> acc_mgr)
> );
> shared_ptr transp_tx(
> new
> TBufferedTransport(ssl_tx_transp_factory->createSocket(TX_SERVER_ADDR,
> SERVER_PORT)));
> auto client_tx =
> qkd_network_api::v1::NetworkApiServiceClient(boost::shared_ptr(new
> TBinaryProtocol(transp_tx)));
> try {
> transp_tx->open();
> qkd_network_api::v1::Info info_tx;
> client_tx.get_by_length(info_tx, 22, 33);
> transp_tx->close()
> ...
> {code}
>
> Server output:
> {code:java}
> write 0x7f2a0992c1cd
> 0x7f2a07d65d05
> BIO_write 0x7f2a07d607cb
> 0x7f2a08165c9b
> 0x7f2a081664d0
> 0x7f2a0816e9b1
> 0x7f2a0816ce05
> SSL_shutdown 0x7f2a081770c9
> apache::thrift::transport::TSSLSocket::close 0x7f2a0842aa51
> apache::thrift::server::TConnectedClient::cleanup 0x7f2a08433196
> apache::thrift::server::TConnectedClient::run 0x7f2a08432d65
> apache::thrift::server::TThreadedServer::TConnectedClientRunner::run
> 0x7f2a0843a5f8
> apache::thrift::concurrency::PthreadThread::threadMain 0x7f2a0843e5ff
> start_thread 0x7f2a099234a4
> clone 0x7f2a051e2d0f
> {code}
>
> If client open() and close() transport without calling interface method -
> server works fine.
>
> {code:c++}
> ...
> transp_tx->open();
> // client_tx.get_by_length(info_tx, 22, 33);
> transp_tx->close()
> ...
> {code}
> When I use python client - all works fine.
>
> Help me, please.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4888) TSSLSocket::close() server crash
[
https://issues.apache.org/jira/browse/THRIFT-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16874875#comment-16874875
]
James E. King III commented on THRIFT-4888:
---
In past projects I have installed a log intercept that ignores certain log
messages like this. Good to hear you figured it out.
> TSSLSocket::close() server crash
>
>
> Key: THRIFT-4888
> URL: https://issues.apache.org/jira/browse/THRIFT-4888
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.10.0
>Reporter: Vladimir Nevzorov
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> *Client* gets info from the server and terminates succesfully.
> But *Server* crashes when *client* _TBufferedTransport_ calls close().
>
> Client code:
> {code:java}
> int main() {
> std::cout << "C++ client in network mode start..." << std::endl;
> shared_ptr acc_mgr(new AllowAllAccessManager());
> shared_ptr
> ssl_tx_transp_factory(
> new qkd_api_client::SSLSocketTransportFactory(CLIENT_TX_CERT_PATH,
> CLIENT_TX_KEY_PATH,
> TRUSTED_CA_PATH,
> acc_mgr)
> );
> shared_ptr transp_tx(
> new
> TBufferedTransport(ssl_tx_transp_factory->createSocket(TX_SERVER_ADDR,
> SERVER_PORT)));
> auto client_tx =
> qkd_network_api::v1::NetworkApiServiceClient(boost::shared_ptr(new
> TBinaryProtocol(transp_tx)));
> try {
> transp_tx->open();
> qkd_network_api::v1::Info info_tx;
> client_tx.get_by_length(info_tx, 22, 33);
> transp_tx->close()
> ...
> {code}
>
> Server output:
> {code:java}
> write 0x7f2a0992c1cd
> 0x7f2a07d65d05
> BIO_write 0x7f2a07d607cb
> 0x7f2a08165c9b
> 0x7f2a081664d0
> 0x7f2a0816e9b1
> 0x7f2a0816ce05
> SSL_shutdown 0x7f2a081770c9
> apache::thrift::transport::TSSLSocket::close 0x7f2a0842aa51
> apache::thrift::server::TConnectedClient::cleanup 0x7f2a08433196
> apache::thrift::server::TConnectedClient::run 0x7f2a08432d65
> apache::thrift::server::TThreadedServer::TConnectedClientRunner::run
> 0x7f2a0843a5f8
> apache::thrift::concurrency::PthreadThread::threadMain 0x7f2a0843e5ff
> start_thread 0x7f2a099234a4
> clone 0x7f2a051e2d0f
> {code}
>
> If client open() and close() transport without calling interface method -
> server works fine.
>
> {code:c++}
> ...
> transp_tx->open();
> // client_tx.get_by_length(info_tx, 22, 33);
> transp_tx->close()
> ...
> {code}
> When I use python client - all works fine.
>
> Help me, please.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4895) Revive Cocoa support and add tests
[ https://issues.apache.org/jira/browse/THRIFT-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870541#comment-16870541 ] James E. King III commented on THRIFT-4895: --- I'm okay to see it come back with activity and folks who can maintain it and move it forward; it's probably something we should have folks vote on since we voted to remove it, just to ensure everyone is aligned. It probably won't make it back into 0.13.0 however since that release cycle is going to start very soon. > Revive Cocoa support and add tests > -- > > Key: THRIFT-4895 > URL: https://issues.apache.org/jira/browse/THRIFT-4895 > Project: Thrift > Issue Type: New Feature > Components: Cocoa - Library, Test Suite >Reporter: Kevin Wojniak >Priority: Major > > I would like to see the Objective-C (Cocoa) support brought back. The > suggestion to use Swift is not valid for all use cases for a few reasons: > # Objective-C is not deprecated and is not going away. > # Swift has to be written with Objective-C in mind to be backwards > compatible. This severely limits the ability to use modern Swift. Plus, it > requires bringing in the Swift runtime (several MB). It is nice to use all > modern Swift features when using Swift and not have to be reminded of > Objective-C backwards compatibility. > # Objective-C library can be used with Swift with no extra cost, but not the > other way around. Currently 0.12 already has good support by using modern > Objective-C enums and could be expanded for better Swift support, for example > adding nullability type annotations. > # Swift cannot interact with C+++, so if a project is mostly C+++ that must > interact with Cocoa APIs it must use Objective-C. > I am working on adding tests for the Cocoa code from the 0.12 version. My > work in progress is here: > [https://github.com/kainjow/thrift/commits/kwojniak/cocoa-tests-wip] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4878) c_glib ThriftSocket support for unix domain sockets
[ https://issues.apache.org/jira/browse/THRIFT-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4878. --- Resolution: Fixed Fix Version/s: 0.13.0 > c_glib ThriftSocket support for unix domain sockets > --- > > Key: THRIFT-4878 > URL: https://issues.apache.org/jira/browse/THRIFT-4878 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Reporter: Kevin Wojniak >Assignee: James E. King III >Priority: Major > Fix For: 0.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > c_glib library only supports host/port sockets but I needed local unix domain > sockets via file system path. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4547) Finish the conversion to native swift (LANGUAGES.md, cross test)
[
https://issues.apache.org/jira/browse/THRIFT-4547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869849#comment-16869849
]
James E. King III commented on THRIFT-4547:
---
It would be great to get swift into the cross test suite that runs on every PR
and build.
> Finish the conversion to native swift (LANGUAGES.md, cross test)
>
>
> Key: THRIFT-4547
> URL: https://issues.apache.org/jira/browse/THRIFT-4547
> Project: Thrift
> Issue Type: Story
> Components: Swift - Library
>Affects Versions: 0.12.0
>Reporter: James E. King III
>Assignee: Chris Simpson
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Support for Swift-3 was added in THRIFT-3773, however this work needs to be
> completed.
> Are there breaking changes?
> {quote}No/Yes? The compiler is written to allow for the Old Cocoa/Swift with
> a compiler flag, so anyone still using swift 1 or 2 should still be able to
> use the Cocoa style generator but will have to use a compiler flag
> {quote}
> Are they documented?
> {quote}I don't believe thats documented anywhere
> {quote}
> Is it already running in the cross test or is that future work?
> {quote}No tests written for this, that is future work
> {quote}
> Can this be exercised in the Travis CI build environment? (make check, make
> cross?)
> {quote}Should be exercisable in Travis though no tests currently
> {quote}
> Can I add swift support to Ubuntu Xenial and Artful?
> {quote}I'm not sure where the Swift compiler support for Xenial and Artful
> currently is, but should be available.
> {quote}
> What minimum and maximum versions are known supported?
> {quote}Given backwards compatibility with Cocoa/Swift generator this should
> work with all Swift versions v1 through v4 (for Swift 1 and 2, the Cocoa
> library which is Obj-C is required along with the cocoa flag when generating
> code, for Swift 3+ the dedicated Swift library is required)
> {quote}
> Has the LANGUAGES.md file been updated?
> {quote}LANGUAGES.md has not been updated
> {quote}
> Has the build/docker/README.md file been updated?
> {quote}build/docker/README.md have not been updated
> {quote}
> Is this supposed to replace the cocoa implementation? Should that be removed?
> {quote}The cocoa implementation is separate from this implementation. The
> Cocoa compiler/libraries exist for Obj-C, and Swift 1 & 2, whereas Swift 3+
> operate independently without Cocoa (as Swift 3 and up can run on Linux
> without Obj-C runtime/libraries). That being said the old Swift/Cocoa
> compiler is "gone/removed" and there is "only 1 Swift compiler" given the old
> Swift/Cocoa compiler is integrated in this as a compiler flag
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (THRIFT-4874) Thrift 0.12.0 Source Distribution (.tar.gz) Contains Hardlinks - Extract Fails
[ https://issues.apache.org/jira/browse/THRIFT-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III reassigned THRIFT-4874: - Assignee: James E. King III > Thrift 0.12.0 Source Distribution (.tar.gz) Contains Hardlinks - Extract Fails > -- > > Key: THRIFT-4874 > URL: https://issues.apache.org/jira/browse/THRIFT-4874 > Project: Thrift > Issue Type: Bug >Affects Versions: 0.12.0 >Reporter: Daniel Jewell >Assignee: James E. King III >Priority: Blocker > Fix For: 0.13.0 > > > Hello! > The source release tarball of Thrift contains hardlinks - which makes it > impossible to extract on a platform where you cannot create hardlinks (e.g. > on a non-root Android device). (e.g. the archive was not created with > --hard-dereference) > I discovered this as a knock-on effect of trying to build Apache Arrow C++ on > Android (in Termux)... The build fails because the Thrift tarball can't be > extracted because of the hardlinks. > Best, > -Daniel -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4769) Change NuGet package to use netstd artifact
[ https://issues.apache.org/jira/browse/THRIFT-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869833#comment-16869833 ] James E. King III commented on THRIFT-4769: --- Was this work done? It is marked as an 0.13.0 blocker. > Change NuGet package to use netstd artifact > --- > > Key: THRIFT-4769 > URL: https://issues.apache.org/jira/browse/THRIFT-4769 > Project: Thrift > Issue Type: Story > Components: Build Process, C# - Library, netcore - Library, netstd - > Library >Affects Versions: 0.13.0 >Reporter: James E. King III >Assignee: Jens Geyer >Priority: Blocker > > The top level file `ApacheThrift.nuspec` takes artifacts from the C# and > .NETCore builds and places them into a single multi-target nuget package. > This needs to be changed to work with netstd for the 0.13.0 release. I'm > going to make this a blocker to ensure it gets done for the next release, as > I don't think we should publish a 0.13.0 on deprecated artifacts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (THRIFT-4842) Multiplexed protocol has a memory leak in set c_glib
[ https://issues.apache.org/jira/browse/THRIFT-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III reassigned THRIFT-4842: - Assignee: James E. King III (was: Gonzalo Aguilar) > Multiplexed protocol has a memory leak in set c_glib > > > Key: THRIFT-4842 > URL: https://issues.apache.org/jira/browse/THRIFT-4842 > Project: Thrift > Issue Type: Bug >Affects Versions: 0.12.0 >Reporter: Gonzalo Aguilar >Assignee: James E. King III >Priority: Major > Fix For: 0.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The multiplexed protocol is affected by a memory leak in set property in the > c_gllib version when setting the service to be multiplexed. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (THRIFT-4842) Multiplexed protocol has a memory leak in set c_glib
[ https://issues.apache.org/jira/browse/THRIFT-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III reassigned THRIFT-4842: - Assignee: Gonzalo Aguilar (was: James E. King III) > Multiplexed protocol has a memory leak in set c_glib > > > Key: THRIFT-4842 > URL: https://issues.apache.org/jira/browse/THRIFT-4842 > Project: Thrift > Issue Type: Bug >Affects Versions: 0.12.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar >Priority: Major > Fix For: 0.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The multiplexed protocol is affected by a memory leak in set property in the > c_gllib version when setting the service to be multiplexed. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4883) Thrift 0.12.0 source lua lib has a mistake
[
https://issues.apache.org/jira/browse/THRIFT-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869831#comment-16869831
]
James E. King III commented on THRIFT-4883:
---
This change broke the build in the pull request. I suspect it is unnecessary;
I am pulling it out of the 0.13.0 release cycle.
> Thrift 0.12.0 source lua lib has a mistake
> --
>
> Key: THRIFT-4883
> URL: https://issues.apache.org/jira/browse/THRIFT-4883
> Project: Thrift
> Issue Type: Bug
> Components: Lua - Library
>Affects Versions: 0.12.0
>Reporter: Nguyen Duc Duy
>Priority: Major
> Labels: easyfix
> Fix For: 0.13.0
>
> Attachments: Thrift.lua
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> function __TObject:new(init_obj)
> local obj = {}
> if ttype(obj) == 'table' then
> obj = init_obj
> end
> -- Use the __parent key and the __index function to achieve inheritance
> obj.__parent = self
> setmetatable(obj, __TObject.__mt)
> return obj
> end{code}
> In the above code in file Thrift.lua from lib lua in thrift project. I saw
> that it should check if init_obj is a table but this code is checking obj(a
> table as declare ?).
> So i think the source must be
> {code:java}
> function __TObject:new(init_obj)
> local obj = {}
> if ttype(init_obj) == 'table' then
> obj = init_obj
> end
> -- Use the __parent key and the __index function to achieve inheritance
> obj.__parent = self
> setmetatable(obj, __TObject.__mt)
> return obj
> end
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
