[jira] [Resolved] (THRIFT-5821) Cannot compile against aws-lc libcrypto (openssl replacement from AWS)
[ https://issues.apache.org/jira/browse/THRIFT-5821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-5821. --- Fix Version/s: 0.22.0 Resolution: Fixed > Cannot compile against aws-lc libcrypto (openssl replacement from AWS) > -- > > Key: THRIFT-5821 > URL: https://issues.apache.org/jira/browse/THRIFT-5821 > Project: Thrift > Issue Type: Task > Components: C++ - Library >Affects Versions: 0.20.0 > Reporter: James E. King III > Assignee: James E. King III >Priority: Major > Fix For: 0.22.0 > > Attachments: AWSLC.patch > > Time Spent: 10m > Remaining Estimate: 0h > > When attempting to build thrift 0.20.0 against aws-lc > ([https://github.com/aws/aws-lc)] I had to use some local patches. This > issue tracks getting those patches upstream into the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5821) Cannot compile against aws-lc libcrypto (openssl replacement from AWS)
James E. King III created THRIFT-5821: - Summary: Cannot compile against aws-lc libcrypto (openssl replacement from AWS) Key: THRIFT-5821 URL: https://issues.apache.org/jira/browse/THRIFT-5821 Project: Thrift Issue Type: Task Components: C++ - Library Affects Versions: 0.20.0 Reporter: James E. King III Assignee: James E. King III Attachments: AWSLC.patch When attempting to build thrift 0.20.0 against aws-lc ([https://github.com/aws/aws-lc)] I had to use some local patches. This issue tracks getting those patches upstream into the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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&focusedCommentId=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&focusedCommentId=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
&g
[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)
Thrift 0.13.0 Distribution Update
Thrift 0.13.0 has been released to: - Maven Central (as3, java) - Dub (dlang) - Pub (dart) - Hackage (haskell) - npm (js) - CPAN (perl) - Packagist (php) - pypi (python) - Jim
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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)
Re: Please respond to THRIFT-4998
Sorry Christopher, I founded a new company and haven't had any time for the usual duties like this. I'll take care of it this weekend. - Jim On Fri, Nov 15, 2019, 5:45 PM Jens Geyer wrote: > > I agree, and I already reached out to the maven maintainer. > > > -Ursprüngliche Nachricht- > From: Christopher > Sent: Friday, November 15, 2019 10:44 PM > To: dev@thrift.apache.org > Subject: Please respond to THRIFT-4998 > > Can a committer or PMC member please respond to the numerous requests > for information about the 0.13.0 release artifacts in Maven Central at > https://issues.apache.org/jira/browse/THRIFT-4998 ? > > It has been over a week, and nobody is replying to the users who took > the time to report the issue to the developers. This is a very > unfriendly way to treat Thrift's user community. > > Please respond, somebody. > > Thanks. > >
Re: [VOTE] Apache Thrift 0.13.0-rc0 release candidate
Sorry I missed the release party... my startup was funded back in July and most of my open source endeavors have been on pause. - Jim On Tue, Oct 15, 2019, 5:56 PM Jens Geyer wrote: > http://www.apache.org/legal/release-policy.html#release-approval > > -Ursprüngliche Nachricht- > From: XU Qinghui > Sent: Tuesday, October 15, 2019 11:45 AM > To: dev@thrift.apache.org > Subject: Re: [VOTE] Apache Thrift 0.13.0-rc0 release candidate > > Who should be voting on this? (PMC, committers, everybody?) > > Le ven. 11 oct. 2019 à 22:24, Duru Can Celasun a > écrit : > > > Just a reminder: The tagged version must be "v0.13.0" (note the v prefix) > > to be a valid Go module. > > > > I've verified the signature & checksums for the tar.gz. > > > > > > On Fri, 11 Oct 2019, at 21:01, Jens Geyer wrote: > > > All, > > > > > > I propose that we accept the following release candidate as the > official > > > Apache Thrift 0.13.0 release: > > > > > > > > > https://dist.apache.org/repos/dist/dev/thrift/0.13.0-rc0/thrift-0.13.0-rc0.tar.gz > > > > > > The release candidate was created from the release/0.13.0 branch and > can > > be > > > cloned using: > > > > > > git clone -b release/0.13.0 https://github.com/apache/thrift.git > > > > > > The release candidates GPG signature can be found at: > > > > > > https://dist.apache.org/repos/dist/dev/thrift/0.13.0-rc0/thrift-0.13.0-rc0.tar.gz.asc > > > > > > The release candidates checksums are: > > > md5: 38a27d391a2b03214b444cb13d5664f1 > > > sha1: 0cbb06d047a8212c6ac1240492bc569609fecd33 > > > sha256: > 7ad348b88033af46ce49148097afe354d513c1fca7c607b59c33ebb6064b5179 > > > > > > > > > A prebuilt statically-linked Windows compiler is available at: > > > > > > https://dist.apache.org/repos/dist/dev/thrift/0.13.0-rc0/thrift-0.13.0-rc0.exe > > > > > > Prebuilt statically-linked Windows compiler GPG signature: > > > > > > https://dist.apache.org/repos/dist/dev/thrift/0.13.0-rc0/thrift-0.13.0-rc0.exe.asc > > > > > > Prebuilt statically-linked Windows compiler checksums are: > > > md5: e6deaa01bc3697fd78beb680417ef45c > > > sha1: 317b27dd758fed3dd424be8f6e550e0473bc9584 > > > sha256: > 92753ef860304eb6b3fdbbb3e07ae23b30827194d3c2a072bb4cf7a65be87693 > > > > > > > > > The source tree as ZIP file to be published via Github releases: > > > > > > https://dist.apache.org/repos/dist/dev/thrift/0.13.0-rc0/thrift-0.13.0-rc0.zip > > > > > > ZIP source tree GPG signature: > > > > > > https://dist.apache.org/repos/dist/dev/thrift/0.13.0-rc0/thrift-0.13.0-rc0.zip.asc > > > > > > ZIP source tree checksums are: > > > md5: e30699d2eec0cddf80fd4a50ab6aaf2b > > > sha1: 1d56b31aca92f1940701f9a267d8ca473e9b7256 > > > sha256: > 196e52d8fc1a0dd15620ccae59e2473940d41935881608f6eae0c8615366aeb5 > > > > > > > > > The CHANGES list for this release is available at: > > > https://github.com/apache/thrift/blob/release/0.13.0/CHANGES.md > > > > > > > > > Please download, verify sig/sum, install and test the libraries and > > > languages of your choice. > > > > > > This vote will close in 120 hours on 2019-10-16 20:00 UTC > > > > > > [ ] +1 Release this as Apache Thrift 0.13.0 > > > [ ] +0 > > > [ ] -1 Do not release this as Apache Thrift 0.13.0 because... > > > > > > > > > Have fun, > > > JensG > > > > > > > > > >
Re: Travis and D builds
Travis job timeout is 50 minutes normally, but our project has more time than that (which I negotiated). - Jim On Tue, Aug 20, 2019 at 2:15 PM Christopher wrote: > > Is it possible that Travis aborted the job because it took longer than > 20 minutes (the default timeout for Travis)? > That duration value on the travis_time line indicates a duration of > just over 20 minutes (in nanoseconds). > You could try using travis_wait to give it more time: > https://docs.travis-ci.com/user/common-build-problems/#my-builds-are-timing-out > > On Tue, Aug 20, 2019 at 1:01 PM Jens Geyer wrote: > > > > Hi all, > > > > does anybody know what this error is about? > > The deprecations are warnings, so what else could be wrong here? > > > > https://travis-ci.org/apache/thrift/jobs/574053036 > > > > dmd -L-fuse-ld=gold -L-levent ../libthriftd-event.a -L-fuse-ld=gold -L-lssl > > -L-lcrypto ../libthriftd-ssl.a -w -wi -O -release -inline > > -I../../../lib/d/src -Igen-d ../../../lib/d/libthriftd.a > > -ofserialization_benchmark serialization_benchmark.d > > gen-d/DebugProtoTest_types.d > > dmd -L-fuse-ld=gold -L-levent ../libthriftd-event.a -L-fuse-ld=gold -L-lssl > > -L-lcrypto ../libthriftd-ssl.a -w -wi -O -release -inline > > -I../../../lib/d/src -Igen-d ../../../lib/d/libthriftd.a > > -ofstress_test_server stress_test_server.d test_utils.d > > gen-d/thrift/test/stress/Service.d > > gen-d/thrift/test/stress/StressTest_types.d > > dmd -L-fuse-ld=gold -L-levent ../libthriftd-event.a -L-fuse-ld=gold -L-lssl > > -L-lcrypto ../libthriftd-ssl.a -w -wi -O -release -inline > > -I../../../lib/d/src -Igen-d ../../../lib/d/libthriftd.a > > -ofthrift_test_client thrift_test_client.d thrift_test_common.d > > gen-d/thrift/test/SecondService.d gen-d/thrift/test/ThriftTest.d > > gen-d/thrift/test/ThriftTest_constants.d > > gen-d/thrift/test/ThriftTest_types.d > > [1mthrift_test_client.d(128): [1;36mDeprecation: [mstruct > > `std.datetime.StopWatch` is deprecated - Use > > std.datetime.stopwatch.StopWatch. > > [1mthrift_test_client.d(128): [1;36mDeprecation: [mstruct > > `std.datetime.StopWatch` is deprecated - Use > > std.datetime.stopwatch.StopWatch. > > [1mthrift_test_client.d(338): [1;36mDeprecation: [mstruct > > `std.datetime.StopWatch` is deprecated - Use > > std.datetime.stopwatch.StopWatch. > > [1mthrift_test_client.d(338): [1;36mDeprecation: [malias > > `std.datetime.AutoStart` is deprecated - Use > > std.datetime.stopwatch.AutoStart. > > [1mthrift_test_client.d(338): [1;36mDeprecation: [mstruct > > `std.datetime.StopWatch` is deprecated - Use > > std.datetime.stopwatch.StopWatch. > > dmd -L-fuse-ld=gold -L-levent ../libthriftd-event.a -L-fuse-ld=gold -L-lssl > > -L-lcrypto ../libthriftd-ssl.a -w -wi -O -release -inline > > -I../../../lib/d/src -Igen-d ../../../lib/d/libthriftd.a > > -ofthrift_test_server thrift_test_server.d thrift_test_common.d > > test_utils.d gen-d/thrift/test/SecondService.d > > gen-d/thrift/test/ThriftTest.d gen-d/thrift/test/ThriftTest_constants.d > > gen-d/thrift/test/ThriftTest_types.d > > make[3]: Leaving directory '/thrift/src/lib/d/test' > > make[2]: Leaving directory '/thrift/src/lib/d' > > make[1]: Leaving directory '/thrift/src/lib' > > travis_time:end:17fb8648:start=1566251726125736930,finish=1566252944899663089,duration=1218773926159 > > [0K [31;1mThe command "build/docker/run.sh" exited with 2. [0m > > > >
[jira] [Commented] (THRIFT-4677) UnicodeDecodeError in Python3
[
https://issues.apache.org/jira/browse/THRIFT-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3029) Getters for fields defined with uppercase names do not work
[
https://issues.apache.org/jira/browse/THRIFT-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III closed THRIFT-3029.
-
> Getters for fields defined with uppercase names do not work
> ---
>
> Key: THRIFT-3029
> URL: https://issues.apache.org/jira/browse/THRIFT-3029
> Project: Thrift
> Issue Type: Bug
> Components: Cocoa - Compiler
>Affects Versions: 0.9.2
>Reporter: Wes Henderson
> Assignee: James E. King III
>Priority: Critical
> Fix For: 0.13.0
>
>
> Using a thrift file such as:
> {code:title=foo.thrift|borderStyle=solid}
> struct Foo {
> 1: required i32 Bar;
> 2: required i32 baz;
> }
> {code}
> The generated Objective-C object, "baz" will have working getters but "Bar"
> will not. For example, after setting bar to 5 and baz to 9, I get the
> following output depending on the syntax:
> {code}
> [foo bar] => 0
> [foo Bar] (private method invoked by performSelector) => 5
> foo.bar => 0
> foo.Bar => 0
> foo.baz => 9
> {code}
> The problem is that the generated header specifies a lowercase getter:
> {code:}
> @property (nonatomic, getter=bar, setter=setBar:) int32_t Bar;
> {code}
> Whereas the .m file uses uppercase:
> {code}
> - (int32_t) Bar {
> return __Bar;
> }
> {code}
> When the Objective-C compiler sees that there is no lowercase getter
> implementation provided, it automatically generates one (this is supposed to
> be a convenience of the @property syntax). So effectively, two getters are
> defined: a lowercase one that does not work, and an uppercase one that does
> work but is private.
> As a workaround one can define all their fields beginning with a lowercase
> letter, if possible.
--
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 regul
[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&focusedCommentId=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", &sin6_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&focusedCommentId=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", &sin6_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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&writer 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&focusedCommentId=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&writer 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&focusedCommentId=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&writer 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&focusedCommentId=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&writer 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&focusedCommentId=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&writer 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&focusedCommentId=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&writer 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&focusedCommentId=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&writer 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&focusedCommentId=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&writer 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&focusedCommentId=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&writer in Golang's TBinaryProtocol
>
> Client: go
>
> This closes #1831.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
Re: THRIFT-3769
Releases of Thrift are very expensive (time-wise), so we only do them twice a year. The next one should start soon for 0.13.0. - Jim On Thu, Jul 18, 2019 at 7:37 AM Jeff Nelson wrote: > > Ahh, my mistake – I was actually looking for the changes in THRIFT-4805, > which have not been released yet. > > Is it possible to back port this to a 0.12.1? > On Jul 18, 2019, 7:19 AM -0400, James E. King III , wrote: > > It appears in the 0.12.0 tag to me, here's the commit and the tag it > > first appeared in is listed near the top: > > > > https://github.com/apache/thrift/commit/33fb1a3f0da71ba79e3156f7d0c169e7480fcf26#diff-c6a81da7e9ec5ce3c040a3386a790b69 > > > > - Jim > > > > On Wed, Jul 17, 2019 at 5:33 PM Jeff Nelson wrote: > > > > > > The changelog says that THRIFT-3769 was shipped with 0.12.0 but the jar > > > on maven central and the state of the code at the 0.12.0 tag doesn’t have > > > the relevant changes > > > (https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/TThreadPoolServer.java) > > > > > > Is this a mistake? If so, is there a plan to ship an 0.12.1 that adds > > > this change?
Re: THRIFT-3769
It appears in the 0.12.0 tag to me, here's the commit and the tag it first appeared in is listed near the top: https://github.com/apache/thrift/commit/33fb1a3f0da71ba79e3156f7d0c169e7480fcf26#diff-c6a81da7e9ec5ce3c040a3386a790b69 - Jim On Wed, Jul 17, 2019 at 5:33 PM Jeff Nelson wrote: > > The changelog says that THRIFT-3769 was shipped with 0.12.0 but the jar on > maven central and the state of the code at the 0.12.0 tag doesn’t have the > relevant changes > (https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/TThreadPoolServer.java) > > Is this a mistake? If so, is there a plan to ship an 0.12.1 that adds this > change?
[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&focusedCommentId=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)
Re: Using Thrift 0.12.0 generated code with Boost 1.70.0?
We've discussed starting a release cycle and agreed, but it hasn't happened yet. On Tue, Jul 16, 2019 at 6:31 AM Christofer Dutz wrote: > > Ah ok > > In that case we'll leave thrift out of the cpp part till that version is > released. We don't want to introduce dependencies to unreleased stuff. > > Do you have an idea to when 0.13.0 will be released? > > Chris > > Holen Sie sichOutlook für Android<https://aka.ms/ghei36> > > > From: James E. King III > Sent: Tuesday, July 16, 2019 12:57:27 AM > To: dev@thrift.apache.org > Subject: Re: Using Thrift 0.12.0 generated code with Boost 1.70.0? > > Those boost predef deprecation fixes would be in master, and will be > in 0.13.0 when it is released. > In this project master accumulates changes between releases, then we > tag and release. > > - Jim > > On Mon, Jul 15, 2019 at 6:52 PM Christofer Dutz > wrote: > > > > Hi Jim, > > > > Is there any released version which contains these fixes? Cause I thought > > 0.12.0 is the latest one and that's the one I'm using. Or were the changes > > you are referring to merged to master without a release? > > > > Chris > > > > Holen Sie sichOutlook für Android<https://aka.ms/ghei36> > > > > > > From: James E. King III > > Sent: Monday, July 15, 2019 2:27:27 PM > > To: dev@thrift.apache.org > > Subject: Re: Using Thrift 0.12.0 generated code with Boost 1.70.0? > > > > Have you tried the master branch of thrift? > > As far as I know the boost/predef deprecation warnings were resolved > > since 0.12.0 was released. > > > > I found some openssl deprecations as well, I will submit a PR to clean > > that up in a backwards-compatible way. > > > > It also sounds like you are building with "warnings as errors". > > We do not currently do that. > > > > - Jim > > > > On Sun, Jul 14, 2019 at 5:14 PM Christofer Dutz > > wrote: > > > > > > Hi all, > > > > > > we are currently working hard on using Thrift in the Apache PLC4X > > > project. While it took quite a lot of time to fix all the problems with > > > building thrift and boost in our project. > > > Now I’m having problems building c++ thrift code. I guess the issue is > > > that we’re using Boost 1.70.0 and there seem to be issues with Thrift > > > using some deprecated boost features (usage of some BOOST_*_ENDIANES > > > constants). > > > > > > Is a Boost 1.70.0 compatible version of Thrift going to be released soon > > > or is there a way to avoid the build from failing due to these > > > deprecation errors? > > > > > > Help greatly appreciated. Till we can sort this out we’ll just disable > > > the proxy driver in C++ (A PLC4X driver using Thrift to talk to a proxy > > > server) > > > > > > Chris
Re: Using Thrift 0.12.0 generated code with Boost 1.70.0?
Those boost predef deprecation fixes would be in master, and will be in 0.13.0 when it is released. In this project master accumulates changes between releases, then we tag and release. - Jim On Mon, Jul 15, 2019 at 6:52 PM Christofer Dutz wrote: > > Hi Jim, > > Is there any released version which contains these fixes? Cause I thought > 0.12.0 is the latest one and that's the one I'm using. Or were the changes > you are referring to merged to master without a release? > > Chris > > Holen Sie sichOutlook für Android<https://aka.ms/ghei36> > > ________ > From: James E. King III > Sent: Monday, July 15, 2019 2:27:27 PM > To: dev@thrift.apache.org > Subject: Re: Using Thrift 0.12.0 generated code with Boost 1.70.0? > > Have you tried the master branch of thrift? > As far as I know the boost/predef deprecation warnings were resolved > since 0.12.0 was released. > > I found some openssl deprecations as well, I will submit a PR to clean > that up in a backwards-compatible way. > > It also sounds like you are building with "warnings as errors". > We do not currently do that. > > - Jim > > On Sun, Jul 14, 2019 at 5:14 PM Christofer Dutz > wrote: > > > > Hi all, > > > > we are currently working hard on using Thrift in the Apache PLC4X project. > > While it took quite a lot of time to fix all the problems with building > > thrift and boost in our project. > > Now I’m having problems building c++ thrift code. I guess the issue is that > > we’re using Boost 1.70.0 and there seem to be issues with Thrift using some > > deprecated boost features (usage of some BOOST_*_ENDIANES constants). > > > > Is a Boost 1.70.0 compatible version of Thrift going to be released soon or > > is there a way to avoid the build from failing due to these deprecation > > errors? > > > > Help greatly appreciated. Till we can sort this out we’ll just disable the > > proxy driver in C++ (A PLC4X driver using Thrift to talk to a proxy server) > > > > Chris
Re: Using Thrift 0.12.0 generated code with Boost 1.70.0?
Have you tried the master branch of thrift? As far as I know the boost/predef deprecation warnings were resolved since 0.12.0 was released. I found some openssl deprecations as well, I will submit a PR to clean that up in a backwards-compatible way. It also sounds like you are building with "warnings as errors". We do not currently do that. - Jim On Sun, Jul 14, 2019 at 5:14 PM Christofer Dutz wrote: > > Hi all, > > we are currently working hard on using Thrift in the Apache PLC4X project. > While it took quite a lot of time to fix all the problems with building > thrift and boost in our project. > Now I’m having problems building c++ thrift code. I guess the issue is that > we’re using Boost 1.70.0 and there seem to be issues with Thrift using some > deprecated boost features (usage of some BOOST_*_ENDIANES constants). > > Is a Boost 1.70.0 compatible version of Thrift going to be released soon or > is there a way to avoid the build from failing due to these deprecation > errors? > > Help greatly appreciated. Till we can sort this out we’ll just disable the > proxy driver in C++ (A PLC4X driver using Thrift to talk to a proxy server) > > Chris
[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&focusedCommentId=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)
Re: Travis CI Failures - mostly resolved
It looks like the Haskell site is returning valid binaries again - builds are passing. I merged a few more today, down to 5 open PRs. - Jim On Mon, Jul 8, 2019 at 6:23 PM Jens Geyer wrote: > > Hi Jim, > > What needs to be done to resolve this? > > > @Mailing list: Any Haskell-savvy around who wants to take a stab on that > task? > > > IIRC we had Haskell excluded from a release in the past, so (given my mind > does not fool me) in theory we could do that again ... just saying. > > I would like to see the 0.13.0 come to fruition soon, but my Haskell skills > are quite limited. > > Have fun, > JensG > > > -Ursprüngliche Nachricht- > From: James E. King III > Sent: Sunday, July 7, 2019 9:19 PM > To: dev@thrift.apache.org > Subject: Travis CI Failures - mostly resolved > > Currently the Haskell web site is not returning a binary for the cabal > installation; this is causing the Xenial job in Travis CI to fail. > Once that issue is resolved, CI will be back to normal (passing). > > - Jim >
[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
[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)
Travis CI Failures - mostly resolved
Currently the Haskell web site is not returning a binary for the cabal installation; this is causing the Xenial job in Travis CI to fail. Once that issue is resolved, CI will be back to normal (passing). - Jim
[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)
Re: Erlang is not working
Good news, l found the issue was in the test/tests.py file, where we set the command line options to run erlang. After updating to rebar3 the "ebin" directory is in a different location. Tests are passing for me locally now. - Jim On Fri, Jul 5, 2019 at 9:04 PM James E. King III wrote: > > Unfortunately rebar3 was not in the docker container for our CI > builds, which means erlang wasn't being built at all, and it looks > like erlang is now completely broken. Whether using OTP 20 or OTP 22, > erlang doesn't work with any of the other languages. > > This can be seen in the latest pull request for CI updates: > > https://github.com/apache/thrift/pull/1817 > > It is easily reproducible inside the docker build container. > If someone who knows erlang could look into this, it would be great. > We cannot start the 0.13.0 release cycle with a regression like this. > > - Jim
Erlang is not working
Unfortunately rebar3 was not in the docker container for our CI builds, which means erlang wasn't being built at all, and it looks like erlang is now completely broken. Whether using OTP 20 or OTP 22, erlang doesn't work with any of the other languages. This can be seen in the latest pull request for CI updates: https://github.com/apache/thrift/pull/1817 It is easily reproducible inside the docker build container. If someone who knows erlang could look into this, it would be great. We cannot start the 0.13.0 release cycle with a regression like this. - Jim
Need help with erlang test failure, blocking thrift CI build
I have a feature test failing when I update the docker build environment to erlang 22. It looks like no TLS is working. I believe they disabled TLSv1.0 and TLSv1.1 in this release of the ssl package (9.3.x). That said, could someone tell me how to fix this? I do not know erlang. Are we missing a dependency in the rebar script on ssl perhaps? None of the TLS protocols are working. root@4f0e809ad26e:/thrift/src# python3 test/test.py -F --server erl Apache Thrift - Integration Test Suite Wed Jul 03 15:55:28 2019 === server-client: protocol: transport: result: erl-nosslv3 binarybuffered-ip-ssl success erl-limit_container_len compact buffered-ip failure(65) erl-limit_string_length compact buffered-ip failure(65) erl-tls binarybuffered-ip-ssl failure(3) === *** Following 1 failures were unexpected ***: If it is introduced by you, please fix it before submitting the code. === server-client: protocol: transport: result: erl-tls binarybuffered-ip-ssl failure(3) === Unexpected failures are logged to test/features/log/unexpected_failures.log Known failures are logged to test/features/log/known_failures.log You can browse results at: file:///thrift/src/test/features/index.html # If you use Chrome, run: # cd /thrift/src # python -m http.server 8001 # then browse: # http://localhost:8001/test/features/ Full log for each test is here: test/log/server_client_protocol_transport_client.log test/log/server_client_protocol_transport_server.log 3 failed of 4 tests in total. Test execution took 4.4 seconds. Wed Jul 03 15:55:33 2019 root@4f0e809ad26e:/thrift/src# cat test/features/log/erl-tls_binary_buffered-ip-ssl_client.log Wed Jul 03 15:55:33 2019 Executing: /thrift/src/test/features/tls.sh --protocol=binary --transport=buffered --ssl --port=36713 Directory: /thrift/src/test/features config:delay: 5 config:timeout: 5 === openssl s_client -connect localhost:36713 -CAfile ../keys/CA.pem -tls1 2>&1 < /dev/null result of command: 1 [warn] tls1 negotiation did not work 139857556615616:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110: 139857556615616:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111: 139857556615616:error:02002063:system library:connect:Cannot assign requested address:../crypto/bio/b_sock2.c:110: 139857556615616:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111: connect:errno=99 openssl s_client -connect localhost:36713 -CAfile ../keys/CA.pem -tls1_1 2>&1 < /dev/null result of command: 1 [warn] tls1_1 negotiation did not work 139800178897344:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110: 139800178897344:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111: 139800178897344:error:02002063:system library:connect:Cannot assign requested address:../crypto/bio/b_sock2.c:110: 139800178897344:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111: connect:errno=99 openssl s_client -connect localhost:36713 -CAfile ../keys/CA.pem -tls1_2 2>&1 < /dev/null result of command: 1 [warn] tls1_2 negotiation did not work 140417440297408:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110: 140417440297408:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111: 140417440297408:error:02002063:system library:connect:Cannot assign requested address:../crypto/bio/b_sock2.c:110: 140417440297408:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111: connect:errno=99 [fail] At least one of TLSv1.0, TLSv1.1, or TLSv1.2 needs to work, but does not === Return code: 3 (negative values indicate kill by signal) Test execution took 0.0 seconds. Wed Jul 03 15:55:33 2019 root@4f0e809ad26e:/thrift/src# cat test/features/log/erl-tls_binary_buffered-ip-ssl_server.log Wed Jul 03 15:55:29 2019 Executing: erl +K true -noshell -pa ../../lib/erl/ebin/ -pa ./ebin -s test_thrift_server -extra --protocol=binary --transport=buffered --ssl --port=36713 Directory: /thrift/src/test/erl config:delay: 5 config:timeout: 5 === =ERROR REPORT 3-Jul-2019::15:55:30.046850 === Error in process <0.93.0> with exit
