Re: [VOTE] Apache Thrift 0.20.0-rc1 release candidate

[Randy Abernethy]

+1

From: Jens Geyer 
> Date: Tue, Mar 12, 2024 at 6:13 PM
> Subject: [VOTE] Apache Thrift 0.20.0-rc1 release candidate
> To: Thrift-Dev 
>
>
> All,
>
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.20.0 release:
>
>
> https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.tar.gz
>
> The release candidate was created from the release/0.20.0 branch and can
> be cloned using:
>
> git clone -b release/0.20.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.20.0-rc1/thrift-0.20.0.tar.gz.asc
>
> The release candidates checksums are:
> md5: aadebde599e1f5235acd3c730721b873
> sha1: 08330d85fa037440d5b0873aa18edd654194483c
> sha256: b5d8311a779470e1502c027f428a1db542f5c051c8e1280ccd2163fa935ff2d6
>
> A prebuilt statically-linked Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.exe
>
> Prebuilt statically-linked Windows compiler GPG signature:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.exe.asc
>
> Prebuilt statically-linked Windows compiler checksums are:
>
> md5: e867efb609da1f89a77a078c79d435b9
> sha1: 1268712650a525a70125e96ddeb47035b1dfdbb7
> sha256: 7e554be788b6f1fddb05d2be2a3cd2dc853075218c937adb9e9b834959c9c060
>
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/0.20.0/CHANGES.md
>
> Please download, verify sig/sum, install and test the libraries and
> languages of your choice.
>
>
> I start this voting thread with my own +1 vote.
>
>
> This vote will close in 145 hours on 2024-02-19 00:00 UTC
> https://www.timeanddate.com/countdown/generic?iso=20240319T=1440
>
> [ ] +1 Release this as Apache Thrift 0.20.0
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.20.0 because...
>
> Have fun,
> JensG
>
>
>

Re: [VOTE] Apache Thrift 0.19.0-rc1 release candidate

[Randy Abernethy]

+1

On Sun, Aug 27, 2023 at 10:22 AM Jens Geyer  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.19.0 release:
>
>
> https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc1/thrift-0.19.0.tar.gz
>
> The release candidate was created from the release/0.19.0 branch and can
> be cloned using:
>
> git clone -b release/0.19.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.19.0-rc1/thrift-0.19.0.tar.gz.asc
>
> The release candidates checksums are:
> md5: f2074232cd80c83f30c030cb69ef68a8
> sha1: 8b3f52e7645e3374669d523bcaa433ed8962aa75
> sha256: d49c896c2724a78701e05cfccf6cf70b5db312d82a17efe951b441d300ccf275
>
>
> A prebuilt statically-linked Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc1/thrift-0.19.0.exe
>
> Prebuilt statically-linked Windows compiler GPG signature:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc1/thrift-0.19.0.exe.asc
>
> Prebuilt statically-linked Windows compiler checksums are:
> md5: 73870121ae5fa18510f4605af03188fc
> sha1: c14214f8f28150428b83735b7a44bb8deeb3d0e8
> sha256: ae87e34c459447c723ef705faa5cde40edfb699f1bb9452cebb94c7bfef7f5ab
>
>
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/0.19.0/CHANGES.md
>
>
> Please download, verify sig/sum, install and test the libraries and
> languages of your choice.
>
> This vote will close in 129 hours on 2023-09-02 00:00 UTC
> https://www.timeanddate.com/countdown/generic?iso=20230902T=1440
>
> [ ] +1 Release this as Apache Thrift 0.19.0
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.19.0 because...
>
>
> Have fun,
> JensG
>


-- 

Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE] Apache Thrift 0.19.0-rc0 release candidate

[Randy Abernethy]

+1

On Mon, Aug 7, 2023 at 1:20 PM Yuxuan Wang 
wrote:

> +1.
>
> We tested the go compiler/lib but didn't finish the python test in time but
> don't want to hold this forever.
>
> Also there's a new RC for go1.21 so I don't want that to hold this release
> forever as well.
>
> Sorry for the late vote.
>
> On Tue, Jul 18, 2023 at 4:14 PM Yuxuan Wang 
> wrote:
>
> > Thanks for the work, Jens!
> >
> > We already tested the RC version on a go service in our environment. We
> > also have another team to try to test the RC version on a python service,
> > but that's more challenging (especially for an unreleased version that
> > there's no pre-built python packages) so it might take a few more days.
> >
> > Another thing that's not really a release blocker but I would prefer to
> > wait for a little bit is https://github.com/apache/thrift/pull/2821,
> > which depends on the release of Go 1.21. There was go 1.21-rc2 from June
> 21
> > and -rc3 from July 14, so I would expect the actual release will happen
> > very soon, and it would be great to wait a bit and align our releases
> > (since we both have similar release cadence of twice a year).
> >
> > On Sat, Jul 15, 2023 at 3:20 AM Jens Geyer  wrote:
> >
> >> All,
> >>
> >> I propose that we accept the following release candidate as the official
> >> Apache Thrift 0.19.0 release:
> >>
> >>
> >>
> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc0/thrift-0.19.0.tar.gz___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6NjoyZTU4OmQ0Yzk5YTQzZTViOTk2Njc5YjA3NzcwZTA2ZmNhZjFjZjM0ODdjMmM3MWJhYWI0ZjA1ZjI0ZjAwZWJhNTBkNzE6cDpU
> >>
> >> The release candidate was created from the release/0.19.0 branch and can
> >> be cloned using:
> >>
> >> git clone -b release/0.19.0
> >>
> https://protect.checkpoint.com/v2/___https://github.com/apache/thrift.git___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6NjowZDM0OjI3YmY2NzVjZjhjNjhjMTVjNTllYjQ4NzNlYmU4MDM4NzkxOTBjZDMxZTFkMDUwNTc1YjM5MmIzYzJjMDQzMDI6cDpU
> >>
> >> The release candidates GPG signature can be found at:
> >>
> >>
> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc0/thrift-0.19.0.tar.gz.asc___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6NjplZGMzOmI0YWM4OGI1MGU0MTFkNTJkZjlkMGVlYzk5ZmNlNGRiN2RmODMyZmIwNzcxMWI2YjFhMzIwMjcwOWI1ZjcwNjY6cDpU
> >>
> >> The release candidates checksums are:
> >> md5: d1f7f19a23e1830f83052c050156cebc
> >> sha1: f06f3a281bb41eed789d0e88d8a1b35405c664a8
> >> sha256: c5a6ac0aca3bf1fd8a2f6afffc24bdf247cd8188480222c89f14a7900f7d6a51
> >>
> >>
> >> A prebuilt statically-linked Windows compiler is available at:
> >>
> >>
> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc0/thrift-0.19.0.exe___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6Njo5NDIzOjUxNTRlM2IxMDlmY2VjOWY5OWM4NjVjNzQzNmM2NTE1NTJmNzdmMmRlMGMyOTNlOGEzOTQ1MTk2MjJhZDFlMWI6cDpU
> >>
> >> Prebuilt statically-linked Windows compiler GPG signature:
> >>
> >>
> https://protect.checkpoint.com/v2/___https://dist.apache.org/repos/dist/dev/thrift/0.19.0-rc0/thrift-0.19.0.exe.asc___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6Njo5YWQ3OjFhNjNmZGZjNmJiM2YxODY2ODAxNmY4NGFjYWYzYjdkNmNjMWNjNTA5OWJhYzVmZjdhZWExYTI1ZDQ4ZDExMzA6cDpU
> >>
> >> Prebuilt statically-linked Windows compiler checksums are:
> >> md5: cf4a7d003893c4503fc7105aef0259ca
> >> sha1: d0e67bb8c89ee557614fd9e1e0f3086ff67164c9
> >> sha256: 1f1ce1658df1226a35dc6a6318da6d534328e24f3c99da4dee847eb57654401d
> >>
> >>
> >> The CHANGES list for this release is available at:
> >>
> >>
> https://protect.checkpoint.com/v2/___https://github.com/apache/thrift/blob/0.19.0/CHANGES.md___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6NjoyZjVkOjkxMDkwNjY1YjU4MDQ1NWRjNmFhM2ZiM2Q1MGY1NzhlOGFhZDU3MDEwY2Q1ODAwMzNlYzMwZjIwYmI3ZTRmOWI6cDpU
> >>
> >>
> >> Please download, verify sig/sum, install and test the libraries and
> >> languages of your choice.
> >>
> >> This vote will close in 109 hours on 2023-07-20 00:00 UTC
> >>
> >>
> https://protect.checkpoint.com/v2/___https://www.timeanddate.com/countdown/generic?iso=20230720T=1440___.YzJ1OnJlZGRpdDpjOmc6ZWI5MWFkNzI2OWQxMWVlMTZiNWYzODUyMThmYjk4YWQ6NjpkOGMzOjNiOTY1ZTZkNjcwNzVlOGU0OTc2N2EyOTcxNzYwNDI0ZDUwN2E5M2M2ODEwMzFmZTM2NWNiNGZmNjMwNjY5NDg6cDpU
> >>
> >> [ ] +1 Release this as Apache Thrift 0.19.0
> >> [ ] +0
> >> [ ] -1 Do not release this as Apache Thrift 0.19.0 because...
> >>
> >>
> >> Have fun,
> >> JensG
> >>
> >
>


-- 

Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

[VOTE] Apache Thrift 0.18.1-rc0 release candidate

[Randy Abernethy]

+1

(to be official)
On Thu, Feb 23, 2023 at 4:31 PM Jens Geyer  wrote:

> @all,
>
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.18.1 release:
>
>
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.tar.gz
>
> The release candidate was created from the release/0.18.1 branch and can
> be cloned using:
>
> git clone -b release/0.18.1 https://github.com/apache/thrift.git
>
> The release candidates GPG signature can be found at:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.tar.gz.asc
>
> The release candidates checksums are:
> md5: 44f788bf18f85851847d49fa14786a96
> sha1: eac2a46a2d09df7f7cc25c687b066f0803d4e770
> sha256: 04c6f10e5d788ca78e13ee2ef0d2152c7b070c0af55483d6b942e29cff296726
>
>
> A prebuilt statically-linked Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.exe
>
> Prebuilt statically-linked Windows compiler GPG signature:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.exe.asc
>
> Prebuilt statically-linked Windows compiler checksums are:
> md5: ac14f6c20558f1264ea57723f5183e18
> sha1: dca5abbc27031c3a91b6dc572bf7beed01e65511
> sha256: d9a9c54268ad982dcfd0f0485084acce73278a281813593234b4bad9c5d31044
>
>
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/0.18.1/CHANGES.md
>
>
> Please download, verify sig/sum, install and test the libraries and
> languages of your choice.
>
> This vote will close in 122 hours on 2023-03-01 00:00 UTC
> https://www.timeanddate.com/countdown/generic?iso=20230301T=1440
>
> [ ] +1 Release this as Apache Thrift 0.18.1
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.18.1 because...
>
> Have fun,
> JensG

Re: [VOTE] Apache Thrift 0.18.1-rc0 release candidate

[Randy Abernethy]

+1

On Thu, Feb 23, 2023 at 4:31 PM Jens Geyer  wrote:

> @all,
>
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.18.1 release:
>
>
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.tar.gz
>
> The release candidate was created from the release/0.18.1 branch and can
> be cloned using:
>
> git clone -b release/0.18.1 https://github.com/apache/thrift.git
>
> The release candidates GPG signature can be found at:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.tar.gz.asc
>
> The release candidates checksums are:
> md5: 44f788bf18f85851847d49fa14786a96
> sha1: eac2a46a2d09df7f7cc25c687b066f0803d4e770
> sha256: 04c6f10e5d788ca78e13ee2ef0d2152c7b070c0af55483d6b942e29cff296726
>
>
> A prebuilt statically-linked Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.exe
>
> Prebuilt statically-linked Windows compiler GPG signature:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.18.1-rc0/thrift-0.18.1.exe.asc
>
> Prebuilt statically-linked Windows compiler checksums are:
> md5: ac14f6c20558f1264ea57723f5183e18
> sha1: dca5abbc27031c3a91b6dc572bf7beed01e65511
> sha256: d9a9c54268ad982dcfd0f0485084acce73278a281813593234b4bad9c5d31044
>
>
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/0.18.1/CHANGES.md
>
>
> Please download, verify sig/sum, install and test the libraries and
> languages of your choice.
>
> This vote will close in 122 hours on 2023-03-01 00:00 UTC
> https://www.timeanddate.com/countdown/generic?iso=20230301T=1440
>
> [ ] +1 Release this as Apache Thrift 0.18.1
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.18.1 because...
>
> Have fun,
> JensG
>


-- 

Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: Versions, patches and limited resources (was: Thoughts on a 0.9.4 rc)

[Randy Abernethy]

If the community wants to move to 1.0 I would support that.

On Sat, Mar 5, 2022 at 3:11 AM Jens Geyer  wrote:

>
> Am 05.03.2022 um 12:06 schrieb Jens Geyer:
> > Java and the compiler (for C#)
>
>
> Well, compiler code is a full package ... so that would then be a full
> 0.16.1 indeed.
>
>

-- 

Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: Second opinion wanted

[Randy Abernethy]

Dropped a Jira comment with a couple format/comment requests but
functionally LGTM.

On Sat, Mar 5, 2022 at 9:40 AM Jens Geyer  wrote:

> Hi C++ folks,
>
> I would love to have a second opinion on this:
>
> https://github.com/apache/thrift/pull/2522
>
> It's not a big change, so if anyone competent can spare a few minutes,
> that would be awesome.
>
> Thanks,
> JensG
>


-- 

Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE] Apache Thrift 0.16.0-rc2 release candidate

[Randy Abernethy]

If not recorded already +1

On Wed, Feb 9, 2022 at 12:19 PM Jens Geyer  wrote:

>
> All,
>
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.16.0 release:
>
>
> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.tar.gz
>
> The release candidate was created from the release/0.16.0 branch and can
> be cloned using:
>
> git clone -b release/0.16.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.16.0-rc2/thrift-0.16.0.tar.gz.asc
>
> The release candidates checksums are:
> md5: 44cf1b54b4ec1890576c85804acfa637
> sha1: a4770d0d16851b59b657348d6d167437938dd750
> sha256: f460b5c1ca30d8918ff95ea3eb6291b3951cf518553566088f3f2be8981f6209
>
>
> A prebuilt statically-linked Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.exe
>
> Prebuilt statically-linked Windows compiler GPG signature:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc2/thrift-0.16.0.exe.asc
>
> Prebuilt statically-linked Windows compiler checksums are:
> md5: 9ff1a90f8dd5b1fa73d55990b775a516
> sha1: 16a85665a095b5924f2d00efe1e7ae4595c1a317
> sha256: e106135ee72c5328ccf13faa1180570c672d4bb7af44d3f9e34642874474b58a
>
>
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/0.16.0/CHANGES.md
>
>
> Please download, verify sig/sum, install and test the libraries and
> languages of your choice.
>
> This vote will close in 123 hours on 2022-02-15 00:00 UTC
> https://www.timeanddate.com/countdown/generic?iso=20220215T=1440
>
> [ ] +1 Release this as Apache Thrift 0.16.0
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.16.0 because...
>
> PS: Thanks to all that made it possible.
>
>
>

Re: [VOTE] Apache Thrift 0.16.0-rc1 release candidate

[Randy Abernethy]

+1

On Fri, Feb 4, 2022 at 2:10 PM Jens Geyer  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.16.0 release:
>
>
> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc1/thrift-0.16.0.tar.gz
>
> The release candidate was created from the release/0.16.0 branch and can
> be cloned using:
>
> git clone -b release/0.16.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.16.0-rc1/thrift-0.16.0.tar.gz.asc
>
> The release candidates checksums are:
> md5: b57857fe9f32f4cdeb8368ed74b6f5d1
> sha1: 750ef4d74f5a863bf1431fa1a64b346a1e2ff0d3
> sha256: 036894dc05d439889f2a302db95af44f7e2aea64d6b17014b2c941df2798b1b3
>
>
> A prebuilt statically-linked Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc1/thrift-0.16.0.exe
>
> Prebuilt statically-linked Windows compiler GPG signature:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.16.0-rc1/thrift-0.16.0.exe.asc
>
> Prebuilt statically-linked Windows compiler checksums are:
> md5: 574fb28bcec48a27f3e911f3dab23b99
> sha1: ee2692de1f38aa45d285709d177c92d490e9ac73
> sha256: 18f055010bc67ed59b824d8fe41a67dc083177bb6ccd7787499123a04f33f870
>
>
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/0.16.0/CHANGES.md
>
>
> Please download, verify sig/sum, install and test the libraries and
> languages of your choice.
>
> This vote will close in 121 hours on 2022-02-10 00:00 UTC
> https://www.timeanddate.com/countdown/generic?iso=20220210T=1440
>
> [ ] +1 Release this as Apache Thrift 0.16.0
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.16.0 because...
>
>
>

Re: Drop support of Python 2?

[Randy Abernethy]

+1 for dropping Py2 support

On Fri, Jan 7, 2022 at 1:41 PM Duru Can Celasun  wrote:

> On Fri, 7 Jan 2022, at 21:27, Yuxuan Wang wrote:
> > According to https://www.python.org/doc/sunset-python-2/, support for
> > Python 2 was stopped from 2020-01-01, which is already more than two
> years
> > ago from now. Is there any reason that thrift should continue to support
> > Python 2 in the newer versions?
> >
> > If there's no objections I would like to remove python 2 from CI
> > configuration and docs (for example, LANGUAGES.md).
> >
> > If JIRA is a better place to discuss this than the maillist I can move
> the
> > discussion there as well.
> >
> > (This came up as we found out that a fix we did for Python 3 failed the
> > Python 2 tests. That in itself is not a very big deal that we can make
> the
> > tests to work for both 2 and 3, but continuing support something that's
> > already dropped by upstream for 2 years doesn't really make much sense to
> > me.)
>
> +1 for dropping it. The wire formats have been stable for a very long time
> and anyone who needs Python 2 support can stick to 0.15 without worrying
> about compatibility.
>

Re: [DISCUSS][VOTE] Deprecation of Common LISP bindings?

[Randy Abernethy]

+1

On Thu, Oct 21, 2021 at 6:48 PM Allen George  wrote:

> +1 deprecate it
>
> Allen
>
>
> On Thu, Oct 21, 2021 at 4:53 PM Jens Geyer  wrote:
>
> > @all,
> >
> > THRIFT-5410 “CL build broken: Component :NET.DIDIERVERNA.CLON.TERMIO not
> > found” is open for months now, and CI is still not fully working because
> of
> > it.
> >
> > Because of the obvious lack of community interest in Common Lisp (we have
> > only two tickets for it in total in JIRA) and the lack of contributions
> of
> > any kind, I propose to deprecate the Common LISP bindings per 0.16.0 and
> > finally remove it with whatever follows after 0.16.x
> >
> > According to Apache’s Lazy Consensus policy, if there is no significant
> > opinion against it, I move forward with creating a ticket and adding the
> > deprecation message at the end of next the week to master. I will also
> > comment it out to get CI green again and last not least take care about
> the
> > necessary follow-up after next release (i.e. removal from the code base).
> >
> > [   ]  +1 yes, deprecate it
> > [   ]  0   no opinion
> > [   ]  -1 don’t deprecate, because __
> >
> > Have fun,
> > JensG
>


-- 

Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE] Apache Thrift 0.15.0-rc0 release candidate

[Randy Abernethy]

+1

On Tue, Sep 7, 2021 at 9:18 PM Duru Can Celasun  wrote:

> +1
>
>
>
> On Wed, 8 Sep 2021, at 01:31, Yuxuan Wang wrote:
> > +1
> >
> > On Sat, Sep 4, 2021 at 1:01 PM Jens Geyer  wrote:
> >
> > > All,
> > >
> > > I propose that we accept the following release candidate as the
> official
> > > Apache Thrift 0.15.0 release:
> > >
> > >
> > >
> https://dist.apache.org/repos/dist/dev/thrift/0.15.0-rc0/thrift-0.15.0.tar.gz
> > >
> > > The release candidate was created from the 0.15.0 branch and can be
> cloned
> > > using:
> > >
> > > git clone -b 0.15.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.15.0-rc0/thrift-0.15.0.tar.gz.asc
> > >
> > > The release candidates checksums are:
> > > md5: 81954d55567e2996ba186f8776aa8b1b
> > > sha1: a2f9f2bc3db1f045c1e2d429a8951912fb2d253b
> > > sha256:
> d5883566d161f8f6ddd4e21f3a9e3e6b8272799d054820f1c25b11e86718f86b
> > >
> > >
> > > A prebuilt Windows compiler is available at:
> > >
> https://dist.apache.org/repos/dist/dev/thrift/0.15.0-rc0/thrift-0.15.0.exe
> > >
> > > Prebuilt Windows compiler GPG signature:
> > >
> > >
> https://dist.apache.org/repos/dist/dev/thrift/0.15.0-rc0/thrift-0.15.0.exe.asc
> > >
> > > Prebuilt Windows compiler checksums are:
> > > md5: c43896461df259f3b3815336fe42040e
> > > sha1: 1687f2b2d648391c3aa3a540df6ec791be03c38e
> > > sha256:
> 4c584556233a95e78b17d89ce9506ad8dbea651b5bbc63da1467f97564b58849
> > >
> > >
> > > The CHANGES list for this release is available at:
> > > https://github.com/apache/thrift/blob/0.15.0/CHANGES.md
> > >
> > >
> > > Please download, verify sig/sum, install and test the libraries and
> > > languages of your choice.
> > >
> > > This vote will close in 104 hours on Thu, 2021-SEP-09 00:00 UTC5
> > >
> https://www.timeanddate.com/countdown/generic?iso=20210909T=1440
> > >
> > > [ ] +1 Release this as Apache Thrift 0.15.0
> > > [ ] +0
> > > [ ] -1 Do not release this as Apache Thrift 0.15.0 because...
> > >
> > > Best,
> > > JensG
> > >
> > >
> >
>


-- 

Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE] Apache Thrift 0.14.2-rc1 release candidate

[Randy Abernethy]

+1

On Sat, Jun 12, 2021, 1:13 PM Jens Geyer  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.14.2 release:
>
>
> https://dist.apache.org/repos/dist/dev/thrift/0.14.2-rc1/thrift-0.14.2.tar.gz
>
> The release candidate was created from the 0.14.2 branch and can be cloned
> using:
>
> git clone -b 0.14.2 https://github.com/apache/thrift.git
>
> The release candidates GPG signature can be found at:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.14.2-rc1/thrift-0.14.2.tar.gz.asc
>
> The release candidates checksums are:
> md5: 284a48df355aa3910687ee9b894d3ae8
> sha1: daf3640f5f18ddb7c194133903b6882df93c5d51
> sha256: 4191bfc0b7490e20cc69f9f4dc6e991fbb612d4551aa9eef1dbf7f4c47ce554d
>
>
> A prebuilt Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.14.2-rc1/thrift-0.14.2.exe
>
> Prebuilt Windows compiler GPG signature:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.14.2-rc1/thrift-0.14.2.exe.asc
>
> Prebuilt Windows compiler checksums are:
> md5: fd0bda468e65f552e15a585ef5de83fe
> sha1: 52a0a177cea7d5431fa5b19d8d6caa753b02eba1
> sha256: 2a0911dbd5899ebb37a08dcc517188ce02987cdebdfc5e5f1db29215ed5355bb
>
>
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/0.14.2/CHANGES.md
>
>
> Please download, verify sig/sum, install and test the libraries and
> languages of your choice.
>
> This vote will close on Thu, 2021-06-17 00:00 UTC
> https://www.timeanddate.com/countdown/generic?iso=20210617T=1440
>
> [ ] +1 Release this as Apache Thrift 0.14.2
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.14.2 because...
>
> I start with my own +1.
>
> Best,
> JensG
>
>

[jira] [Commented] (THRIFT-5405) netstd TSocketTransport(IPAddress host, ...) constructor fails to init TcpClient

[Randy Abernethy (Jira)]

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

Randy Abernethy commented on THRIFT-5405:
-

Patch attached. Anyone want to review?

> netstd TSocketTransport(IPAddress host, ...) constructor fails to init 
> TcpClient
> 
>
> Key: THRIFT-5405
> URL: https://issues.apache.org/jira/browse/THRIFT-5405
> Project: Thrift
>  Issue Type: Bug
>  Components: netstd - Library
>Affects Versions: 0.14.1
>Reporter: Randy Abernethy
>    Assignee: Randy Abernethy
>Priority: Minor
> Attachments: 
> 0001-Properly-init-netstd-TcpClient-in-TSocketTransport-c.patch
>
>
> netstd TSocketTransport(IPAddress host, int port, TConfiguration config, int 
> timeout = 0) constructor fails to init the TcpClient.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (THRIFT-5405) netstd TSocketTransport(IPAddress host, ...) constructor fails to init TcpClient

[Randy Abernethy (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy reassigned THRIFT-5405:
---

Assignee: Randy Abernethy

> netstd TSocketTransport(IPAddress host, ...) constructor fails to init 
> TcpClient
> 
>
> Key: THRIFT-5405
> URL: https://issues.apache.org/jira/browse/THRIFT-5405
> Project: Thrift
>  Issue Type: Bug
>  Components: netstd - Library
>Affects Versions: 0.14.1
>Reporter: Randy Abernethy
>    Assignee: Randy Abernethy
>Priority: Minor
> Attachments: 
> 0001-Properly-init-netstd-TcpClient-in-TSocketTransport-c.patch
>
>
> netstd TSocketTransport(IPAddress host, int port, TConfiguration config, int 
> timeout = 0) constructor fails to init the TcpClient.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (THRIFT-5405) netstd TSocketTransport(IPAddress host, ...) constructor fails to init TcpClient

[Randy Abernethy (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-5405:

Attachment: 0001-Properly-init-netstd-TcpClient-in-TSocketTransport-c.patch

> netstd TSocketTransport(IPAddress host, ...) constructor fails to init 
> TcpClient
> 
>
> Key: THRIFT-5405
> URL: https://issues.apache.org/jira/browse/THRIFT-5405
> Project: Thrift
>  Issue Type: Bug
>  Components: netstd - Library
>Affects Versions: 0.14.1
>Reporter: Randy Abernethy
>Priority: Minor
> Attachments: 
> 0001-Properly-init-netstd-TcpClient-in-TSocketTransport-c.patch
>
>
> netstd TSocketTransport(IPAddress host, int port, TConfiguration config, int 
> timeout = 0) constructor fails to init the TcpClient.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (THRIFT-5405) netstd TSocketTransport(IPAddress host, ...) constructor fails to init TcpClient

[Randy Abernethy (Jira)]

Randy Abernethy created THRIFT-5405:
---

 Summary: netstd TSocketTransport(IPAddress host, ...) constructor 
fails to init TcpClient
 Key: THRIFT-5405
 URL: https://issues.apache.org/jira/browse/THRIFT-5405
 Project: Thrift
  Issue Type: Bug
  Components: netstd - Library
Affects Versions: 0.14.1
Reporter: Randy Abernethy


netstd TSocketTransport(IPAddress host, int port, TConfiguration config, int 
timeout = 0) constructor fails to init the TcpClient.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[VOTE] Apache Thrift 0.14.1-rc0 release candidate

[Randy Abernethy]

  +1


From: Jens Geyer 
Date: Tue, Mar 2, 2021 at 1:35 PM
Subject: [VOTE] Apache Thrift 0.14.1-rc0 release candidate
To: Thrift-Dev 


All,

I propose that we accept the following release candidate as the official
Apache Thrift 0.14.1 release:

https://dist.apache.org/repos/dist/dev/thrift/0.14.1-rc0/thrift-0.14.1.tar.gz

The release candidate was created from the 0.14.1 branch and can be cloned
using:

git clone -b 0.14.1 https://github.com/apache/thrift.git

The release candidates GPG signature can be found at:
https://dist.apache.org/repos/dist/dev/thrift/0.14.1-rc0/thrift-0.14.1.tar.gz.asc

The release candidates checksums are:
md5: c64434548438df2cb1e53fb27c600e85
sha1: 7b322742610ef6c9f15e22101862163b72a7efe7
sha256: 13da5e1cd9c8a3bb89778c0337cc57eb0c29b08f3090b41cf6ab78594b410ca5


A prebuilt Windows compiler is available at:
https://dist.apache.org/repos/dist/dev/thrift/0.14.1-rc0/thrift-0.14.1.exe

Prebuilt Windows compiler GPG signature:
https://dist.apache.org/repos/dist/dev/thrift/0.14.1-rc0/thrift-0.14.1.exe.asc

Prebuilt Windows compiler checksums are:
md5: adda033e9a721e13215e13994ca0d5bd
sha1: 1080b396ad3e8ce5aafffb26664ccf7fa6ca1b52
sha256: 2529e9e8dfe0c6bfaeb8f618705e5ea6703b56acbd7566ea7a1e75521b24dfff



The CHANGES list for this release is available at:
https://github.com/apache/thrift/blob/0.14.1/CHANGES.md


Please download, verify sig/sum, install and test the libraries and
languages of your choice.

This vote will close in 72 hours on Mon, 2021-03-08 00:00 UTC
https://www.timeanddate.com/countdown/generic?iso=20210308T=1440

[ ] +1 Release this as Apache Thrift 0.14.1
[ ] +0
[ ] -1 Do not release this as Apache Thrift 0.14.1 because...

Best,
JensG

Re: Travis open-source builds sharply reduced

[Randy Abernethy]

Public images on Docker Hub are free. They limit your pulls but I don't
think the limits are anywhere near restrictive enough to limit Thrift
builds.

> rate *limits* of 100 container *image* requests per six hours for
anonymous usage, and 200 container *image* requests per six hours for free
*Docker* accounts

On Tue, Mar 2, 2021 at 6:29 AM Mario Emmenlauer  wrote:

>
> Hi,
>
> On 02.03.21 15:14, Allen George wrote:
> > Hi -
> >
> > Re: the blogpost on the paid subscription for Travis - is it still valid
> > today? If so - that's great to hear.
> >
> > Re: reinstalling deps from scratch. You're right Mario - that does
> happen.
> > Seems like the guidance is to have the first stage build a temporary
> docker
> > container that has all the deps, and have following stages pull down that
> > container and use it for their tasks. Travis doesn't have a docker cache,
> > however, so we'd need something like docker hub. Does the ASF have a
> docker
> > hub subscription? Did someone else take a look at doing this in the past?
>
> Yep, this would work, or there could be a dedicated branch that builds the
> docker images. I personally use a dedicated branch that I trigger only
> every
> once a month or so. The benefit is that the "current latest" docker images
> keep on working until new docker images (from the branch) become available.
> So if an upstream remote is temporarily down for a few weeks, it will only
> break the dedicated docker build and zero of our own pipelines.
>
> My own mileage for this concept is pretty good, as long as someone will
> every now and then actually do update dependencies.
>
> I tried to implement this for Thrift but stopped because I did not know
> where to put the images :-(
>
> Cheers,
>
> Mario
>
>
>
> > Thanks,
> > Allen
> >
> > On Tue, Mar 2, 2021 at 3:38 AM Duru Can Celasun 
> wrote:
> >
> >> Keep in mind that the ASF has a paid subscription [1] to Travis, so we
> are
> >> not limited to the open source plan.
> >>
> >> [1]
> https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci
> >>
> >> On Tue, 2 Mar 2021, at 08:28, Mario Emmenlauer wrote:
> >>>
> >>> Hi,
> >>>
> >>> On 02.03.21 05:28, Allen George wrote:
> >>>> Hi -
> >>>>
> >>>> Really sorry if I missed the conversation about this, but it seems
> like
> >>>> Travis open source builds are being drastically reduced. I only
> >> realized
> >>>> this when looking at the ominous warning on the Travis build page for
> >>>> Thrift. Counting up the minutes for a single push indicates that we
> >> use 500
> >>>> minutes per PR (!) This is a serious problem, because as far as I can
> >> tell,
> >>>
> >>> I'm not sure how much this is related, but I'm under the impression
> that
> >>> currently every build is starting from vanilla environment and
> installing
> >>> all dependencies from scratch. This spends significant time on
> downloads
> >>> and installations, and (what's almost worse) it often fails when
> upstream
> >>> dependencies are temporarily unavailable or changed.
> >>>
> >>> It could be much better to have a persistent environment, for example
> >>> preserve the pre-installed docker containers?
> >>>
> >>> All the best,
> >>>
> >>> Mario Emmenlauer
> >>>
> >>>
> >>> --
> >>> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> >>> Balanstr. 43   mailto: memmenlauer *
> biodataanalysis.de
> >>> D-81669 München
> http://www.biodataanalysis.de/
> >>>
> >>
> >
>
>
>
> Viele Gruesse,
>
> Mario Emmenlauer
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
>


-- 

-- 
Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE][RESULT] Apache Thrift 0.14.0-rc0 release candidate

[Randy Abernethy]

adding my late +1

On Wed, Feb 10, 2021 at 12:04 PM Jens Geyer  wrote:

> All,
>
> Including my own vote of +1 we have 2 binding +1.
> Additionally, we received one non-binding +1.
> No -1 votes have been cast.
>
> Binding Votes
> +1 Jens Geyer
> +1 Duru Can Celasun
>
> Non-binding votes
> +1 Yuxuan Wang
>
> According to the ASF trelease policy, the vote for the Apache Thrift
> 0.14.0
> release is NOT successful, because we did not reach the minimum required
> amount of positive binding votes.
>
> http://www.apache.org/legal/release-policy.html#release-approval
> http://www.apache.org/legal/release-policy.html#approving-a-release
>
> Thank you to all who helped test and verify.
>
> JensG
>
>
> -Ursprüngliche Nachricht-
> From: Jens Geyer
> Sent: Friday, February 5, 2021 12:52 AM
> To: Thrift-Dev
> Subject: [VOTE] Apache Thrift 0.14.0-rc0 release candidate
>
> All,
>
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.14.0 release:
>
>
> https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.tar.gz
>
> The release candidate was created from the release/0.14.0 branch and can
> be
> cloned using:
>
> git clone -b release/0.14.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.14.0-rc0/thrift-0.14.0.tar.gz.asc
>
> The release candidates checksums are:
> md5: 53a61cd60ff2f06d3102e1bf6dd62b37
> sha1: ced3c99bede66e27daff7bd097adc329ff3682b9
> sha256: 8dcb64f63126522e1a3fd65bf6e5839bc3d3f1e13eb514ce0c2057c9b898ff71
>
>
> A prebuilt statically-linked Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.exe
>
> Prebuilt statically-linked Windows compiler GPG signature:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.14.0-rc0/thrift-0.14.0.exe.asc
>
> Prebuilt statically-linked Windows compiler checksums are:
> md5: 28ff1f363ead1f4c11485cef9c2ac696
> sha1: 078001bcd4ac6d179c2d09a0323eb5fc9bc5bb78
> sha256: 2630d039d3548db9eae70f7cd76ace0672f8535ef0021b9ad02205ed63d3f204
>
>
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/release/0.14.0/CHANGES.md
>
>
> Please download, verify sig/sum, install and test the libraries and
> languages of your choice.
>
> This vote will close in 114 hours on 2021-02-09 18:00 UTC, giving enough
> room for everybody even with a weekend in between.
>
> [ ] +1 Release this as Apache Thrift 0.14.0
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.14.0 because...
>
> https://www.timeanddate.com/countdown/generic?iso=20210209T1800=1440
>
> Have fun,
> JensG
>
>

-- 

-- 
Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [DISCUSS][VOTE] Deprecation of Haskell bindings?

[Randy Abernethy]

+1 to dropping it if we can not find a maintainer.

On Mon, Feb 8, 2021 at 5:19 AM Jens Geyer  wrote:

> @all,
>
> In THRIFT-5347, Philipp Hausmann started the discussion whether or not the
> Apache Thrift Haskell bindings are still worth maintaining or if we should
> drop them from the code base. I don’t want to repeat all the arguments
> here, so if you need details please look at that ticket.
>
> Therefore, I’d like to ask the question what the community thinks about
> this particular piece of the code base.
>
> a) Is anyone out there who is still using Apache Thrift Haskell bindings?
> b) What would be the consensus if we follow the proposal  to drop Haskell
> support from Apache Thrift  entirely?
>
> So this is your personal opportunity to veto (and step up as a maintainer).
>
> As with AS3 the support would be deprecated for 0.15.0 and finally removed
> with 0.16.0 (or whatever the number will be).
>
> According to Apache’s Lazy Consensus policy, if there is no significant
> opinion against Haskell deprecation, I add the deprecation message at the
> end of the week to master and take care about the necessary follow-up after
> next release.
>
> Have fun,
> JensG
>


-- 

-- 
Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: Improving documentation

[Randy Abernethy]

+1 !!

On Mon, Sep 28, 2020 at 11:48 AM Jens Geyer  wrote:

> +1 much appreciated,  documentation is a common complaint
>
> 
> From: Dedipyaman Das <2dcodeblo...@gmail.com>
> Sent: Sunday, September 27, 2020 4:11:41 PM
> To: u...@thrift.apache.org ; dev@thrift.apache.org
> 
> Subject: Improving documentation
>
> The other day I was discussing with a friend regarding GRPC/Protobuf and
> Thrift, and he told me about how the GRPC documentation was much better to
> Thrift as a result of him choosing it over Thrift any day.
>
> And I think that's an issue with the current state of Thrift as well, when
> I was starting off with Thrift about a year back, it was considerably
> harder for me to get started with it than it did for GRPC/Protobuf because
> of the state of the documentation.
>
> The documentation in its current state seems disorganized and unwelcoming
> for the new user according to me personally, and I think it's the general
> consensus as well. Of course, there are independent blogs, ebooks books
> etc. on thrift, but I think the official documentation should be a bit more
> organized and easy to get used to.
>
> Can we attempt at making a new, more organized attempt at improving the
> documentation? I think starting from scratch would be the best at this
> point with the aim of making it newbie-friendly documentation with a clear
> explanation of the concepts and implementations.
>
> I'd like to volunteer to take this step if more people feel the same way
> and willing to help out. Let's make Thrift more newbie-friendly!
>
> Regards,
> Dedipyaman
> www.twodee.me<http://www.twodee.me>
>


-- 

-- 
Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: Your experience with TCompactProtocol vs. TBinaryProtocol?

[Randy Abernethy]

Used Compact a few versions back with good results in a mostly C++ system.
Noticed a bit more CPU consumption on very high call rate services but the
smaller wire size seemed to improve overall throughput in our scenario. Non
line of biz utilities in various scripting languages all seemed to work
fine.

On Tue, Sep 22, 2020 at 2:52 PM Yuxuan Wang 
wrote:

> I'm wondering if anyone has/had experience with switching from
> TBinaryProtocol to TCompactProtocol in your production environment, either
> good or bad ones (maybe you encountered problems and had to switch back,
> I'd like to hear your story).
>
> We recently noticed that for the same structs, using TSerializer with
> TCompactProtocol would save roughly 25~30% in size compared to using
> TBinaryProtocol. We also did some benchmark tests which show that there's
> no noticeable performance hit for both go and python's implementations.
> We've been running https://github.com/apache/thrift/pull/2239 in our
> staging environment experimenting THeader+TCompact over the default
> THeader+TBinary, and the results so far look good. We are gonna do some
> production experiments soon as well after that is merged.
>
> But if anyone has done that before, I'd like to hear from you! :)
>


-- 

-- 
Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: New committer: Zezeng Wang

[Randy Abernethy]

Congratulations Zezeng!!

On Fri, Sep 11, 2020 at 11:27 AM Jens Geyer  wrote:

> The Project Management Committee (PMC) for Apache Thrift has invited
> Zezeng
> Wang to become a committer and we are pleased to announce that he has
> accepted.
>
> Being a committer enables easier contribution to the project since there
> is
> no need to go via the patch submission process. This should enable better
> productivity.
>
> The Apache Thrift PMC
>
>

-- 

-- 
Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: C++ reviewers for PR 2151 wanted

[Randy Abernethy]

Just took a look. +1

On Tue, Jun 9, 2020 at 12:59 AM max ulidtko  wrote:

> Hi list,
>
> I'm the PR author — calling out for reviewers!
>
> The diff is under 1 kLoC.
>
> I have it well-groomed already:
>  • CI bots are green;
>  • new code is clang-formatted;
>  • entry in CHANGES.md added;
>  • both buildsystems adjusted for new file;
>  • non-pertinent changes split off;
>  • Jens Geyer's "partial" code review remarks addressed;
>  • Mario Emmenlau's remarks addressed.
>
> Mario has done, or is doing, his own testing of this patch. No issues have
> returned to me so far.
>
> I did my own testing — I describe which exactly in the commit message /
> patch header.
>
> If there is any C++ developer out there who feels like spending a
> share of his/her valuable
> > time to review this PR, that would be a great thing. But be warned,
> there is a reason for
> > this request: The patch is a bit more complicated and has plenty of
> #ifdef-ed code portions,
> > so better come prepared ;-)
> > https://github.com/apache/thrift/pull/2151
> >
> >
> Right, about those #ifdef's. I add only one new #ifdef _WIN32, in
> TSocketUtils.h. It's used to correctly handle the slightly different
> meanings of getaddrinfo() error codes on win32 vs posix.
>
> All other #ifdef's in the diff are moves. As I explain in the commit
> message; several screenfuls of repetitive #ifdef-rich lines in the middle
> of important loop — are big nuisance and get in the way. So I grouped all
> those setsockopt()s and separated them into dedicated private methods.
> Makes it possible to navigate the listen() method again; I refrained from
> any further refactorings.
>
> git config diff.colormoved zebra — may help to see these code moves. GitHub
> diff viewer does not visualize those.
>
> Lastly: about third of the diff consists of just replicating the same
> changes as in TServerSocket onto TNonblockingServerSocket. These two
> classes are obviously "inherited" one from another (via copy-paste). I
> again refrained from refactoring any of that. Instead, I carefully did the
> same changes again to the other class. This is another reason why the diff
> is bigger than it needs to be (and it's not my fault).
>
> Please NOTE: an earlier patch from me ("Thrift libraries crash with
> localhost-only network"), merged post-0.13, does remedy the localhost-only
> situation — but also has a potential to increase the "Address family for
> hostname not supported" errors in _networked_ scenarios. Before that former
> patch, we've seen the error ~once a month or two on our systems; with it
> (vendored in-house build of Thrift), we continued to see the errors,
> somewhat even more frequently — but this time, on _networked_ machines
> (non-localhost-only), as it turned out. Which is why I went big, and
> developed this second patch.
>
> I hope you can see why I'd really really really like to get this patch
> ("Rewrite address resolution") landed in 0.14 — otherwise, the earlier
> patch may make some havoc.
>
> Hope to get some good looks on the patch (with git diff zebra enabled!..),
> helpful comments, and ultimately LGTM.
>
> Best regards
> Max
>
>
> On Fri, May 29, 2020 at 1:29 PM max ulidtko  wrote:
>
> > Hi all,
> >>
> >> the PR creator is a bit hesitant about it, so I ask for him:
> >>
> >> If there is any C++ developer out there who feels like spending a share
> of his/her valuable
> >> time to review this PR, that would be a great thing. But be warned,
> there is a reason for
> >> this request: The patch is a bit more complicated and has plenty of
> #ifdef-ed code portions,
> >> so better come prepared ;-)
> >> https://github.com/apache/thrift/pull/2151
> >>
> >> Right, about those #ifdef's — I add only one new #ifdef _WIN32, in
> > TSocketUtils.h. It's used to correctly handle the slightly different
> > meanings of getaddrinfo() error codes on win32 vs posix.
> >
> > All other #ifdef's in the diff are moves. As I explain in the commit
> > message; several screenfuls of repetitive #ifdef-rich lines in the middle
> > of important loop are big nuisance and get in the way. So I grouped all
> > those setsockopt()s and separated them into dedicated private methods.
> > Makes it possible to navigate the listen() method; I refrained from any
> > further refactorings.
> >
> > git config diff.colormoved zebra — may help to see these code moves.
> > GitHub diff viewer doesn't visualize those.
> >
> > Lastly: around third of the diff consists of just replicating the same
> > changes as in TServerSocket onto TNonblockingServerSocket. These two
> > classes are obviously "inherited" from each other (by copy-paste). I
> again
> > refrained from refactoring any of that. Instead, I carefully did the same
> > changes again to the other class. This is another reason why the diff is
> > bigger than it needs to be (and it's not my fault).
> >
> > Max
> >
> >
>


-- 

-- 
Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [DISCUSS] AS3 anyone?

[Randy Abernethy]

I would +1 retiring it. Perhaps deprecate it in the next release and then
remove in the one after that.

On Tue, Apr 28, 2020 at 12:10 AM Jens Geyer  wrote:

> Hi all,
>
> we had have long time no commits or contributions for the AS3 support in
> Thrift.
>
> Therefore, I’d like to ask the question what the community thinks about
> this particular piece of the code base.
>
> a) Is anyone out there who is still using Action Script?
> b) What would be the consensus if I propose to drop AS3 support entirely?
>
> Before we have a formal vote I’d like to get some free feedback, so please
> feel free to comment in any form you wish.
>
> Have fun,
> JensG
>
>

-- 

-- 
Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Randy Abernethy (Jira)]

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

Randy Abernethy commented on THRIFT-4710:
-

+1

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.13.0
>Reporter: James E. King III
>Assignee: Duru Can Celasun
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Apache Thrift 0.13.0-rc0 release candidate

[Randy Abernethy]

+1

On Fri, Oct 11, 2019 at 1:01 PM 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
>
>

-- 

-- 
Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [Discussion] Should thrift-java support HTTP/2 ?

[Randy Abernethy]

+1 for http/2 support

On Thu, Aug 29, 2019, 08:19 pzh  wrote:

> Dear All:
>
>
> Our team encountered some http protocol problems when using thrift-0.12.0:
>
>
> 1. Just like Spark Thrift's http delay case, Since HttpClient 4.3, many
> classes and methods have been deprecated or terminated, HttpClient uses
> HTTP/2, which is much worse than HTTP/2,
> Apache HttpComponents httpclient 5.0 has still not released support for
> HTTP/2 officially.
>
>
> 2. In Android Thrift aspect, the underlying implementation of
> HttpURLConnection from Android4.4 uses OkHttp, which is based on HTTP/2
> development,
> official team is no longer maintaining HttpClient.
>
>
> OTOH, compared to HTTP/1, HTTP/2 has more features and excellent
> performance, such as: Multiplexing, binary framing, header compression,
> server push etc...
>
>
> HTTP/1, is a little out of date, so i propose to replace HttpClient with a
> third-party jar that supports HTTP/2, such as OkHttp, or upgrade the java
> version that supports HTTP/2.
>
>
> hope for your reply, guys.
>
>
> Best Regards
> Zhouhu

ASF annual report

[Randy Abernethy]

Per Sally Khudairi, highlights from the ASF annual report include:

"21. GitHub traffic: Top 5 most active Apache sources --clones: Thrift,
Cordova, Arrow, Airflow, and Beam"

Nice!


Highlights include:

1. ASF codebase is conservatively valued at least $20B, using the COCOMO 2
model;
2. Continued guardianship of 190M+ lines of code in the Apache repositories;
3. Profit for FY2018-2019: $585,486;
4. Total of 10 Platinum Sponsors, 9 Gold Sponsors, 11 Silver Sponsors, 25
Bronze Sponsors, and 6 Platinum Targeted Sponsors, 5 5. Gold Targeted
Sponsors, 3 Silver Targeted Sponsors, and 10 Bronze Targeted Sponsors;
5. 35 new individual ASF Members elected, totalling 766;
6. Exceeded 7,000 code Committers;
7. 202 Top-Level communities overseeing 332 Apache projects and
sub-projects;
8. 17 newly-graduated Top-Level Projects from the Apache Incubator;
9. 47 projects currently undergoing development in the Apache Incubator;
10. Top 5 most active/visited Apache projects: Hadoop, Kafka, Lucene, POI,
ZooKeeper;
11. Top 5 Apache repositories by number of commits: Camel, Hadoop, HBase,
Beam, and Flink;
12. Top 5 Apache repositories by lines of code: NetBeans, OpenOffice, Flex
(combined), Mynewt (combined), and Trafodion;
13. 35M page views per week across apache.org;
14. 9M+ source code downloads from Apache mirrors (excluding convenience
binaries);
15. Web requests received from every Internet-connected country on the
planet;
16. 3,280 Committers changed 71,186,324 lines of code over 222,684 commits;
17. 18,750 authors sent 1,402,267 emails on 570,469 topics across 1,131
mailing lists;
18. Top 5 most active mailing lists (user@ + dev@): Flink, Beam, Lucene,
Ignite, and Kafka;
19. Automated Gitbox across ~1,800 git repositories containing ~75GB of
code and repository history;
20. Each GitHub account monitored for security compliance;
21. GitHub traffic: Top 5 most active Apache sources --clones: Thrift,
Cordova, Arrow, Airflow, and Beam;
22. GitHub traffic: Top 5 most active Apache sources --visits: Spark,
Camel, Flink, Kafka, and Airflow;
23. 24th anniversary of the Apache HTTP Server (20 years under the ASF
umbrella);
24. 770 Individual Contributor License Agreements (CLAs) signed;
25. 28 Corporate Contributor License Agreements signed;
26. 26 Software Grant Agreements signed; and
27. ASF is a mentoring organization in Google Summer of Code for 14th
consecutive year.

Re: About time for another release?

[Randy Abernethy]

+1

On Wed, Jun 19, 2019 at 11:49 AM Jens Geyer  wrote:

> +1
>
> Sent from mobile device, please ignore spelling mistakes.
> 
> Von: James E. King III
> Gesendet: 19.06.2019 16:49
> An: dev@thrift.apache.org
> Betreff: About time for another release?
>
> The pull request backlog is growing.  Let's scrub it, merge what we
> can, and start a release cycle.  If we release now and again in
> December we'll get 2 releases out this year.  This release will also
> include a CVE from the 0.12.1 effort (I think).  Thoughts?
>
> - Jim
>


-- 

-- 
Randy Abernethy
Managing Partner
RX-M, llcrandy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: THRIFT-66 - Bidirectional communication

[Randy Abernethy]

gt; > to be an "initiator" (starts the connection), and after they connect they 
> > > are equal peers with the ability to request or reply of each-other.
> > >
> > > You can approximate asynchronous behavior by exclusively using "oneway" 
> > > requests in your design.  I'd suggest avoiding use of oneway requests 
> > > with THttpProtocol varieties however as today there are some issues, 
> > > since Http transport requires a response to be sent, and "oneway" 
> > > dictates there is no reply, and most languages do not handle it well 
> > > right now (there are open backlog issues for this).
> > >
> > > For a matrix of supported languages, protocols, transports, and server 
> > > types, see the file LANGUAGES.md at the root of the github repository.
> > >
> > > Another idea I was toying with a while ago was to add a message bus 
> > > transport to Thrift which would allow for things like reliable delivery 
> > > and broadcast semantics but that also does not exist today.
> > >
> > > - Jim
> > >
> > > On Wed, May 15, 2019 at 1:05 AM John Dougrez-Lewis  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > >
> > > >
> > > > I was looking for a mechanism to be able to provide
> > > > language-agnostic API support to a hobby project I've been working on 
> > > > for some time.
> > > >
> > > >
> > > >
> > > > By following a trail of papers, books and references, I eventually
> > > > came across Apache Thrift and have found and started going through
> > > > Randy Abernethy's new book.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Essentially what I was looking for was support for asynchronous
> > > > calls, and by extension, pub/sub and two way communication across
> > > > and between multiple languages over some channel, preferably IPC but in 
> > > > the worst case sockets.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Having read the book, I can see that there is support for basic
> > > > synchronous RPC between a client and a server over a significant
> > > > number of languages and for just a very few languages, such as java,
> > > > some element of support for asynchronous callbacks, and otherwise
> > > > one-way methods that do not provide indication of subsequent failure.
> > > >
> > > >
> > > >
> > > > It appeared to me one way of extending bi-directional asynchronous
> > > > support would be to have the client to set itself up as a server for
> > > > the server at the other end to connect to, and then it would just be
> > > > a question of choreographing the setting up of a pair of RPC channels.
> > > >
> > > >
> > > >
> > > > An asynchronous call could be implemented by providing a synchronous
> > > > method that simply immediately returns a handle to the caller, and
> > > > the server would then continue to process the call request on a
> > > > background threadpool thread on the server, and the async result
> > > > would then be signalled by a call from the server back to the client
> > > > on the 2nd channel with the handle providing a context to lookup the 
> > > > result.
> > > >
> > > >
> > > >
> > > > Pub/sub would just then be multiple calls from the server back to
> > > > the client.
> > > >
> > > >
> > > >
> > > > The whole thing could sit on top of the existing unidirectional RPC
> > > > implementation and provide full asynchronous calls & pub/sub across
> > > > *ALL* supported languages at probably very little additional effort,
> > > > with no changes to the existing code.
> > > >
> > > >
> > > >
> > > > You could then have a framework that extended the existing IDL to
> > > > include decoration with attributes for async & pub/sub methods & in/out 
> > > > parameters.
> > > >
> > > >
> > > >
> > > > This extended IDL could then be pre-processed to generate
> > > > client-server and server-client service definitions in the existing
> > > > base IDL language, together with generating supporting glue code to
> > > > compile to provide the support for hooking up the channels between each 
> > > > side.
> > > >
> > > >
> > > >
> > > > I note that THRIFT-66 was raised 10 years ago, but it looks like the
> > > > C# code was never made available for release by Dell.
> > > >
> > > >
> > > >
> > > > I have some questions:
> > > >
> > > >
> > > >
> > > > 1)  What is the current state of plans for this supporting this 
> > > > sort of
> > > > functionality? What issues have been encountered ?
> > > >
> > > >
> > > >
> > > > 2)  Is there a document/spreadsheet somewhere showing a matrix of 
> > > > what
> > > > Transports and Protocols are supported for each language?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > >
> > > >
> > > > John
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE] Apache Thrift 0.12.1-rc1 release candidate

[Randy Abernethy]

+1

On Tue, Mar 19, 2019 at 2:32 PM Jens Geyer  wrote:
>
> All,
>
> since I just became aware of what Christopher really meant I leave the vote 
> open for another 72 hours. Sorry for the confusion.
>
> Therefore, this vote will close in 72 hours on 2019-03-22 22:00 UTC.
>
> Have fun,
> JensG
>
>
>
>
> From: Jens Geyer
> Sent: Saturday, March 16, 2019 6:50 PM
> To: Thrift-Dev
> Subject: [VOTE] Apache Thrift 0.12.1-rc1 release candidate
>
> All,
>
> I propose that we accept the following release candidate as the official 
> Apache Thrift 0.12.1 release:
>
> https://dist.apache.org/repos/dist/dev/thrift/0.12.1-rc1/thrift-0.12.1.tar.gz
>
> The release candidate was created from the release/0.12.1 branch and can be 
> cloned using:
>
> git clone -b release/0.12.1 https://github.com/apache/thrift.git
>
> The release candidates GPG signature can be found at:
> https://dist.apache.org/repos/dist/dev/thrift/0.12.1-rc1/thrift-0.12.1.tar.gz.asc
>
> The release candidates checksums are:
> md5: f32465321af86b68bf8e063346e8215d
> sha1: 0b3262c0f6138dd93940c12812b7f7119d1ef6a1
> sha256: 4eb365b2ffeed21e3e713bddf1d69922789c3761e1ecdefacf3256b1493d19b3
>
>
> A prebuilt statically-linked Windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.12.1-rc1/thrift-0.12.1.exe
>
> Prebuilt statically-linked Windows compiler GPG signature:
> https://dist.apache.org/repos/dist/dev/thrift/0.12.1-rc1/thrift-0.12.1.exe.asc
>
> Prebuilt statically-linked Windows compiler checksums are:
> md5: 0da241ce0f87670879cffdf19e7c248d
> sha1: 1e2bc1e2db853ec89e570fa830e8fe4a597ba6ab
> sha256: cf27fefa18c490b5cb9c9191ab2bb341c9a0d86de733776cb3b6d8dd2a03e4d0
>
>
> The source tree as ZIP file to be published via Github releases:
> https://dist.apache.org/repos/dist/dev/thrift/0.12.1-rc1/thrift-0.12.1.zip
>
> ZIP source tree GPG signature:
> https://dist.apache.org/repos/dist/dev/thrift/0.12.1-rc1/thrift-0.12.1.zip.asc
>
> ZIP source tree checksums are:
> md5: bdb52e41cfa51f4a992f0ae5a8ceec6b
> sha1: 55dea149402c897ec4167e01ecc35a5d6765dd88
> sha256: 0caf8e8e50d0b9912e37082702dc05c73a91997748b4b39a5ab05291fe0ad038
>
>
> The CHANGES list for this release is available at:
> https://github.com/apache/thrift/blob/0.12.1/CHANGES
>
>
> Please download, verify sig/sum, install and test the libraries and languages 
> of your choice.
>
> This vote will close in 72 hours on 2019-07-06 21:00 UTC
>
> [ ] +1 Release this as Apache Thrift 0.12.1
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.12.1 because...
>
> Have fun,
> JensG



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

[jira] [Commented] (THRIFT-4815) Golang thrift and Python don't write the same messages

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4815:
-

Also want to add that Apache Thrift has no concern for field order. You can 
pass fields and/or parameters in any order on the wire and a correctly built 
Apache Thrift counter party will receive them without error.

> Golang thrift and Python don't write the same messages
> --
>
> Key: THRIFT-4815
> URL: https://issues.apache.org/jira/browse/THRIFT-4815
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler, Go - Library, Python - Compiler, Python - 
> Library
>Affects Versions: 0.11.0, 0.12.0
> Environment: Python:
> Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 
> bit (AMD64)] on win32
> Thrift version 0.11.0 tested.
> Golang:
> Thrift versions 0.12.0 and 0.11.0 tested
> go version go1.11.4 windows/amd64
> go env:
> set GOARCH=amd64
> set GOBIN=
> set GOCACHE=C:\Users\BUNNY\AppData\Local\go-build
> set GOEXE=.exe
> set GOFLAGS=
> set GOHOSTARCH=amd64
> set GOHOSTOS=windows
> set GOOS=windows
> set GOPATH=C:\Users\BUNNY\go
> set GOPROXY=
> set GORACE=
> set GOROOT=C:\Go
> set GOTMPDIR=
> set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
> set GCCGO=gccgo
> set CC=gcc
> set CXX=g++
> set CGO_ENABLED=1
> set GOMOD=
> set CGO_CFLAGS=-g -O2
> set CGO_CPPFLAGS=
> set CGO_CXXFLAGS=-g -O2
> set CGO_FFLAGS=-g -O2
> set CGO_LDFLAGS=-g -O2
> set PKG_CONFIG=pkg-config
> set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 
> -fdebug-prefix-map=C:\Users\BUNNY\AppData\Local\Temp\go-build552047466=/tmp/go-build
>  -gno-record-gcc-switches
>Reporter: Jack Flecher
>Assignee: James E. King III
>Priority: Blocker
>  Labels: newbie
> Attachments: bunny.thrift
>
>
> I'm trying to port a tool that relies on Thrift from Python to Golang, it is 
> a client not a server.
> The thrift protocol behaves inconsistent when comparing Python and Golang and 
> it results in breaking applications.
> What it boils down to is I have a struct called Message with a certain amount 
> of fields and I have a sendMessage method that takes that message and sends 
> it to a server which then processes that.
> In Python I can simply make a Message object, set some user's userId as 
> receiver and the text after which I can send the message using sendMessage()
> In Golang I can do the exact same but I run into error responses from the 
> server saying another field that isn't required cannot be found.
> In Python this is the generated POST body sent to the server:
> b'\x82!\x00\x0bsendMessage\x15\x00\x1c(!u218891b1a7af4d21ffe4918acbeb9a73\x88\x04test\x00\x00'
> b'\x82!\x00\x0bsendMessage\x15\x00\x1c(!u218891b1a7af4d21ffe4918acbeb9a73\x88\x05test2\x00\x00'
> In Golang the generated POST body sent to the server:
> b'\x82!\x01\x0bsendMessage\x15\x00\x1c(\x04test\x88!u218891b1a7af4d21ffe4918acbeb9a73\x00\x00'
> b'\x82!\x02\x0bsendMessage\x15\x00\x1c(\x05test2\x88!u218891b1a7af4d21ffe4918acbeb9a73\x00\x00'
> As demonstrated above therre are two differences in the generated POST bodies 
> but the one causing the error is the fact that the fields are in a different 
> order than they are supposed to.
> In Golang trying to reverse the order of the fields causes this POST body to 
> be generated:
> b'\x82!\x01\x0bsendMessage\x15\x00\x1c\xa8!u218891b1a7af4d21ffe4918acbeb9a73\x08\x04\x04test\x00\x00'
> When commenting out all the fields I actually don't want to be written and 
> then only reversing the functions that are actually writing data, the ones 
> for the receiver and text fields the POST body looks like this:
> b'\x82!\x01\x0bsendMessage\x15\x00\x1c(\x04test\x88!u218891b1a7af4d21ffe4918acbeb9a73\x00\x00'
> To summarize, the Thrift protocol on Golang is broken in certain cases 
> because fields are not written in the right order causing other 
> implementatings of Thrift to stop serving Golang Thrift clients.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4801) Take ownership of node-int64 JS module

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4801:
-

[~Kieffer] could you perhaps provide a patch/pull that integrates the 
node-int64 code directly in the js lib? That would give us autonomy without a 
breaking change. [~jking3] Then we could go down the bignum path as needed.

> Take ownership of node-int64 JS module
> --
>
> Key: THRIFT-4801
> URL: https://issues.apache.org/jira/browse/THRIFT-4801
> Project: Thrift
>  Issue Type: Task
>  Components: JavaScript - Library
>Reporter: Robert
>Priority: Major
>
> Hey gang, I wrote/maintain the node-int64. I no longer have an interest in 
> maintaining it, however.
> As Thrift (and various thrift-related projects) seem to be the primary 
> dependents on this module, I thought I'd reach out to see if there was any 
> interest in taking ownership of this code.  Let me know if so.  Otherwise I 
> plan on npm-deprecating it at some future date.
> Cheers!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-1018) Add support for idempotent service requests

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-1018:
-

Indeed, this would be complex to implement, particularly so in a generic way. 
Completely valid to want impotence but I concur with Allen, it should be an 
application layer concern.

> Add support for idempotent service requests
> ---
>
> Key: THRIFT-1018
> URL: https://issues.apache.org/jira/browse/THRIFT-1018
> Project: Thrift
>  Issue Type: New Feature
>  Components: Wish List
> Environment: NA
>Reporter: Tony Kinnis
>Priority: Major
>
> I would like to be able to flag service methods as idempotent and allow the 
> transport to replay idempotent requests in certain failure cases. I think 
> this would be a valuable feature for Thrift and its community of users.
> High-Level Feature Description:
> Owners of services should be able to flag a service method as idempotent in 
> the IDL. This metadata will need to make its way into the code generated by 
> the compiler. Exactly how that shows up is probably language dependent.
> The transport can then transparently replay the idempotent requests for 
> typical errors, such as connect timeout, interrupted connections, no response 
> received in timeout interval, etc. 
> The replaying of idempotent requests can be disabled/enabled via the 
> transport. In addition to enabling/disabling, the configuration could allow 
> for the number of allowed retries to be specified or even provide a delegate 
> method that decides if the retry is allowed based on the error that occurred 
> and other context. 
> In some cases retries are not desired, even if the method allows for it. In 
> this case the caller can simply disable retries. Likewise, the caller can 
> decide to only retry on a subset of the possible errors by providing a 
> delegate to the transport.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4710:
-

If we can make the web/build tooling work I agree that a one repo approach is a 
big win.

> Move all ASF CMS website content to GitHub
> --
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.12.0
>Reporter: James E. King III
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.
> My recommendation is to put the documentation into the "docs/" (or leave it 
> in "doc/", perhaps, it if works) and use https://readthedocs.org/ to create 
> the documentation web site.  Documentation updates can be pushed into the 
> repository with {{`[ci skip]`}} or maybe we teach GitHub and/or our Appveyor 
> and Travis to do nothing on pull requests that only contain updates to 
> markdown and/or rst files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: GSoC

[Randy Abernethy]

Totally agree on the fortitude point! Maybe a good fit for a paid
intern because of.

On Tue, Jan 29, 2019 at 3:37 PM James E. King III  wrote:
>
> I'm open to pull requests but I don't know what the GSoC requirements are
> for reporting back.
> Boost does GSoC and seems to have a little program around it.
>
> I recently added AS3 support to autotools and cmake.  One needs to have
> patience and some
> fortitude to get it all working.
>
> - Jim
>
> On Tue, Jan 29, 2019 at 1:45 PM Randy Abernethy  wrote:
>
> > Hey All,
> >
> > What do you think about Thrift trying to get a GSoC student to get the
> > build system fully migrated to cmake?
> >
> > --Randy
> >



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

GSoC

[Randy Abernethy]

Hey All,

What do you think about Thrift trying to get a GSoC student to get the
build system fully migrated to cmake?

--Randy

[jira] [Commented] (THRIFT-4405) Proper use of sequence IDs in all clients and servers

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4405:
-

I would reword #3 and 4 a bit but otherwise sounds great.

#3 A server must return the exact seqid received in a request with the response 
to that request.

#4 A server should make no assumptions about the value or semantics of the 
seqid.

 

> Proper use of sequence IDs in all clients and servers
> -
>
> Key: THRIFT-4405
> URL: https://issues.apache.org/jira/browse/THRIFT-4405
> Project: Thrift
>  Issue Type: Improvement
>  Components: Test Suite
>Affects Versions: 0.10.0
> Environment: docker ubuntu-xenial
>Reporter: James E. King III
>Assignee: James E. King III
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Create a feature test that verifies sequence numbers are used properly.  
> Write a server that verifies clients are generating unique sequence IDs.  
> Write a client that makes sure servers return the same sequence ID that was 
> given.
> To do this, I enhanced the C++ TProcessorEventHandler class to include a 
> preReadSeq, which is like preRead but carries the sequence ID.
> In the C++ TestServer, I check to see if the sequence numbers are unique and 
> do not repeat; if any of them do, the cpp test fails.
> The following languages properly send sequence IDs (for the binary protocol):
> * dart
> * go
> * nodejs
> * java
> * rs
> The rest of the languages do not.  Now, one could argue that unless a 
> language has a concurrent-safe client and server, sequence IDs are 
> unnecessary.  While that is true, all languages should respect that the 
> protocol has a sequence ID and there could be future implementations that 
> will require all clients are well-behaved, which is why I am putting this 
> test in.
> Languages fixed up so unique sequence IDs are sent by the client, and 
> verified by the tests:
> * cpp (was only sending unique sequence IDs for Concurrent clients, now it 
> does for the regular one too)
> * csharp (seqid_ was not bring incremented with each use)
> * lua (seqid_ was not bring incremented with each use)
> * perl (seqid_ was not bring incremented with each use)
> * ruby (seqid_ was not bring incremented with each use and a unit test was 
> updated to no longer be pending)
> Languages left to do:
> * c_glib
> * erlang
> * haskell
> * php
> * python
> * python3
> * any non-cross tested languages



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2426) clarify IP rights and contributions from fbthrift

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-2426:
-

Hey Mario,

Yes, would be surprised to get the FB nod to handing over the whole fbthrift 
repo, though it would be great. In the past the FB folks providing the code 
bits have built the pull requests. 

 

--Randy 

> clarify IP rights and contributions from fbthrift 
> --
>
> Key: THRIFT-2426
> URL: https://issues.apache.org/jira/browse/THRIFT-2426
> Project: Thrift
>  Issue Type: Story
>  Components: Documentation
>Reporter: Roger Meier
>Assignee: James E. King III
>Priority: Critical
>
> We need to ensure that we have the IP rights to anything we commit from
> fbthrift and its traceable back on our dev list initiated from someone at 
> facebook.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2426) clarify IP rights and contributions from fbthrift

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-2426:
-

The issue is that the Apache 2 lic  requires preservation of copyright. Code in 
the Apache repo can not have copyright Facebook 2014 or whatever (which AFAIK 
all of the fbthrift code is). If fb staff contribute it w/o copyright then it's 
ok. If they blanket grant the fbthrift code to apache then anyone contributing 
it would be ok. As it is, it is not ok.

What can you do?
 # Create a patch and get them to contrib it
 # Get them to provide blanket auth for their entire fbthrift repo to be 
contributed

1 has been done but is a headache for them (and us really). 2 has been rejected 
by them in the past but if you can get it done that would be great.

 

> clarify IP rights and contributions from fbthrift 
> --
>
> Key: THRIFT-2426
> URL: https://issues.apache.org/jira/browse/THRIFT-2426
> Project: Thrift
>  Issue Type: Story
>  Components: Documentation
>Reporter: Roger Meier
>Assignee: James E. King III
>Priority: Critical
>
> We need to ensure that we have the IP rights to anything we commit from
> fbthrift and its traceable back on our dev list initiated from someone at 
> facebook.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-3055) Apache Thrift Logo

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-3055:
-

Bummer. Still like the second one from the bottom of the previous list.

> Apache Thrift Logo
> --
>
> Key: THRIFT-3055
> URL: https://issues.apache.org/jira/browse/THRIFT-3055
> Project: Thrift
>  Issue Type: Brainstorming
>  Components: Wish List
>Reporter: Jake Farrell
>Assignee: James E. King III
>Priority: Major
> Attachments: ApacheThriftLogoIdea.PNG, ApacheThriftLogoProposal.pptx, 
> ApacheThriftLogoWip3.pptx, ThriftLogo-UMLConnection.JPG, 
> ThriftLogoUmlIdeas.JPG, screenshot-1.png, screenshot-2.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Next version number: 1.0

[Randy Abernethy]

People have maturity expectations associated with a 1.0 release. So
yes, my vote to do a release might be +1 while my vote for doing the
same release as 1.0 might be -1 because I do not want to mislead the
public.

On Tue, Jan 15, 2019 at 7:32 PM James E. King III  wrote:
>
> To do this we need to retire the autoconf build and make the cmake
> environment as prolific as autoconf is, and be able to run cross tests on
> Windows.  That's a lot to ask, and we need to release at least twice in the
> upcoming year, and three times in the next.  No more once-per-year or more
> releases,  We have folks interested and engaged and we need to help them
> contribute as much as possible.
>
> Votes aren't supposed to have conditions - do they? :)
>
> - Jim
>
> On Tue, Jan 15, 2019 at 9:48 AM Randy Abernethy 
> wrote:
>
> > I am very pro the 1.0 moniker on the next release. However I would put
> > a few key criteria on it. Without these things I would be a strong -1.
> > Here's my list:
> >
> > 1. A single build system and no trace of a duplicate/confusing second
> > system (e.g. cmake everywhere)
> > 2. No claims of support for anything that does not have a passing cross
> > test
> > 3. TBinaryProtocol support everywhere
> > 4. A published specification for the RPC protocol
> > 5. 0 or close to 0 open bug jira issues (there are over 300 right now)
> >
> > Each of these is tied to this statement at the top of the Thrift home page:
> >
> > "The Apache Thrift software framework, for scalable cross-language
> > services development, combines a software stack with a code generation
> > engine to build services that work efficiently and seamlessly between
> > C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa,
> > JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages."
> >
> > I would expect a 1.0 project to have few if any known bugs, to be
> > fairly simple to build, to be specified and to do what is says (cross
> > platform rpc), which must be born out in tests.
> >
> > A 1.0 release is a great goal.
> >
> > --Randy
> >
> > On Tue, Jan 15, 2019 at 6:27 AM James E. King III 
> > wrote:
> > >
> > > I'd like us to consider the next version number to be 1.0.  The project
> > is
> > > mature enough, and some folks won't want a version 0.13.  There are
> > already
> > > a number of accumulated breaking changes in interfaces of the C++,
> > > JavaScript, and Java libraries.  C++ especially, with the break away from
> > > C++03 and boost as a link-time dependency has allowed us to change our
> > code
> > > significantly interface-wise.  In js/node.js we not have correct 64-bit
> > > integer handling.  Of course, the wire protocol is still backwards
> > > compatible.  None of that has changed (not to my awareness).  These
> > changes
> > > are documented in the top level CHANGES.md and in each language's
> > README.md
> > > file.
> > >
> > > Let's vote.
> > >
> > > [ ] +1 Next version number is 1.0.
> > > [ ] 0 Don't care
> > > [ ] -1 Next version number is 0.13.
> > >
> > > Voting ends in 72 hours, Friday January 18 at 13:00 UTC.
> > >
> > > Thanks,
> > >
> > > Jim
> >
> >
> >
> > --
> >
> > --
> > Randy Abernethy
> > Managing Partner
> > RX-M, LLC
> > randy.aberne...@rx-m.com
> > o 415-800-2922
> > c 415-624-6447
> >



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: Thrift Maven Plugin on Linux

[Randy Abernethy]

I have used the old Maven plug in as recently as 2018 on Thrift v0.10
and did not have any trouble on Ubuntu 16.04.

On Tue, Jan 15, 2019 at 7:36 PM James E. King III  wrote:
>
> Hi Adam,
>
> Definitely create an issue in Jira and submit a PR.  Things in contrib/ are
> in there either due to licensing or due to inactivity/inaction to
> maintain.  The latter can be solved with more active development.
>
> - Jim
>
> On Tue, Jan 15, 2019 at 5:18 PM Adam Marcionek <
> amarcio...@seven10storage.com> wrote:
>
> > I'm wondering if anyone uses the thrift maven plugin with any success on
> > Linux?  A couple years ago, we created an alternate version which did have
> > success. It modified the Thrift.compile() function to put /usr/local/lib as
> > the LD_LIBRARY_PATH so that it could find the thrift install.  Would this
> > be the best way to accomplish this?  If not, any suggestions?
> >
> > If so, we're happy to submit an issue and PR.  Here is the commit that
> > fixes it (its forked from the original repo, but we'll redo it in the new
> > place.)
> > https://github.com/seven10builder/maven-thrift-plugin/commit/ff83d369866a203ee8c5e0a6cc9d65db2b8199f3
> > But I have a couple questions:
> >
> >
> >   1.  Should I create an issue first in JIRA?
> >   2.  Is it OK that we added new dependencies to get this to work,
> > specifically the commons exec classes?
> >
> > Thanks for any help,
> >
> > Adam Marcionek
> >



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE] Next version number: 1.0

[Randy Abernethy]

I am very pro the 1.0 moniker on the next release. However I would put
a few key criteria on it. Without these things I would be a strong -1.
Here's my list:

1. A single build system and no trace of a duplicate/confusing second
system (e.g. cmake everywhere)
2. No claims of support for anything that does not have a passing cross test
3. TBinaryProtocol support everywhere
4. A published specification for the RPC protocol
5. 0 or close to 0 open bug jira issues (there are over 300 right now)

Each of these is tied to this statement at the top of the Thrift home page:

"The Apache Thrift software framework, for scalable cross-language
services development, combines a software stack with a code generation
engine to build services that work efficiently and seamlessly between
C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa,
JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages."

I would expect a 1.0 project to have few if any known bugs, to be
fairly simple to build, to be specified and to do what is says (cross
platform rpc), which must be born out in tests.

A 1.0 release is a great goal.

--Randy

On Tue, Jan 15, 2019 at 6:27 AM James E. King III  wrote:
>
> I'd like us to consider the next version number to be 1.0.  The project is
> mature enough, and some folks won't want a version 0.13.  There are already
> a number of accumulated breaking changes in interfaces of the C++,
> JavaScript, and Java libraries.  C++ especially, with the break away from
> C++03 and boost as a link-time dependency has allowed us to change our code
> significantly interface-wise.  In js/node.js we not have correct 64-bit
> integer handling.  Of course, the wire protocol is still backwards
> compatible.  None of that has changed (not to my awareness).  These changes
> are documented in the top level CHANGES.md and in each language's README.md
> file.
>
> Let's vote.
>
> [ ] +1 Next version number is 1.0.
> [ ] 0 Don't care
> [ ] -1 Next version number is 0.13.
>
> Voting ends in 72 hours, Friday January 18 at 13:00 UTC.
>
> Thanks,
>
> Jim



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE] Remove compiler plug-in mode

[Randy Abernethy]

[x] +1 Remove the plug-in compiler mode

On Mon, Jan 14, 2019 at 12:16 AM Jens Geyer  wrote:
>
>
>
> -Ursprüngliche Nachricht-
> From: James E. King III
> Sent: Monday, January 14, 2019 5:07 AM
> To: dev@thrift.apache.org
> Subject: [VOTE] Remove compiler plug-in mode
>
> I'd like to call a vote on removing the plug-in mode for the compiler.  It
> has caused problems with the build in the past and causes a build-time
> branch that must be supported, and to the best I can ascertain it is not
> used.  Anyone with a custom generator will build a compiler that uses it.
> No distributions package a plug-in compiler,  In all our CI builds except
> for one we disable it.
>
> Please vote:
>
> [x] +1 Remove the plug-in compiler mode.
>
> This vote will conclude in 72 hours from now at Wednesday January 16, 11:00
> PM EST/US (I believe that would be 03:00 AM on Thursday January 17).  PMC
> member votes are binding, all others are non-binding.
>


-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

[jira] [Commented] (THRIFT-3055) Apache Thrift Logo

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-3055:
-

My vote goes to the Candara font version. The Tempus is cool too but, to my 
eye, maybe a bit too stylized and not as versatile as Candara. Just my 2 cents, 
both are great and you are doing the work so either works for me!

> Apache Thrift Logo
> --
>
> Key: THRIFT-3055
> URL: https://issues.apache.org/jira/browse/THRIFT-3055
> Project: Thrift
>  Issue Type: Brainstorming
>  Components: Wish List
>Reporter: Jake Farrell
>Assignee: James E. King III
>Priority: Major
> Attachments: ApacheThriftLogoIdea.PNG, ApacheThriftLogoProposal.pptx, 
> ApacheThriftLogoWip3.pptx, ThriftLogo-UMLConnection.JPG, 
> ThriftLogoUmlIdeas.JPG, screenshot-1.png, screenshot-2.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-3055) Apache Thrift Logo

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-3055:
-

My firm will happily fund the $35 for the image if that's easier. A logo would 
be super awesome.

> Apache Thrift Logo
> --
>
> Key: THRIFT-3055
> URL: https://issues.apache.org/jira/browse/THRIFT-3055
> Project: Thrift
>  Issue Type: Brainstorming
>  Components: Wish List
>Reporter: Jake Farrell
>Assignee: James E. King III
>Priority: Major
> Attachments: ApacheThriftLogoIdea.PNG, ApacheThriftLogoWip3.pptx, 
> ThriftLogo-UMLConnection.JPG, ThriftLogoUmlIdeas.JPG, screenshot-1.png, 
> screenshot-2.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-3055) Apache Thrift Logo

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-3055:
-

>From your 28/Apr/17 07:32 post I like the second from the last one. Funky, 
>cool simple.

 

I also like the puzzle piece one you just posted above with the Apache Thrift. 
Big +1 for either of those.

> Apache Thrift Logo
> --
>
> Key: THRIFT-3055
> URL: https://issues.apache.org/jira/browse/THRIFT-3055
> Project: Thrift
>  Issue Type: Brainstorming
>  Components: Wish List
>Reporter: Jake Farrell
>Assignee: James E. King III
>Priority: Major
> Attachments: ApacheThriftLogoIdea.PNG, ApacheThriftLogoWip3.pptx, 
> ThriftLogo-UMLConnection.JPG, ThriftLogoUmlIdeas.JPG, screenshot-1.png, 
> screenshot-2.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-3924) Make C++ library build on SunOS with the Sun compiler

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-3924:
-

+1 to close this and let any Solaris users in the community reopen if they can 
jump in and help

> Make C++ library build on SunOS with the Sun compiler
> -
>
> Key: THRIFT-3924
> URL: https://issues.apache.org/jira/browse/THRIFT-3924
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
> Environment: 1.upgrade thrift from 0.9.0 to 0.9.2
> 2.SunOS
> 3./opt/SUNWspro/prod/include/CC/Cstd
> 4.CC compiler
>Reporter: Guoguang Lan
>Priority: Minor
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> when Both Clang and GNUC are not define , there is an error!
> 1.upgrade thrift from 0.9.0 to 0.9.2
> 2.SunOS
> 3./opt/SUNWspro/prod/include/CC/Cstd
> compile: CC -DHAVE_CONFIG_H -I. -I../.. -I../../lib/cpp/src/thrift 
> -I/CBB_3rdTools/server/OpenSource/src/thrift/thrift-0.9.2/boost_1_57_0//include
>  -I./src -D_POSIX_PTHREAD_SEMANTICS -D_SUN_ -DSUN 
> -I/CBB_3rdTools/server/OpenSource/src/thrift/thrift-0.9.2/openssl/include 
> -I/CBB_3rdTools/server/OpenSource/src/thrift/thrift-0.9.2/boost_1_57_0/include/boost/tr1
>  -Wextra -pedantic -g -c src/thrift/transport/TFileTransport.cpp -KPIC -DPIC 
> -o src/thrift/transport/.libs/TFileTransport.o CC: Warning: Option -Wextra 
> passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option 
> -pedantic passed to ld, if ld is invoked, ignored otherwise 
> "./src/thrift/cxxfunctional.h", line 124: Error: stdcxx is not a member of 
> apache::thrift.
> when i modify the code like this:
> `#ifdef clang
> /* Clang has two options, depending on standard library:
> - no -stdlib or -stdlib=libstdc++ set; uses GNU libstdc++.
> - -stdlib=libc++; uses LLVM libc++.
> , no 'std::tr1'. *
> The compiler itself doesn't define anything differently
> depending on the value of -stdlib, but the library headers
> will set different preprocessor options. In order to check,
> though, we have to pull in some library header.
> */
> #include
> /* With LLVM libc++, utility pulls in __config, which sets
> _LIBCPP_VERSION. */
> #if defined(_LIBCPP_VERSION)
> #define _THRIFT_USING_CLANG_LIBCXX 1
> /* With GNU libstdc++, utility pulls in bits/c++config.h,
> which sets GLIBCXX. */
> #elif defined(GLIBCXX)
> #define _THRIFT_USING_GNU_LIBSTDCXX 1
> /* No idea. /
> #else
> #error Unable to detect which C++ standard library is in use.
> #endif
> #elif GNUC
> #define _THRIFT_USING_GNU_LIBSTDCXX 1
> / No idea. */
> #else
> #error Unable to detect which C++ standard library is in use. Both Clang and 
> GNUC are not define!
> #endif`
> output:
> "./src/thrift/cxxfunctional.h", line 71: Error: #error Unable to detect which 
> C++ standard library is in use. Both Clang and GNUC are not define!.
> Thank you!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2242) Generate C++11 code

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-2242:
-

I just want to shout this loudly, Thrift Sets [at the IDL level] are unordered. 
You can implement them in a server or client with ordered sets or unordered 
sets (in C++ using the hack James mentions or with annotations in Java). 
However on the wire, you must not expect a set or map to be ordered, only a 
list.

> Generate C++11 code
> ---
>
> Key: THRIFT-2242
> URL: https://issues.apache.org/jira/browse/THRIFT-2242
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.1
>Reporter: Vitali Lovich
>Priority: Major
>
> unordered_map instead of map, unordered_set instead of set, noexcept instead 
> of throw() (unless the exact semantics of throw() are needed which seems 
> unlikely).
> It should use the shared_ptr implementation that the library is configured 
> with.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4156) Using boost spirit instead of lex and yacc

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4156:
-

While it strikes me as a cool project, to [~jking3] 's point, it is the kind of 
thing that is not going to add a ton of value to end users and it will create a 
knowledge gap for existing committers. This means we spend less time actually 
adding value for the end users in the community. If Thrift IDL was in dynamic 
development the hit might amortize well, however, if that were the case I might 
vote for a move to Python. As it is I am a -1 on this ticket.

> Using boost spirit instead of lex and yacc
> --
>
> Key: THRIFT-4156
> URL: https://issues.apache.org/jira/browse/THRIFT-4156
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Reporter: Mike Gresens
>Priority: Major
> Attachments: MyService.hpp, MyService.thrift, ast.hpp, 
> doxygen_enum.png, doxygen_service.png, doxygen_struct.png, parser.cpp
>
>
> As a developer I want to use boost spirit to get rid of lex and yacc.
> This kicks dependency to lex, flex, yacc, bison or what ever.
> This makes building easier, because only c++ code must be compiled.
> All grammar is inside the code - all c++. No need to learn ll and yy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [RESULT] [VOTE] Release Apache Thrift 0.12.0

[Randy Abernethy]

Thanks for making this happen Jim! Huge!!

On Fri, Jan 4, 2019 at 2:51 PM James E. King III  wrote:
>
> Voting has now closed.  The results are:
>
> Binding Votes:
>
> +1 [3: Randy Abernathy, Jens Geyer, James E. King III]
>  0 [0]
> -1 [0]
>
> Non-Binding Votes:
>
> +1 [1: Allen George]
>  0 [0]
> -1 [0]
>
> The vote is ***successful***, Apache Thrift 0.12.0 is officially released!
>
> Apache Thrift 0.12.0 is already up on a number of third-party package sites.
> The web site thrift.apache.org will be updated once the distribution
> mirrors sync, sometime tomorrow.  In the meantime you can use this link to
> access the official distribution files:
>
> https://www-us.apache.org/dist/thrift/0.12.0/
>
> Thanks,
>
> Jim



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

[jira] [Commented] (THRIFT-4723) Consolidate C# and netcore into new netstd language target and finally deprecate both C# and netcore bindings

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4723:
-

+1

> Consolidate C# and netcore into new netstd language target and finally 
> deprecate both C# and netcore bindings
> -
>
> Key: THRIFT-4723
> URL: https://issues.apache.org/jira/browse/THRIFT-4723
> Project: Thrift
>  Issue Type: Umbrella
>  Components: C# - Compiler, C# - Library, netcore - Compiler, netcore 
> - Library
> Environment: .NET and Mono
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
>  Labels: Umbrella
>
> There are too many differences to get C# effectively merged into netcore. 
> Because also the name is/would be misleading, the proposal is to have a new 
> *netstd* target which users can migrate to at will, not by force. The end 
> goal is of course to deprecate and remove both the existing C# as well as the 
> existing netcore bindings and only maintain netstd bindings.
> *Purpose of this umbrella ticket is only to host all sub-tasks.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4639) Sequence numbering for multiplexed protocol broken

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4639:
-

[~jking3], Thrift JavaScript does and always has depended on seq nums. It is an 
asyn language by nature and if you make multiple requests, while they will be 
returned in order, there is no way for the callback dispatcher to know which 
call back to call without the seq num. 

All servers should return whatever is passed in the seq num field back to the 
client in the response. There is a reason the C++  readMessageBegin(fname, 
mtype, seqid) signature includes seqid. While JavaScript requires sequence 
numbers many languages could benefit from seq numbers in their async impls. You 
are right though we have work to do (though each fix is trivial) to comply with 
this maxim.

I think it would be better said that:
 # Thrift Clients should not require sequence numbers, though they may use them 
 # Thrift Servers must return the seq num they receive with a request with the 
response (n.b. this is work in progress)

 

> Sequence numbering for multiplexed protocol broken
> --
>
> Key: THRIFT-4639
> URL: https://issues.apache.org/jira/browse/THRIFT-4639
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.11.0, 0.12.0
>Reporter: PH Lundblom
>Priority: Critical
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Handling of client sequence numbering for multiplexed protocol is broken.
> Current implementation uses client internal variable "seqid" which should be 
> "_seqid"
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2464) Transition cpp_type and cpp_include keywords to compiler annotations

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-2464:
-

I have a different view, it is a feature I use and find elegant and chaos free  
!/jira/images/icons/emoticons/smile.png! .

Clearly if you use an implementation type that is incompatible with the 
abstract IDL type or protocol interface you will have problems, just like if 
you don't eat you will starve, I don't think we need to police this. To your 
point, type substitution is not a feature anyone should reach for at the 
outset, rather a feature that allows Thrift to easily accommodate needs related 
to performance, version changes and customization. Many languages have multiple 
IDL-type compatible implementation-types, yet with no specific one being the 
fastest/best for all use cases (lists, vectors, ints, boxed ints, hashmaps, 
treemaps, dictionaries, counters, etc.). Also new types (especially container 
types) can show up over time (v1, v2, v3) making "the best" default hard to 
specify. This feature also allows custom types to be implemented. In none of 
these cases does the impl complexity leak into Thrift, the Thrift IDL types and 
wire serialization are unimpacted.

What is a mess is the implementation we have. We have annotations for "final", 
and Java map types then these crazy keyword impls for C++. The cpp_* kws 
predate annotations and should have been moved over with the introduction of 
annotations.

I also think we should rigorously reject new Thrift IDL types as they break the 
world and spawn huge amounts of work throughout the platform (every lib, every 
protocol) [I am not a fan of the self referential types we have half 
implemented]. In a tool chain used for cross platform compatibility, changing 
the IDL type support is the worst thing we can do and should really only happen 
when extreme benefits are present. This view makes me that much more interested 
in living with the simple and elegant Thrift IDL types yet having the option to 
choose or create my own implementations without impacting client or having to 
modify Thrift at all.

 

 

> Transition cpp_type and cpp_include keywords to compiler annotations
> 
>
> Key: THRIFT-2464
> URL: https://issues.apache.org/jira/browse/THRIFT-2464
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Affects Versions: 0.9.2
> Environment: C++
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
>
> The cpp_type and cpp_include keywords provide a useful feature but are 
> language specific. In keeping with the trend of moving the interface language 
> to a clean cross implementation language abstraction, these two keywords 
> should be transitioned to annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2927) Statistic function support (call analytics: duration, success-count, failure-count, etc..)

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-2927:
-

Sounds like consensus. Should we close this?

> Statistic function support (call analytics: duration, success-count, 
> failure-count, etc..)
> --
>
> Key: THRIFT-2927
> URL: https://issues.apache.org/jira/browse/THRIFT-2927
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.2
> Environment: linux c++
>Reporter: Shi Jun
>Priority: Major
>
> As a RPC framework, Thrift should support some statistic function, such as 
> latency、call times、failure rate and so on. And all these things can be done 
> by the framework, applications just need to use a make argument to open the 
> statistic function switch or not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Support for lib/csharp .NET Framework before 4.5?

[Randy Abernethy]

Ya, I think that is a prereq for sure.

On Thu, Jan 3, 2019 at 11:01 AM Jens Geyer  wrote:
>
>
> Can we make sure all fixes to the C# bindings made in the meantime are also
> in netcore? Otherwise I'm against it.
>
>
> -Ursprüngliche Nachricht-
> From: Randy Abernethy
> Sent: Thursday, January 3, 2019 2:34 AM
> To: dev@thrift.apache.org
> Subject: Re: Support for lib/csharp .NET Framework before 4.5?
>
> @jking  yes /lib/netcore is the .Net Core impl, I am suggesting we
> ultimately remove /lib/csharp, which is the .Net Framework impl. I am
> _not_ suggesting we just del it, I am suggesting we direct all new
> contrib to netcore and stop taking pulls for csharp and create an
> incentive to port everything in C# missing from netcore (simple in
> most cases I've looked at).
>
> On Wed, Jan 2, 2019 at 1:11 PM Allen George  wrote:
> >
> > So, just to be clear, proposed language removals are:
> >
> > Approved:
> >
> > Cocoa
> > C++03 or less
> >
> > Open:
> >
> > JavaME (potential; I’ll look at setting up an Android CI environment and
> > using the standard Java lib there to see if it’s feasible)
> > .net 4.5 or less (no vote yet)
> > Silverlight
> > One of nodets/ts (can we end up only with one, or are there legitimate
> > differences between the two was the question)
> >
> > Allen
> >
> >
> > On January 2, 2019 at 15:55:41, Jens Geyer (jensge...@hotmail.com) wrote:
> > Hi,
> >
> > start a vote. A while ago some people claimed that 4.5+ was not available
> > on
> > their particular subset of Mono. I tend to think that this is no longer
> > the
> > case anymore, so we should drop anything below 4.5.
> >
> > And since wer'e at it: Same for Silverlight, if you ask me. It is still
> > supported until 2012 by Microsoft, but I doubt if anyone really uses it
> > except for maintaining legacy projects. Maybe we should have a vote about
> > that too.
> >
> > Have fun,
> > JensG
> >
> >
> > -Ursprüngliche Nachricht-
> > From: James E. King III
> > Sent: Wednesday, January 2, 2019 9:08 PM
> > To: dev@thrift.apache.org
> > Subject: Re: Support for lib/csharp .NET Framework before 4.5?
> >
> > We already support netstandard2.0 (.NET Core SDK 2.0) and build
> > lib/netcore and run cross tests with that. The docker build image
> > (build/docker/ubuntu-bionic/Dockerfile) defines the version we build
> > against. I was wondering about the .NET 3.5 in lib/csharp and
> > whether we really need a 3.5 and a 4.5 csproj. It's not a big deal
> > really, just a small simplification, but if a lot of people are still on
> > .NET 3.5 then we may decide not to remove support for it yet.
> >
> > - Jim
> >
> > On Wed, Jan 2, 2019 at 12:55 PM Randy Abernethy 
> > wrote:
> >
> > > While we're in the process of dropping old lang vers, I think we
> > > should consider only tracking the latest version of .Net Core (2.2).
> > > Core is CLI build friendly and cross platform. The .Net Framework can
> > > run all Core apps AFAIK so no loss in dropping the Framework for
> > > forward looking stuff.
> > >
> > > On Wed, Jan 2, 2019 at 6:24 AM James E. King III 
> > wrote:
> > > >
> > > > We currently have two projects to support.NET 3.5 and .NET 4.5. The
> > > > differences are minor but it causes us to have to build two projects.
> > > > Do
> > > > we need to continue to maintain support for .NET < 4.5 ?
> > > >
> > > > - Jim
> > >
> > >
> > >
> > > --
> > >
> > > --
> > > Randy Abernethy
> > > Managing Partner
> > > RX-M, LLC
> > > randy.aberne...@rx-m.com
> > > o 415-800-2922
> > > c 415-624-6447
> > >
>
>
>
> --
>
> --
> Randy Abernethy
> Managing Partner
> RX-M, LLC
> randy.aberne...@rx-m.com
> o 415-800-2922
> c 415-624-6447
>


-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

[jira] [Commented] (THRIFT-2927) Statistic function support (call analytics: duration, success-count, failure-count, etc..)

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-2927:
-

There are a lot of external solutions for observability. For example, the 
service mesh model often used in cloud native systems provides 
monitoring/metering access points at each service ingress/egress (e.g. 
[https://istio.io/).]  There are also cross platform tracing solutions that 
offer some of these features (e.g. [https://opentracing.io/,] 
[https://www.jaegertracing.io/).] To Jens' point leaving these concerns as a 
choice external to thrift makes it optional and allows people to make choices 
that will work for all of their platform elements (Thrift, messaging, REST, 
custom, etc.).

> Statistic function support (call analytics: duration, success-count, 
> failure-count, etc..)
> --
>
> Key: THRIFT-2927
> URL: https://issues.apache.org/jira/browse/THRIFT-2927
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.2
> Environment: linux c++
>Reporter: Shi Jun
>Priority: Major
>
> As a RPC framework, Thrift should support some statistic function, such as 
> latency、call times、failure rate and so on. And all these things can be done 
> by the framework, applications just need to use a make argument to open the 
> statistic function switch or not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Support for lib/csharp .NET Framework before 4.5?

[Randy Abernethy]

Hey Jens,
Problems with a .Net Standard lib?
--Randy

On Thu, Jan 3, 2019 at 10:39 AM Jens Geyer  wrote:
>
> Great idea. Not.
>
> -Ursprüngliche Nachricht-----
> From: Randy Abernethy
> Sent: Thursday, January 3, 2019 7:18 PM
> To: dev@thrift.apache.org
> Subject: Re: Support for lib/csharp .NET Framework before 4.5?
>
> A .Net Standard library should work with a .NET Core app, a .NET
> Framework/Mono app or a Xamarin app. I think it would be best to make
> Thrift a .net standard lib exclusively. Given our lack of need for GUI
> features it seems we should be easily able to comply with .Net
> Standard. Probably should get rid of csharp (and and maybe netcore)
> dir and merge everything (into a netstandard dir?). If .Net Framework
> 4.5 support is important we could do .net Standard 1.0. For testing
> netcore seems the right approach as it is likely the choice for cloud
> native microservices and offers the most direct impl of the standard.
>
>
>
> On Thu, Jan 3, 2019 at 7:45 AM James E. King III  wrote:
> >
> > To clarify, voting on C++03 and Cocoa ends tomorrow.
> > We'll call for votes on others.
> >
> > If we could merge netcore into lib/csharp and have a single project
> > produce
> > both net45 and netstandard2.0 targets that would be ideal...  I'm not sure
> > how compatible the code is though.
> >
> > On Wed, Jan 2, 2019 at 8:34 PM Randy Abernethy 
> > wrote:
> >
> > > @jking  yes /lib/netcore is the .Net Core impl, I am suggesting we
> > > ultimately remove /lib/csharp, which is the .Net Framework impl. I am
> > > _not_ suggesting we just del it, I am suggesting we direct all new
> > > contrib to netcore and stop taking pulls for csharp and create an
> > > incentive to port everything in C# missing from netcore (simple in
> > > most cases I've looked at).
> > >
> > > On Wed, Jan 2, 2019 at 1:11 PM Allen George 
> > > wrote:
> > > >
> > > > So, just to be clear, proposed language removals are:
> > > >
> > > > Approved:
> > > >
> > > > Cocoa
> > > > C++03 or less
> > > >
> > > > Open:
> > > >
> > > > JavaME (potential; I’ll look at setting up an Android CI environment
> > > > and
> > > > using the standard Java lib there to see if it’s feasible)
> > > > .net 4.5 or less (no vote yet)
> > > > Silverlight
> > > > One of nodets/ts (can we end up only with one, or are there legitimate
> > > > differences between the two was the question)
> > > >
> > > > Allen
> > > >
> > > >
> > > > On January 2, 2019 at 15:55:41, Jens Geyer (jensge...@hotmail.com)
> > > wrote:
> > > > Hi,
> > > >
> > > > start a vote. A while ago some people claimed that 4.5+ was not
> > > > available
> > > > on
> > > > their particular subset of Mono. I tend to think that this is no
> > > > longer
> > > the
> > > > case anymore, so we should drop anything below 4.5.
> > > >
> > > > And since wer'e at it: Same for Silverlight, if you ask me. It is
> > > > still
> > > > supported until 2012 by Microsoft, but I doubt if anyone really uses
> > > > it
> > > > except for maintaining legacy projects. Maybe we should have a vote
> > > > about
> > > > that too.
> > > >
> > > > Have fun,
> > > > JensG
> > > >
> > > >
> > > > -Ursprüngliche Nachricht-
> > > > From: James E. King III
> > > > Sent: Wednesday, January 2, 2019 9:08 PM
> > > > To: dev@thrift.apache.org
> > > > Subject: Re: Support for lib/csharp .NET Framework before 4.5?
> > > >
> > > > We already support netstandard2.0 (.NET Core SDK 2.0) and build
> > > > lib/netcore and run cross tests with that. The docker build image
> > > > (build/docker/ubuntu-bionic/Dockerfile) defines the version we build
> > > > against. I was wondering about the .NET 3.5 in lib/csharp and
> > > > whether we really need a 3.5 and a 4.5 csproj. It's not a big deal
> > > > really, just a small simplification, but if a lot of people are still
> > > > on
> > > > .NET 3.5 then we may decide not to remove support for it yet.
> > > >
> > > > - Jim
> > > >
> > > > On Wed, Jan 2, 2019 at 12:55 PM Randy Abernethy <
> > > randy.aberne...

Re: Support for lib/csharp .NET Framework before 4.5?

[Randy Abernethy]

A .Net Standard library should work with a .NET Core app, a .NET
Framework/Mono app or a Xamarin app. I think it would be best to make
Thrift a .net standard lib exclusively. Given our lack of need for GUI
features it seems we should be easily able to comply with .Net
Standard. Probably should get rid of csharp (and and maybe netcore)
dir and merge everything (into a netstandard dir?). If .Net Framework
4.5 support is important we could do .net Standard 1.0. For testing
netcore seems the right approach as it is likely the choice for cloud
native microservices and offers the most direct impl of the standard.



On Thu, Jan 3, 2019 at 7:45 AM James E. King III  wrote:
>
> To clarify, voting on C++03 and Cocoa ends tomorrow.
> We'll call for votes on others.
>
> If we could merge netcore into lib/csharp and have a single project produce
> both net45 and netstandard2.0 targets that would be ideal...  I'm not sure
> how compatible the code is though.
>
> On Wed, Jan 2, 2019 at 8:34 PM Randy Abernethy 
> wrote:
>
> > @jking  yes /lib/netcore is the .Net Core impl, I am suggesting we
> > ultimately remove /lib/csharp, which is the .Net Framework impl. I am
> > _not_ suggesting we just del it, I am suggesting we direct all new
> > contrib to netcore and stop taking pulls for csharp and create an
> > incentive to port everything in C# missing from netcore (simple in
> > most cases I've looked at).
> >
> > On Wed, Jan 2, 2019 at 1:11 PM Allen George 
> > wrote:
> > >
> > > So, just to be clear, proposed language removals are:
> > >
> > > Approved:
> > >
> > > Cocoa
> > > C++03 or less
> > >
> > > Open:
> > >
> > > JavaME (potential; I’ll look at setting up an Android CI environment and
> > > using the standard Java lib there to see if it’s feasible)
> > > .net 4.5 or less (no vote yet)
> > > Silverlight
> > > One of nodets/ts (can we end up only with one, or are there legitimate
> > > differences between the two was the question)
> > >
> > > Allen
> > >
> > >
> > > On January 2, 2019 at 15:55:41, Jens Geyer (jensge...@hotmail.com)
> > wrote:
> > > Hi,
> > >
> > > start a vote. A while ago some people claimed that 4.5+ was not available
> > > on
> > > their particular subset of Mono. I tend to think that this is no longer
> > the
> > > case anymore, so we should drop anything below 4.5.
> > >
> > > And since wer'e at it: Same for Silverlight, if you ask me. It is still
> > > supported until 2012 by Microsoft, but I doubt if anyone really uses it
> > > except for maintaining legacy projects. Maybe we should have a vote about
> > > that too.
> > >
> > > Have fun,
> > > JensG
> > >
> > >
> > > -Ursprüngliche Nachricht-
> > > From: James E. King III
> > > Sent: Wednesday, January 2, 2019 9:08 PM
> > > To: dev@thrift.apache.org
> > > Subject: Re: Support for lib/csharp .NET Framework before 4.5?
> > >
> > > We already support netstandard2.0 (.NET Core SDK 2.0) and build
> > > lib/netcore and run cross tests with that. The docker build image
> > > (build/docker/ubuntu-bionic/Dockerfile) defines the version we build
> > > against. I was wondering about the .NET 3.5 in lib/csharp and
> > > whether we really need a 3.5 and a 4.5 csproj. It's not a big deal
> > > really, just a small simplification, but if a lot of people are still on
> > > .NET 3.5 then we may decide not to remove support for it yet.
> > >
> > > - Jim
> > >
> > > On Wed, Jan 2, 2019 at 12:55 PM Randy Abernethy <
> > randy.aberne...@rx-m.com>
> > > wrote:
> > >
> > > > While we're in the process of dropping old lang vers, I think we
> > > > should consider only tracking the latest version of .Net Core (2.2).
> > > > Core is CLI build friendly and cross platform. The .Net Framework can
> > > > run all Core apps AFAIK so no loss in dropping the Framework for
> > > > forward looking stuff.
> > > >
> > > > On Wed, Jan 2, 2019 at 6:24 AM James E. King III 
> > > wrote:
> > > > >
> > > > > We currently have two projects to support.NET 3.5 and .NET 4.5. The
> > > > > differences are minor but it causes us to have to build two projects.
> > > > > Do
> > > > > we need to continue to maintain support for .NET < 4.5 ?
> > > > >
> > > > > - Jim
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > --
> > > > Randy Abernethy
> > > > Managing Partner
> > > > RX-M, LLC
> > > > randy.aberne...@rx-m.com
> > > > o 415-800-2922
> > > > c 415-624-6447
> > > >
> >
> >
> >
> > --
> >
> > --
> > Randy Abernethy
> > Managing Partner
> > RX-M, LLC
> > randy.aberne...@rx-m.com
> > o 415-800-2922
> > c 415-624-6447
> >



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

[jira] [Commented] (THRIFT-2464) Transition cpp_type and cpp_include keywords to compiler annotations

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-2464:
-

This is covered pretty thoroughly in chapter 5 of the Programmer's Guide to 
Apache Thrift. I agree Thrift should supply standard cross platform types that 
work across all languages. However there are multiple layers of abstraction in 
Thrift:
 # IDL - the conceptual types
 # wire - the protocol based serialization of the types
 # language - the language specific implementation of the types

It is in #3 that the impl may need to be (or could benefit from) being tweaked. 
The IDL compiler might generate a Java TreeMap for a Thrift Map or it might 
generate a HashMap. We can not say which is the right answer without a use case.

It is also important to note that the language impl has (must have) no impact 
on the wire or conceptual type representations. Adding types to the IDL or wire 
layers is a breaking Thrift wide interface change and I think should be avoided 
unless tremendous benefit is imparted. On the other hand, changing impl types 
is by definition an implementation detail that no one on the other side of the 
RPC should care about.

In short, I agree with [~jking3] that the cpp_type and cpp_include keywords 
should be removed but the functionality should be preserved through Thrift 
annotations. So my vote is that until we have the annotations working we do not 
remove the keywords.

The annotation solution would look something like this:

{{(cpp.include = "unordered_map")}}

{{exception BadFishes {}}
{{    1: map (cpp.type "std::unordered_map")   
fish_errors}}
{{}}}

Should be an easy change.

 

> Transition cpp_type and cpp_include keywords to compiler annotations
> 
>
> Key: THRIFT-2464
> URL: https://issues.apache.org/jira/browse/THRIFT-2464
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Affects Versions: 0.9.2
> Environment: C++
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
>
> The cpp_type and cpp_include keywords provide a useful feature but are 
> language specific. In keeping with the trend of moving the interface language 
> to a clean cross implementation language abstraction, these two keywords 
> should be transitioned to annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Support for lib/csharp .NET Framework before 4.5?

[Randy Abernethy]

@jking  yes /lib/netcore is the .Net Core impl, I am suggesting we
ultimately remove /lib/csharp, which is the .Net Framework impl. I am
_not_ suggesting we just del it, I am suggesting we direct all new
contrib to netcore and stop taking pulls for csharp and create an
incentive to port everything in C# missing from netcore (simple in
most cases I've looked at).

On Wed, Jan 2, 2019 at 1:11 PM Allen George  wrote:
>
> So, just to be clear, proposed language removals are:
>
> Approved:
>
> Cocoa
> C++03 or less
>
> Open:
>
> JavaME (potential; I’ll look at setting up an Android CI environment and
> using the standard Java lib there to see if it’s feasible)
> .net 4.5 or less (no vote yet)
> Silverlight
> One of nodets/ts (can we end up only with one, or are there legitimate
> differences between the two was the question)
>
> Allen
>
>
> On January 2, 2019 at 15:55:41, Jens Geyer (jensge...@hotmail.com) wrote:
> Hi,
>
> start a vote. A while ago some people claimed that 4.5+ was not available
> on
> their particular subset of Mono. I tend to think that this is no longer the
> case anymore, so we should drop anything below 4.5.
>
> And since wer'e at it: Same for Silverlight, if you ask me. It is still
> supported until 2012 by Microsoft, but I doubt if anyone really uses it
> except for maintaining legacy projects. Maybe we should have a vote about
> that too.
>
> Have fun,
> JensG
>
>
> -Ursprüngliche Nachricht-
> From: James E. King III
> Sent: Wednesday, January 2, 2019 9:08 PM
> To: dev@thrift.apache.org
> Subject: Re: Support for lib/csharp .NET Framework before 4.5?
>
> We already support netstandard2.0 (.NET Core SDK 2.0) and build
> lib/netcore and run cross tests with that. The docker build image
> (build/docker/ubuntu-bionic/Dockerfile) defines the version we build
> against. I was wondering about the .NET 3.5 in lib/csharp and
> whether we really need a 3.5 and a 4.5 csproj. It's not a big deal
> really, just a small simplification, but if a lot of people are still on
> .NET 3.5 then we may decide not to remove support for it yet.
>
> - Jim
>
> On Wed, Jan 2, 2019 at 12:55 PM Randy Abernethy 
> wrote:
>
> > While we're in the process of dropping old lang vers, I think we
> > should consider only tracking the latest version of .Net Core (2.2).
> > Core is CLI build friendly and cross platform. The .Net Framework can
> > run all Core apps AFAIK so no loss in dropping the Framework for
> > forward looking stuff.
> >
> > On Wed, Jan 2, 2019 at 6:24 AM James E. King III 
> wrote:
> > >
> > > We currently have two projects to support.NET 3.5 and .NET 4.5. The
> > > differences are minor but it causes us to have to build two projects.
> > > Do
> > > we need to continue to maintain support for .NET < 4.5 ?
> > >
> > > - Jim
> >
> >
> >
> > --
> >
> > --
> > Randy Abernethy
> > Managing Partner
> > RX-M, LLC
> > randy.aberne...@rx-m.com
> > o 415-800-2922
> > c 415-624-6447
> >



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: Thrift compiler "plug-in" mode

[Randy Abernethy]

Ditto, simple is faster, more reliable, more maintainable, more ...
Let's remove the plugin feature.

I would put rewriting the compiler very low on the priority list.
Maybe incrementally updating the existing compiler code to C++11/17 as
we go makes sense but I don't see rewriting it as a good use of the
limited contributor base's time.

On Wed, Jan 2, 2019 at 5:58 AM Allen George  wrote:
>
> The company I work at uses Thrift (as well as scrooge), and we don’t use
> the plug ins.
>
> That said, the previous company I worked at used plugins for the _protobuf_
> compiler, but that’s a completely different model, and the use of plugins
> there is the norm IIRC.
>
> I’d vote for simplifying the code base and removing plugins.
>
> Allen
>
>
> On January 2, 2019 at 08:43:40, James E. King III (jk...@apache.org) wrote:
> The addition of a "plug-in" compiler mode has made the build of the
> compiler fairly complex. There are now two kinds of compilers - one with
> all the code generators statically linked, and one where all the code
> generators are dynamically linked. I believe the original goal was to
> allow third parties to add their own code generator without having to
> maintain their own fork of thrift?
>
> As part of all the CI builds we effectively disable the plug-in part of the
> compiler. It had to be disabled for all distribution builds as well.
> Nobody distributes a plug-in compiler. As such, if anyone is using it,
> they are already building their own compiler, so they are maintaining their
> own fork. Therefore there is no real benefit.
>
> I believe the added complexity that this mode brings to the project
> overshadows any possible benefits of allowing for compiler plug-ins with a
> linked compiler like the one we have. This new compiler mode hasn't been
> touched in a couple years now and only one person has expressed interest in
> pull requests.
>
> If we want to have a more extensible compiler environment, we should
> consider rewriting it in another more flexible language like python. It
> would be easy for folks to extend it from there, however it would force a
> requirement on python to generate code.
>
> I'd really like us to consider eliminating the plug-in mode of the compiler
> to simplify the compiler build and have fewer overall build targets.
> Thoughts? Does anybody use the compiler plug-in mode?
>
> - Jim



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: Support for lib/csharp .NET Framework before 4.5?

[Randy Abernethy]

While we're in the process of dropping old lang vers, I think we
should consider only tracking the latest version of .Net Core (2.2).
Core is CLI build friendly and cross platform. The .Net Framework can
run all Core apps AFAIK so no loss in dropping the Framework for
forward looking stuff.

On Wed, Jan 2, 2019 at 6:24 AM James E. King III  wrote:
>
> We currently have two projects to support.NET 3.5 and .NET 4.5.  The
> differences are minor but it causes us to have to build two projects.  Do
> we need to continue to maintain support for .NET < 4.5 ?
>
> - Jim



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

[jira] [Commented] (THRIFT-4710) Move all website content to markdown within the project

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4710:
-

In my experience putting docs and code together is a good way of reducing 
duplicate effort, keeping code/docs in sync and keeping related things in the 
same place. These principles are the reasons for Javadoc, Pydoc, etc. The 
humans create the docs as they code and commit both together and then the 
automation renders the content into whatever format(s) required (html, pdf, 
etc.).

I think the above suggestion of a single pull request is a really important 
feature we should try to enable. The PR should include the code, the tests and 
the docs.

Another thought is, as a developer, when I clone a repo, getting the code and 
docs together is an uptick not an inconvenience. The MDs are small and there 
should probably be only one/zero (readme.md?) per directory. I don't think 
we'll need to worry about images as our doc images will be mainly code snippets.

 

My 2 cents

> Move all website content to markdown within the project
> ---
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.12.0
>Reporter: James E. King III
>Priority: Major
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Apache Thrift third party package management locations

[Randy Abernethy]

nuget: https://www.nuget.org/packages/ApacheThrift/


On Sun, Dec 30, 2018 at 1:27 PM James E. King III  wrote:
>
> Please let me know what third party package managers I'm missing from the
> following list:
>
> * Third party package manager links:
>   - [dart] https://pub.dartlang.org/packages/thrift
>   - [dlang] https://code.dlang.org/packages/apache-thrift
>   - [haskell] https://hackage.haskell.org/package/thrift
>   - [npmjs] https://www.npmjs.com/package/thrift
>   - [perl] https://metacpan.org/release/Thrift
>   - [php] https://packagist.org/packages/apache/thrift
>   - [pypi] https://pypi.org/project/thrift
>   - [rust] https://crates.io/crates/thrift
>
> Thanks,
>
> Jim



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE] Proposal to deprecate cocoa support as of 0.12.0

[Randy Abernethy]

+1

On Sun, Dec 30, 2018 at 6:50 AM James E. King III  wrote:
>
> Advantages:
>
>   1. Simplify the compiler code (fewer branches).
>   2. Shrink the backlog.
>
> Disadvantages:
>
>   1. Folks who need cocoa support are stuck at 0.12.0
>
> General sentiment in discussions was that cocoa is no
> longer being used and everybody is transitioning to
> Swift.
>
> [ ] +1 Deprecate cocoa as of 0.12.0, use swift next release.
> [ ] -1 Keep cocoa support in thrift going forward.
>
> The vote is open until Friday, January 04, at 20:00 UTC due
> to the holidays and passes if at least three positive votes
> from the active PMC group are cast.
>
> For folks not in the Thrift PMC, your comments are still
> quite welcome on the matter, and may help folks make a
> decision.
>
> Thanks,
>
> Jim King, PMC Member, Apache Thrift



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE] Proposal to deprecate C++03 support as of 0.12.0

[Randy Abernethy]

+1

On Sun, Dec 30, 2018 at 6:47 AM James E. King III  wrote:
>
> Advantages:
>
>   1. Simplify the C++ runtime implementation mainly
>  in the areas of threading.
>   2. Resolve platform porting issues.
>   3. Eliminate the dependency on boost for runtime.
>
> Disadvantages:
>
>   1. Folks who need C++03 support are stuck at 0.12.0
>
> Other projects like boost are beginning to move forward
> as well.  I think it's time we do the same, so I would
> like to call out comments and a vote.
>
> [ ] +1 Deprecate C++03 as of 0.12.0, use C++11 next release.
> [ ] -1 Keep C++03 support in thrift going forward.
>
> The vote is open until Friday, January 04, at 20:00 UTC due
> to the holidays and passes if at least three positive votes
> from the active PMC group are cast.
>
> For folks not in the Thrift PMC, your comments are still
> quite welcome on the matter, and may help folks make a
> decision.
>
> Thanks,
>
> Jim King, PMC Member, Apache Thrift



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

Re: [VOTE] Release Apache Thrift 0.12.0 (RC0)

[Randy Abernethy]

+1

On Sun, Dec 30, 2018 at 8:10 AM Allen George  wrote:
>
> +1
>
>
> 
> From: James E. King III 
> Sent: Sunday, December 30, 2018 7:58 AM
> To: dev@thrift.apache.org
> Subject: [VOTE] Release Apache Thrift 0.12.0 (RC0)
>
> Apache Thrift PMC Members,
>
> While thrift 0.12.0 was tagged and announced as a release it was not done
> so according to typical ASF standards (that's on me). One of the standards
> is to publish binaries and archives and sign them, which is what I am doing
> now (along with a significant update of the release documentation).
> Therefore I have created a 0.12.0-rc0 release archive to vote for release:
>
> The tag to be voted on is v0.12.0 (commit 384647d):
> https://github.com/apache/thrift/tree/v0.12.0
>
> The release files, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/thrift/0.12.0-rc0/
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/jking.asc
>
> Please vote on releasing these artifacts as Apache Thrift 0.12.0!
>
> The vote is open until Friday, January 04, at 20:00 UTC due to the holidays
> and passes if at least three positive votes from the active PMC group are
> cast.
> If the vote fails we will abandon 0.12.0 and immediately create a 0.12.1
> release
> that goes through the proper release process including voting before tag
> and upload to
> third party package managers.
>
> [ ] +1 Release these artifacts as Apache Thrift 0.12.0
> [ ] -1 Do not release this package because ... (say why!)
>
> The CHANGES file contains a complete list of changes in the release:
> https://raw.githubusercontent.com/apache/thrift/v0.12.0/CHANGES
>
> There are some late-breaking release notes for known issues found during
> the release process:
>
> - [dart] the license file in lib/dart was not named correctly to work
> with dart pub however this was corrected before `pub publish`. This change
> will be pulled into master when 0.12.0 is manually merged into master.
> - [perl] the module version was set to 'v0.12.0_0' instead of 'v0.12.0'
> however this was corrected in the CPAN upload. This change does not affect
> master. It will not affect usage.
> - [swift] the Thrift.podspec "s.source:tag" specified '0.12.0' instead of
> 'v0.12.0'. This may still be functional due to the 0.12.0 branch which is
> identical to the v0.12.0 tag.
> - [swift] the Thrift-swift3.podspec "s.source:tag" specified '0.12.0'
> instead of 'v0.12.0' This may still be functional due to the 0.12.0 branch
> which is identical to the v0.12.0 tag.
>
> To learn more about Apache Thrift, please see
> https://thrift.apache.org/



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

[jira] [Commented] (THRIFT-4710) Abandon Apache CMS in favor of a different website content management system

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4710:
-

Per mail list disc., big +1 for all github style MD based docs. In tree would 
be my pref.

> Abandon Apache CMS in favor of a different website content management system
> 
>
> Key: THRIFT-4710
> URL: https://issues.apache.org/jira/browse/THRIFT-4710
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation, Website
>Affects Versions: 0.12.0
>Reporter: James E. King III
>Priority: Blocker
>
> Recent changes in Apache infrastructure has made it impossible to use the 
> existing ASF CMS system to manage the Apache Thrift web site.  We need to 
> extract and move the content somewhere else.  For reference, see:
> https://issues.apache.org/jira/browse/INFRA-17519
> This is a bunch of work nobody was expecting to have to do.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4705) Update packages and maintainer list on nuget

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4705:
-

Just added you. It is pending (thinking you'll be active once you respond to 
the invite email but can't remember the exact process flow). LMK if you need 
anything else on this.

> Update packages and maintainer list on nuget
> 
>
> Key: THRIFT-4705
> URL: https://issues.apache.org/jira/browse/THRIFT-4705
> Project: Thrift
>  Issue Type: Task
>  Components: C# - Library
>Affects Versions: 0.10.0, 0.11.0, 0.12.0
>Reporter: James E. King III
>Assignee: Jake Farrell
>Priority: Critical
>
> [~jfarrell] [~codesf] please update the list of maintainers on nuget to 
> include other release managers.  My account username on nuget is "jking3".  
> The latest package on nuget is 0.9.3 - I can upload 0.10.0 through 0.12.0 
> once I have permission.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4697) Create updated release procedures

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4697:
-

Discussion on another thread suggested moving the web site (docs for the 
project) to pure markdown. I think it would simplify things, and thus, 
incentivize more documentation. One suggestion was to create a separate docs 
repo, personally i think it would be easiest to keep it in tree if pos.

 

Any thoughts on this?

> Create updated release procedures
> -
>
> Key: THRIFT-4697
> URL: https://issues.apache.org/jira/browse/THRIFT-4697
> Project: Thrift
>  Issue Type: Documentation
>  Components: Documentation
>Affects Versions: 0.12.0
>Reporter: James E. King III
>Assignee: James E. King III
>Priority: Major
>
> During the 0.12.0 release cycle I took a lot of notes.  This needs to be 
> codified and checked in as markdown, so the web site can pull it in.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: C++03 and Thrift 0.12.0++

[Randy Abernethy]

+1 for dropping 03 support going forward.

On Wed, Dec 26, 2018 at 9:03 AM James E. King III  wrote:
>
> I posted a message on the user mailing list and nobody replied.
>
> I'd like to designate thrift-0.12.0 the last thrift release that supports
> C++03 for the runtime library.  There is an effort underway (albeit
> stalled) to convert to using C++11 items over boost.  This is tracked in
> THRIFT-4441 <https://issues.apache.org/jira/browse/THRIFT-4441> in Jira.
> Having two runtime libraries (one that uses boost and one that uses C++11)
> will be a problem for downstream packagers.  It will also simplify
> THRIFT-4441 and allow it to be completed.  For now the unit tests will
> still require boost for Boost.Test, since many tests use it.  We could
> convert to gtest (gmock) here.  Finally, with the removal of boost from the
> C++ library we will also remove the posix and boost thread classes, and
> rename the std thread class to be the only thread class, removing some
> nasty non-inherited implementation build decisions.  In fact a number of
> things in the threading area may end up being simplified.
>
> As a reference point on C++03, Boost is starting to move away from C++03
> support.  It's now on a per-repository-maintainer decision.  Also, folks
> who need boost and C++03 support can use 0.12.0 or earlier.
>
> Are there any objections?
>
> - Jim



-- 

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.aberne...@rx-m.com
o 415-800-2922
c 415-624-6447

[jira] [Commented] (THRIFT-4678) add noexcept cpp generator option

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4678:
-

Big +1 for removing all dependencies on boost. Love boost but given all of the 
possible environments people might want to use Thrift in and how fundamental a 
utility it is for people, I think we should aggressively, across the board, 
keep deps to a min. Thrift should work with boost but not require it.

The one problem area is tests. Our C++ solution right now is boost/test and it 
is probably best to leave it in place but of course this does not impact the 
runtime lib or sources.

> add noexcept cpp generator option
> -
>
> Key: THRIFT-4678
> URL: https://issues.apache.org/jira/browse/THRIFT-4678
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.11.0
>Reporter: yuanyuan chen
>Priority: Minor
>
> The C++11 standard has deprecated the usage of throw() to express 
> exceptions,so to avoid warnings from the compiler,I think this option is 
> useful.
> I have a pull request in github,this issue is created to track it.
> Some questions remain:
> 1.Should we change the runtime c++ library to use BOOST_NOEXCEPT_OR_NOTHROW?
> 2.Should we add an control option to enable all c++11 options like 
> moveable_types .etc?
> 3.Should we begin to support C+17 features? I think std::optional should be 
> used to implement optional keyword,but this is clearly an API breaking 
> change,so we need an c+17 control option.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4574) Add NanoPb-like support

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4574:
-

I agree, It would be nice to have a pure C implementation of Thrift. Patches 
welcome!

> Add NanoPb-like support
> ---
>
> Key: THRIFT-4574
> URL: https://issues.apache.org/jira/browse/THRIFT-4574
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Anatol Pomozov
>Priority: Minor
>
> Thrift has a support for C language called c_glib. This generator creates a 
> stub for C language that uses quite glib library. glib library is quite heavy 
> dependency and for some cases (like low level software) is not acceptable. 
> One need a generator that does not have any dependencies to third-party libs 
> and ideally neither to libc.
> nanopb project tries to achieve it for Protobufs. It would be great to see 
> something similar for Thrift. Here is more information about nanopb 
> [http://jpa.kapsi.fi/nanopb/docs/concepts.html]
> There is an attempt to implement such generator 
> [https://github.com/markrileybot/thrift-nano] but it might require additional 
> efforts to make the implementation up-to-date and complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4574) Add NanoPb-like support

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-4574:

Issue Type: Improvement  (was: Bug)

> Add NanoPb-like support
> ---
>
> Key: THRIFT-4574
> URL: https://issues.apache.org/jira/browse/THRIFT-4574
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Anatol Pomozov
>Priority: Minor
>
> Thrift has a support for C language called c_glib. This generator creates a 
> stub for C language that uses quite glib library. glib library is quite heavy 
> dependency and for some cases (like low level software) is not acceptable. 
> One need a generator that does not have any dependencies to third-party libs 
> and ideally neither to libc.
> nanopb project tries to achieve it for Protobufs. It would be great to see 
> something similar for Thrift. Here is more information about nanopb 
> [http://jpa.kapsi.fi/nanopb/docs/concepts.html]
> There is an attempt to implement such generator 
> [https://github.com/markrileybot/thrift-nano] but it might require additional 
> efforts to make the implementation up-to-date and complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE]: Move from old asf git to GitBox

[Randy Abernethy]

I think I already +1ed this but just in case:

+1

On Wed, Mar 14, 2018 at 8:44 AM, Jake Farrell  wrote:

> private@ is for discussions and votes for either a new committer or pmc
> member and any project issues that require some discretion. all other
> discussions and votes should occur on the dev@ list so the community can
> be
> engaged with them. Votes on the dev@ list still require a minimum of 3
> binding votes from a PMC member unless it involves code modifications and
> is declared as a lazy consensus vote. This link has a little more detail
> about that https://www.apache.org/foundation/voting.html
>
> If you have any questions around it let me know
> -Jake
>
> On Fri, Mar 9, 2018 at 5:44 PM, James E. King, III 
> wrote:
>
> > Oh, sorry... do you want me to restart it there?
> > How does one determine if a vote is public or private?
> >
> > - Jim
> >
> > On Fri, Mar 9, 2018 at 11:36 AM, Jake Farrell 
> wrote:
> >
> >> +1
> >>
> >> This vote should be on the dev@ list and not on private@
> >>
> >> -Jake
> >>
> >> On Thu, Mar 8, 2018 at 5:09 PM, James E. King, III 
> >> wrote:
> >>
> >> > Per Greg Stein on the infrastructure team:
> >> >
> >> > Regarding management of GitHub Pull Requests: the project could switch
> >> to
> >> > using our new "GitBox" service, where *the repository on github.com
> >> >  becomes read/write* and we mirror back to the
> ASF.
> >> To
> >> > switch to gitbox, we need to see a poll/vote/consensus for the change.
> >> Open
> >> > a Jira if/when the Thrift project decides to move to gitbox.
> >> >
> >> > This could dramatically simplify our commit workflow...
> >> >
> >> > Please VOTE:
> >> >
> >> > [ ] +1 Move to GitBox
> >> > [ ] +0
> >> > [ ] -1 Don't move to GitBox because...
> >> >
> >> > Voting will end in 72 hours (excluding the weekend), March 13, 2018 at
> >> > 6:00:00 pm EST
> >> > https://www.timeanddate.com/countdown/to?iso=20180313T18
> >> >
> >> > - Jim
> >> >
> >>
> >
> >
>

Re: Is the Thrift serialization compatible both directions?

[Randy Abernethy]

Taking this apart:

- Any new fields that you add should be optional.
I disagree, default requiredness with a default value works fine as well
(and is my preference if you are not interested in optimizing the field
away in procs that know about it). On the server side,if the default field
is there great, if not the default value is used. On the client side if the
field is known it is sent if not it is not.

- This means that any messages serialized by code using your "old" message
format can be parsed by your new generated code, as they won’t be missing
any required elements.
True and true with default requiredness as well.

- Similarly, messages created by your new code can be parsed by your old
code: old binaries simply ignore the new field when parsing.
True and true with default requiredness as well.

- However, the unknown fields are not discarded, and if the message is
later serialized, the unknown fields are serialized along with it — so if
the message is passed on to new code, the new fields are still available.
This is inaccurate. If you use Thrift "normally", when you deserialize, the
struct (message) will only contain the fields you know (in any
requiredness).

--Randy

On Thu, Jan 18, 2018 at 7:59 AM, Jean Rodier <
jean.rod...@tatacommunications.com> wrote:

> Hi,
>
> Is this statement true, especially the last part?
>
> Any new fields that you add should be optional. This means that any
> messages serialized by code using your "old" message format can be parsed
> by your new generated code, as they won’t be missing any required elements.
> Similarly, messages created by your new code can be parsed by your old
> code: old binaries simply ignore the new field when parsing. However, the
> unknown fields are not discarded, and if the message is later serialized,
> the unknown fields are serialized along with it — so if the message is
> passed on to new code, the new fields are still available.
>
> Jean
>

Re: Release procedures for third party package managers

[Randy Abernethy]

I can help with some libs as well.

On Tue, Dec 5, 2017 at 11:06 AM, Jens Geyer  wrote:

> Hi
>
> > Should the "dist" CI build produce these so we can
> > take them directly from the CI system
>
> That would be my favourite choice. That way we have a defined process which
> is ideally free of manual work. Creating these artifacts should also be a
> standard CI task, if possible, to make sure it works when we need it.
>
> Aside from getting it reproducable, I personally have not ever in my life
> used CPAN (to name just one). And I certainly don't want to do this, or
> deal
> with 10 other languages' package managers that I don't know much about. I
> can cover a few where I have appropriate knowledge, but not everything. And
> I guess that this will be the case with most people around.
>
> That's by the way also one reason why I didn't provide prebuilt libs. The
> other reason is that they are not part of the official release binaries
> anyway, at least that's how we did it in the past.
>
> $0,02,
> JensG
>
>
>
> -Ursprüngliche Nachricht-
> From: James E. King, III
> Sent: Tuesday, December 5, 2017 6:41 PM
> To: dev@thrift.apache.org
> Subject: Release procedures for third party package managers
>
> Once Thrift 0.11.0 is complete and released, I will build it and upload it
> to CPAN.  I have a question however about how we manage the official
> releases to third party packagers... I believe there is likely to be one
> per language at this point, but I'm not certain as a project we take any
> official capacity to upload and maintain an official package to these.  For
> example there's node.js npm, and there's perl CPAN, and there rust cargo.
>
> Should the official build process for Thrift also include creation and
> dissemination of official third party package manager releases?
>
> Should the "dist" CI build produce these so we can take them directly from
> the CI system, or perhaps mark them as artifacts that need to be captured
> on a specially named branch (like release/), such that any build on that
> branch would build and capture third party package manager artifacts for
> dissemination?
>
> Thanks,
>
> - Jim
>
>

Re: [VOTE] Apache Thrift 0.11.0-rc0 release candidate

[Randy Abernethy]

+1


On Sun, Dec 3, 2017 at 12:18 PM, Jens Geyer  wrote:

> Hi all,
>
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.11.0 release.
>
> https://dist.apache.org/repos/dist/dev/thrift/0.11.0-rc0/
> thrift-0.11.0-rc0.tar.gz
>
> The release candidate was created from the 0.11.0 branch and can be cloned
> using:
>
> git clone -b 0.11.0 https://git-wip-us.apache.org/repos/asf/thrift.git
>
> The release candidates GPG signature can be found at:
> https://dist.apache.org/repos/dist/dev/thrift/0.11.0-rc0/
> thrift-0.11.0-rc0.tar.gz.asc
>
> The release candidates checksums are:
> md5: 0be59730ebce071eceaf6bfdb8d3a20e
> sha1: bdf159ef455c6d3c71e95dba15a6d05f6aaca2a9
> sha256: c4ad38b6cb4a3498310d405a91fef37b9a8e79a50cd0968148ee2524d2fa60c2
>
>
>
> A prebuilt windows compiler is available at:
> https://dist.apache.org/repos/dist/dev/thrift/0.11.0-rc0/
> compiler/windows/thrift-0.11.0-rc0.exe
>
> Prebuilt windows compiler GPG signature:
> https://dist.apache.org/repos/dist/dev/thrift/0.11.0-rc0/
> compiler/windows/thrift-0.11.0-rc0.exe.asc
>
> Prebuilt windows compiler checksums are:
> md5: b037e9e40e61c2fd309944d364c15546
> sha1: 69f92201971cfc741f6b4827d49eca720e15c32e
> sha256: 29a45c267f64ada6663fd449677b4d8ba3b4b3c772a9fd23910f876a224c2776
>
>
> The CHANGES list for this release is available at:
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;
> f=CHANGES;hb=0.11.0
>
>
>
> Please download, verify sig/sum, install and test the libraries of your
> choice.
>
> This vote will close in 72 hours on 2017-12-06  21:00 UTC
>
> [ ] +1 Release this as Apache Thrift 0.11.0
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.11.0 because...
>
>
> Have fun,
> JensG
>
>
>

Re: History of testOneway sleep?

[Randy Abernethy]

Sounds like an oversight to me.

On Sat, Nov 18, 2017 at 9:16 AM, James E. King, III 
wrote:

> Does anybody know why the cross tests have a built-in sleep in the one-way
> test?  This slows down every test, seemingly unnecessarily.  When I removed
> it from the cpp tests, the cpp server tests all zoom along nicely.  It's
> present in c_glib server, for example, and also in go, and probably
> others.  If we don't need all the tests to be sleeping 1 second, we should
> remove all the sleeping to speed up the tests.  We do 2,000+ cross tests,
> so that's a lot of sleep.
>

Re: Compiler plug-ins

[Randy Abernethy]

I am a fan of tenacious elimination of complexity. Thrift should be fast
and easy. A low level platform upon which you can build your own higher
level abstractions.

-1 compiler plug ins
-1 recursive data structs
etc...

--Randy

On Sun, Oct 29, 2017 at 9:50 AM, Jens Geyer  wrote:

>
> Not so long ago some people absolutely want it to have ... Thank god we're
> not in the same position as protobuf (it can't do anything out of the box,
> you always need plugins) where it is a highly needed feature.
>
> I'd still like to hear the opinion of the people who wanted it, but I
> personally (I can only speak for myself) don't need it.
>
> Have fun,
> JensG
>
>
> -Ursprüngliche Nachricht-
> From: James E. King, III
> Sent: Sunday, October 29, 2017 3:38 PM
> To: dev@thrift.apache.org
> Subject: Compiler plug-ins
>
> I'm curious if anyone uses the thrift compiler plug-in feature?  It adds a
> complexity to the build system and the compiler, and if it does not provide
> value, it should be considered for removal.  I'd like to know what the use
> cases are for having a binary plug-in system when the source code is freely
> available and modifiable.
>
> - Jim
>
>

Re: golang support pre-1.8 discussion

[Randy Abernethy]

I agree with Jim and Jens. It is hard to move Thrift forward if we have to
support language versions that the language maintainers do not support. To
rationalize this, if you are using old Go, you should also be ok using old
Thrift. I am strongly in favor of not supporting versions of languages that
the language maintainers do not support.

-Randy

On Thu, Oct 19, 2017 at 2:06 PM, Jens Geyer  wrote:

>
> Funny enough, that's basically what I said only a few weeks ago. But then
> very quickly a few people showed up and said they would need pre 1.7 ...
> mmmh.
>
>
> -Ursprüngliche Nachricht-
> From: James E. King, III
> Sent: Thursday, October 19, 2017 10:51 PM
> To: dev@thrift.apache.org
> Subject: golang support pre-1.8 discussion
>
> According to folks on the Go team, they do not support golang older than
> 1.8 according to an exchange I had about a bug I found and fixed:
>
> https://github.com/golang/mock/issues/119#issuecomment-337968237
>
> Does it make sense to support anything older than golang 1.8 with Thrift
> based on this?  Currently we test against golang 1.4.2 in trusty, 1.6.2 in
> xenial, and 1.8.3 in artful.  We run cross tests in xenial.
>
> If we set the minimum bar at golang 1.7 then we can eliminate all the
> "pre-1.7" go code and x/net/context stuff the project is currently holding
> onto.
>
> Thoughts?
>
> - Jim
>
>

Re: dlang library / compiler maintainer

[Randy Abernethy]

Start contributing and if you stick with it and your patches are good it
will happen. Maintainers are not officially partitioned.

On Mon, Oct 16, 2017 at 7:48 PM Chris Wright  wrote:

> Is there a current maintainer for the thrift dlang compiler and libraries?
> If not, what does the process to become one look like?
>

Re: TException and cross-tests

[Randy Abernethy]

Hi Tom,

All Apache Thrift generated exceptions are derived from TException, not
just user defined exceptions. There are transport exceptions like
TTransportException which raise connectivity problems, TProtocolExceptions
for serialization errors, TApplicationExceptions for Server errors (e.g.
calling a function that does not exist) and user def exceptions for
application errors.

TException is derived from the base exception type in the language in
question (if there is one).

Processors catch only the handler exceptions declared in the exception
clause of the method in the service's IDL, any other exception escaping the
handler will unwind the processor and possibly crash the server. Exceptions
in the IDL exception list are passed back to the client by the processor.
The only other kind of exception passed back to the client is
TApplicationException which is used when a request is mechanically broken
(wrong protocol or transport setup, missing reqed args, etc.).

The only user defined way to return an exception to a caller from a handler
is to actually raise the exception (throw, whatever). Again the exception
must also be IDL defined and in the IDL exception list of the method in
question.

-Randy


On Tue, Oct 10, 2017 at 12:42 AM, Tom  wrote:

> Hi,
>
> We're working on Common Lisp support for Thrift. I've run into a
> little issue while implementing cross-tests - namely this bit:
>
>   /**
>* Print 'testException(%s)' with arg as '%s'
>* @param string arg - a string indication what type of exception to
> throw
>* if arg == "Xception" throw Xception with errorCode = 1001 and message
> = arg
>* elsen if arg == "TException" throw TException
>* else do not throw anything
>*/
>   void testException(1: string arg) throws(1: Xception err1),
>
>
> Is there some specification on how TException is supposed to work? I
> understand it is a parent of any exception type defined by the user in
> the IDL file, but I thought that would be purely an implementation
> detail of specific languages so that they can make clauses that catch
> all user-defined errors they receive via Thrift. But apparently, it
> should be possible to send it explicitly via the protocol, without it
> being defined in the IDL?
>
> Or maybe it's meant to test the TApplicationException, as defined
> here: https://erikvanoosten.github.io/thrift-missing-
> specification/#_response_struct
> ? Supposed to be sent not like a user-defined exception (message type
> Reply), but with a message of type Exception?
>

Re: netcore (dotnet) 2.0 support

[Randy Abernethy]

+1

On Fri, Oct 6, 2017 at 5:27 AM, James E. King, III  wrote:

> Hi folks,
>
> I converted the netcore library over to netstandard20 and netcoreapp20 and
> used the official dotnet 2.0.0 SDK on linux.  The netcore library also runs
> as a client (but not a server yet) in the cross test.  I put up the pull
> request 8 days ago but I haven't seen any responses to it.  I'll give it a
> few more days, and then I'm planning on merging it unless I hear otherwise.
>
> Thanks,
>
> Jim
>

[jira] [Created] (THRIFT-4280) Add async nonblocking ssl support in java client

[Randy Abernethy (JIRA)]

Randy Abernethy created THRIFT-4280:
---

 Summary: Add async nonblocking ssl support in java client
 Key: THRIFT-4280
 URL: https://issues.apache.org/jira/browse/THRIFT-4280
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.10.0
Reporter: Randy Abernethy
Priority: Minor
 Fix For: 0.10.0


Add async nonblocking ssl support in java client



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (THRIFT-4276) Add SSL support to the C++ Nonblocking Server

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy resolved THRIFT-4276.
-
   Resolution: Fixed
Fix Version/s: 0.10.0

committed 

> Add SSL support to the C++ Nonblocking Server
> -
>
> Key: THRIFT-4276
> URL: https://issues.apache.org/jira/browse/THRIFT-4276
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Affects Versions: 0.11.0
>    Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
> Fix For: 0.10.0
>
>
> This patch adds SSL support to the C++ noblocking server and cleans up some 
> of its monolithic integrated transport, moving to a more flexible and typical 
> Apache Thrift Transport model.
> Many thanks to Divya and James for the work on this
> GitHub user dthaluru opened a pull request:
> https://github.com/apache/thrift/pull/1251
> Added support for C++ Nonblocking SSL Server
> You can merge this pull request into a Git repository by running:
> $ git pull https://github.com/dthaluru/cpp-nonblocking1 master
> Alternatively you can review and apply these changes as the patch at:
> https://github.com/apache/thrift/pull/1251.patch
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
> This closes #1251
> 
> 
> commit 6351c2c112affbe4ca7677236605030e72ffa057
> Author: Divya Thaluru <dthal...@vmware.com>
> Date:   2017-04-20T17:35:10Z
> Added support for C++ Nonblocking SSL Server
> 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (THRIFT-4276) Add SSL support to the C++ Nonblocking Server

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-4276:

Description: 
This patch adds SSL support to the C++ noblocking server and cleans up some of 
its monolithic integrated transport, moving to a more flexible and typical 
Apache Thrift Transport model.

Many thanks to Divya and James for the work on this


GitHub user dthaluru opened a pull request:

https://github.com/apache/thrift/pull/1251

Added support for C++ Nonblocking SSL Server

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dthaluru/cpp-nonblocking1 master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1251.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1251


commit 6351c2c112affbe4ca7677236605030e72ffa057
Author: Divya Thaluru <dthal...@vmware.com>
Date:   2017-04-20T17:35:10Z

Added support for C++ Nonblocking SSL Server






  was:
This patch adds SSL support to the C++ noblocking server and cleans up some of 
its monolithic integrated transport, moving to a more flexible and typical 
Apache Thrift Transport model.

Many thanks to Divya and James for the work on this


GitHub user dthaluru opened a pull request:

https://github.com/apache/thrift/pull/1251

Added support for C++ Nonblocking SSL Server

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dthaluru/cpp-nonblocking1 master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1251.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #89


commit 6351c2c112affbe4ca7677236605030e72ffa057
Author: Divya Thaluru <dthal...@vmware.com>
Date:   2017-04-20T17:35:10Z

Added support for C++ Nonblocking SSL Server







> Add SSL support to the C++ Nonblocking Server
> -
>
> Key: THRIFT-4276
> URL: https://issues.apache.org/jira/browse/THRIFT-4276
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Affects Versions: 0.11.0
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
>
> This patch adds SSL support to the C++ noblocking server and cleans up some 
> of its monolithic integrated transport, moving to a more flexible and typical 
> Apache Thrift Transport model.
> Many thanks to Divya and James for the work on this
> GitHub user dthaluru opened a pull request:
> https://github.com/apache/thrift/pull/1251
> Added support for C++ Nonblocking SSL Server
> You can merge this pull request into a Git repository by running:
> $ git pull https://github.com/dthaluru/cpp-nonblocking1 master
> Alternatively you can review and apply these changes as the patch at:
> https://github.com/apache/thrift/pull/1251.patch
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
> This closes #1251
> 
> 
> commit 6351c2c112affbe4ca7677236605030e72ffa057
> Author: Divya Thaluru <dthal...@vmware.com>
> Date:   2017-04-20T17:35:10Z
> Added support for C++ Nonblocking SSL Server
> 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (THRIFT-4276) Add SSL support to the C++ Nonblocking Server

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy updated THRIFT-4276:

Description: 
This patch adds SSL support to the C++ noblocking server and cleans up some of 
its monolithic integrated transport, moving to a more flexible and typical 
Apache Thrift Transport model.

Many thanks to Divya and James for the work on this


GitHub user dthaluru opened a pull request:

https://github.com/apache/thrift/pull/1251

Added support for C++ Nonblocking SSL Server

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dthaluru/cpp-nonblocking1 master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1251.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #89


commit 6351c2c112affbe4ca7677236605030e72ffa057
Author: Divya Thaluru <dthal...@vmware.com>
Date:   2017-04-20T17:35:10Z

Added support for C++ Nonblocking SSL Server






  was:
This patch adds SSL support to the C++ noblocking server and cleans up some of 
its monolithic integrated transport, moving to a more flexible and typical 
Apache Thrift Transport model.

Many thanks to Divya and James for the work on this

https://github.com/apache/thrift/pull/1251


> Add SSL support to the C++ Nonblocking Server
> -
>
> Key: THRIFT-4276
> URL: https://issues.apache.org/jira/browse/THRIFT-4276
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Affects Versions: 0.11.0
>    Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
>
> This patch adds SSL support to the C++ noblocking server and cleans up some 
> of its monolithic integrated transport, moving to a more flexible and typical 
> Apache Thrift Transport model.
> Many thanks to Divya and James for the work on this
> GitHub user dthaluru opened a pull request:
> https://github.com/apache/thrift/pull/1251
> Added support for C++ Nonblocking SSL Server
> You can merge this pull request into a Git repository by running:
> $ git pull https://github.com/dthaluru/cpp-nonblocking1 master
> Alternatively you can review and apply these changes as the patch at:
> https://github.com/apache/thrift/pull/1251.patch
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
> This closes #89
> 
> 
> commit 6351c2c112affbe4ca7677236605030e72ffa057
> Author: Divya Thaluru <dthal...@vmware.com>
> Date:   2017-04-20T17:35:10Z
> Added support for C++ Nonblocking SSL Server
> 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (THRIFT-4276) Add SSL support to the C++ Nonblocking Server

[Randy Abernethy (JIRA)]

Randy Abernethy created THRIFT-4276:
---

 Summary: Add SSL support to the C++ Nonblocking Server
 Key: THRIFT-4276
 URL: https://issues.apache.org/jira/browse/THRIFT-4276
 Project: Thrift
  Issue Type: Improvement
  Components: C++ - Library
Affects Versions: 0.11.0
Reporter: Randy Abernethy
Assignee: Randy Abernethy
Priority: Minor


This patch adds SSL support to the C++ noblocking server and cleans up some of 
its monolithic integrated transport, moving to a more flexible and typical 
Apache Thrift Transport model.

Many thanks to Divya and James for the work on this

https://github.com/apache/thrift/pull/1251



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Java thrift server consuming up systemp tcp_mem under high load pressure.

[Randy Abernethy]

Thanks for sharing your experiences and glad you got the ball moved down
field a little!

On Fri, Jun 23, 2017 at 9:29 PM, w yishigan <yishi...@gmail.com> wrote:

> I find the problem. The AbstractNonblockingServer.maxReadBufferBytes is
> too
> small. Now the tcp_mem is good and the data is clogged in jvm now.
> Thanks.
>
> On Fri, Jun 23, 2017 at 9:46 AM, w yishigan <yishi...@gmail.com> wrote:
>
> > Hi Randy,
> > Thanks for your email. Yes, there're  4 GB in the kernel's buffer. I'm
> > using  two 1Gig nic, so the throughput is only ~200 MB. It's thrift
> 0.9.0.
> > The problem is Scribe which is use c++ thrift library won't have such
> > problem. The processor thread of scribe is busy, but only ~40MB data in
> the
> > tcp buffer of the kernel.   Besides, I had add some tracing points in
> > TThreadedSelector, and found that it take ~2ms and ~2000 times of
> > handleRead invocation to fully read a frame which is only ~1MB.
> >
> > On Fri, Jun 23, 2017 at 8:53 AM, Randy Abernethy <r...@apache.org> wrote:
> >
> >> Hello,
> >> If you truly mean simultaneously that's 4 GB of instantaneous data. If
> you
> >> are using 10Gig Ethernet it would take 4 seconds or more just to move
> the
> >> bytes in the perfect case. That sounds like a DDOS more than a use case.
> >> You might consider scaling your servers out. If you mean 4,000
> >> simultaneous
> >> clients sending 1MB at random intervals it would be helpful to
> understand
> >> the actual bytes per second per client.
> >> -Randy
> >>
> >> On Thu, Jun 22, 2017 at 4:45 PM, w yishigan <yishi...@gmail.com> wrote:
> >>
> >> > Hi folks,
> >> > I had been working on flume which use thrift server to receive data
> >> > recently and encountered a problem. After removing all the user logic
> >> and
> >> > only keep the thrift server code, I try to use ~4000 thrift clients to
> >> send
> >> > data(~1MB per rpc) simultaneously to one thrift server. Seems like the
> >> > thrift server can't work well and there're lots of data in the recv-q
> >> which
> >> > consumes up all the tcp_mem(/proc/sys/net/ipv4/tcp_mem ) of the OS
> >> (cent
> >> > OS), thus causing node's network down. I had tried THaHsServer,
> >> > TThreadedSelectorServer and TThreadPoolServer, but none worked well
> >> enough
> >> > to solve the problem. I had also tried to increase the selector
> threads
> >> and
> >> > other args. Any suggestions? Thank you very much and have a good day.
> >> >
> >>
> >
> >
>

High Performance Microservices w/ Apache Thrift

[Randy Abernethy]

Hello All,

Aki and I just wrapped up a talk at Open Source summit Japan on Thrift. Was
a lot of fun.

As requested, slides here for those interested: http://sched.co/AOmZ

The repo with the code for the performance comparos and demo stuff (is very
messy) here:  https://github.com/RX-M/api-bench

There are some half baked things in there that we did not demo so fair
warning. We may add more comparos and clean things up in the days ahead.

Best,
Randy

Re: High performance Microservices on Linux with Apache Thrift

[Randy Abernethy]

Hey Allen,

The slides and the demo project will be posted for sure but I don't know if
they are going to record/post the live talk yet. Will let you know as soon
as I find out.

-Randy

On Tue, May 2, 2017 at 5:53 AM, Allen George <allen.geo...@gmail.com> wrote:

> Hi Randy,
>
> Congrats! Do you know if the slides/talk will be posted online?
>
> Allen
> Terminal Musings: http://www.allengeorge.com/
> Raft in Java: https://github.com/allengeorge/libraft/
> Twitter: https://twitter.com/allenageorge/
>
>
> On Thu, Apr 27, 2017 at 7:40 PM, Randy Abernethy <r...@apache.org> wrote:
> > Hello All,
> >
> > Wanted to let the community know that OpenSource Summit Japan is
> happening
> > this year May 31 - June 2, 2017 at the Tokyo Conference Center (Ariake,
> > Tokyo) and that Aki Sukagawa and I are doing a talk titled: "High
> > performance Microservices on Linux with Apache Thrift". Should be a lot
> of
> > fun, hope some of you can attend!
> >
> > Slides will be publicly available after the talk and the sample app will
> be
> > available on GitHub as well (will update the list with links when
> > available).
> >
> > More info here:
> > http://sched.co/AOmZ
> >
> > #OSSummit
> >
> > -Randy
>

High performance Microservices on Linux with Apache Thrift

[Randy Abernethy]

Hello All,

Wanted to let the community know that OpenSource Summit Japan is happening
this year May 31 - June 2, 2017 at the Tokyo Conference Center (Ariake,
Tokyo) and that Aki Sukagawa and I are doing a talk titled: "High
performance Microservices on Linux with Apache Thrift". Should be a lot of
fun, hope some of you can attend!

Slides will be publicly available after the talk and the sample app will be
available on GitHub as well (will update the list with links when
available).

More info here:
http://sched.co/AOmZ

#OSSummit

-Randy

[jira] [Commented] (THRIFT-4176) Implement a threaded and threadpool server type for Rust

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-4176:
-

I would argue for a single great rust server. Multiple servers confuse users, 
they don't want to have to figure out which server to use and in most cases 
there is one server model that performs best or close enough in the vast 
majority of cases. If users need hyper performance or special cases they will 
probably write their own anyway. One server will reduce testing burden and 
focus all improvements iin one place. Some of our languages (Java/c++) look 
like a server science project and have caused users to waste huge sums of time 
trying to compare performance and features (often without the necessary 
context).. just my 2 cents



> Implement a threaded and threadpool server type for Rust
> 
>
> Key: THRIFT-4176
> URL: https://issues.apache.org/jira/browse/THRIFT-4176
> Project: Thrift
>  Issue Type: Improvement
>  Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>
> Currently the Rust client library only provides a single-threaded server. Add 
> both a multi-threaded server and a threadpool-based server and add the 
> relevant options to the cross-test code as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (THRIFT-4175) ts and with_ns options added to js generator with no help text

[Randy Abernethy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Randy Abernethy closed THRIFT-4175.
---
Resolution: Invalid

user error

> ts and with_ns options added to js generator with no help text
> --
>
> Key: THRIFT-4175
> URL: https://issues.apache.org/jira/browse/THRIFT-4175
> Project: Thrift
>  Issue Type: Improvement
>  Components: JavaScript - Compiler
>Affects Versions: 0.10.0
>    Reporter: Randy Abernethy
>Priority: Minor
>
> thrift -help says nothing about js:ts or js:with_ns



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (THRIFT-4175) ts and with_ns options added to js generator with no help text

[Randy Abernethy (JIRA)]

Randy Abernethy created THRIFT-4175:
---

 Summary: ts and with_ns options added to js generator with no help 
text
 Key: THRIFT-4175
 URL: https://issues.apache.org/jira/browse/THRIFT-4175
 Project: Thrift
  Issue Type: Improvement
  Components: JavaScript - Compiler
Affects Versions: 0.10.0
Reporter: Randy Abernethy
Priority: Minor


thrift -help says nothing about js:ts or js:with_ns



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)