[jira] [Closed] (THRIFT-3952) Upgrade from v1.5.8 to current version for slf4j
[ https://issues.apache.org/jira/browse/THRIFT-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-3952. - Resolution: Fixed Assignee: James E. King III Fix Version/s: 0.9.3 https://github.com/apache/thrift/commit/98f379ece17c8acb6a91cb3fd5b16acc3f0d1698 > Upgrade from v1.5.8 to current version for slf4j > > > Key: THRIFT-3952 > URL: https://issues.apache.org/jira/browse/THRIFT-3952 > Project: Thrift > Issue Type: Dependency upgrade > Components: Java - Library >Affects Versions: 0.9.3, 0.10.0 >Reporter: Tim Webex >Assignee: James E. King III >Priority: Minor > Fix For: 0.9.3 > > > Are slf4j-api-1.5.8.jar and slf4j-log4j12-1.5.8.jar intended to support the > older versions of Java? These are pretty old versions of slf4j. > Can they be upgraded to the current version? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (THRIFT-3782) How to get client's info(such as ip, cert when using SSL) in a python thrift server
[ https://issues.apache.org/jira/browse/THRIFT-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-3782. - Resolution: Information Provided Assignee: James E. King III You can use the TSocket's handle to get the socket and then use normal socket operations to get the information you want. For TSSLSocket you would probably need to add a certificate validation mechanism that stores the certificate of the connection so you could get it later. > How to get client's info(such as ip, cert when using SSL) in a python thrift > server > --- > > Key: THRIFT-3782 > URL: https://issues.apache.org/jira/browse/THRIFT-3782 > Project: Thrift > Issue Type: Question > Components: Python - Library >Affects Versions: 0.9.3 > Environment: python >Reporter: yueyemijing >Assignee: James E. King III >Priority: Major > > I'm writing a thrift service in python and I would like to understand how I > can get the client's info(such as ip, cert when using SSL) in the handler > functions context. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-3970) Server does not limititate client connections
[
https://issues.apache.org/jira/browse/THRIFT-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III resolved THRIFT-3970.
---
Resolution: Cannot Reproduce
Assignee: James E. King III
Fix Version/s: 0.9.3
Connection limits were added in THRIFT-3084.
The ability to stop the server with connected clients was added in THRIFT-2441.
These appear to solve the issues you discussed.
> Server does not limititate client connections
> -
>
> Key: THRIFT-3970
> URL: https://issues.apache.org/jira/browse/THRIFT-3970
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Claudius Heine
>Assignee: James E. King III
>Priority: Major
> Labels: security
> Fix For: 0.9.3
>
> Attachments: TestServer.patch, ThriftDOSAttack.py
>
>
> Currently the connection from clients are only closed by the server when a
> receive timeout is configured or the client is sending invalid messages that
> cause exceptions on the server (with THRIFT-3957 and THRIFT-3961 merged).
> That means that the client can continue to occupy a limited open connection,
> as long as it sends valid messages in regular intervals.
>
> To demonstrate the issue the appended patch enables the connection limit and
> receive timeout on the TestServer and the appended python script opens many
> connections to it, thus rapidly exhausting the client connection limit.
> Starting the server:
> {code}
> $ bin/TestServer --protocol=json --transport=http --server-type=thread-pool
> --port=9080
> {code}
> Starting the script:
> {code}
> $ ./ThriftDOSAttack.py http://localhost:9080 3
> {code}
> After a short period the connection limit of the server should be exhausted
> and new connections are denied.
> To stop the python script you have to do this in a seperate terminal:
> {code}
> $ kill $(pgrep -f "ThriftDOSAttack.py")
> {code}
> Here are a view ideas to prevent this scenario:
> - Implement traffic limitation of every connection, after limit is reached,
> disconnect the client.
> - Limit size of a single RPC call and limit number of calls per connection
> - Limit number of connections per IP
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (THRIFT-3970) Server does not limititate client connections
[
https://issues.apache.org/jira/browse/THRIFT-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III closed THRIFT-3970.
-
> Server does not limititate client connections
> -
>
> Key: THRIFT-3970
> URL: https://issues.apache.org/jira/browse/THRIFT-3970
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Claudius Heine
>Assignee: James E. King III
>Priority: Major
> Labels: security
> Fix For: 0.9.3
>
> Attachments: TestServer.patch, ThriftDOSAttack.py
>
>
> Currently the connection from clients are only closed by the server when a
> receive timeout is configured or the client is sending invalid messages that
> cause exceptions on the server (with THRIFT-3957 and THRIFT-3961 merged).
> That means that the client can continue to occupy a limited open connection,
> as long as it sends valid messages in regular intervals.
>
> To demonstrate the issue the appended patch enables the connection limit and
> receive timeout on the TestServer and the appended python script opens many
> connections to it, thus rapidly exhausting the client connection limit.
> Starting the server:
> {code}
> $ bin/TestServer --protocol=json --transport=http --server-type=thread-pool
> --port=9080
> {code}
> Starting the script:
> {code}
> $ ./ThriftDOSAttack.py http://localhost:9080 3
> {code}
> After a short period the connection limit of the server should be exhausted
> and new connections are denied.
> To stop the python script you have to do this in a seperate terminal:
> {code}
> $ kill $(pgrep -f "ThriftDOSAttack.py")
> {code}
> Here are a view ideas to prevent this scenario:
> - Implement traffic limitation of every connection, after limit is reached,
> disconnect the client.
> - Limit size of a single RPC call and limit number of calls per connection
> - Limit number of connections per IP
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-3956) Java keywords that are legal in IDL can lead to generated code that will not compile
[
https://issues.apache.org/jira/browse/THRIFT-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757994#comment-16757994
]
James E. King III commented on THRIFT-3956:
---
[~jensg] is this an issue you are looking into resolving?
> Java keywords that are legal in IDL can lead to generated code that will not
> compile
>
>
> Key: THRIFT-3956
> URL: https://issues.apache.org/jira/browse/THRIFT-3956
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Benjamin Gould
>Priority: Minor
>
> Consider the following IDL, which is legal and leads to successful source
> code generation using the Java generator:
> {noformat}
> struct int {
> 1: i32 val
> }
> struct boolean {
> 1: bool val
> }
> struct long {
> 1: i64 val
> }
> struct short {
> 1: i16 short
> }
> struct char {
> 1: i16 val
> }
> struct Primitives {
> 1: i32 int,
> 2: i64 long,
> 3: i16 short,
> 4: bool boolean,
> 5: i16 char
> }
> {noformat}
> The generated does not compile because the struct names and fields names are
> reserved keywords in Java, even though they are not reserved words in the
> Thrift compiler.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (THRIFT-3988) TFramedTransport's writeBuffer_ may cause the client OOM
[ https://issues.apache.org/jira/browse/THRIFT-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-3988. --- Resolution: Duplicate Assignee: James E. King III Fix Version/s: 0.9.2 > TFramedTransport's writeBuffer_ may cause the client OOM > > > Key: THRIFT-3988 > URL: https://issues.apache.org/jira/browse/THRIFT-3988 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.7, 0.8, 0.9 >Reporter: Walllee li >Assignee: James E. King III >Priority: Major > Fix For: 0.9.2 > > > In our application, using the Client connection pool, in the process of use, > the writeBuffer TFramedTransport‘s write buffer default is 1024,but when the > wrire data is more than 1024,then buffer can be widening and can not be > reduced.Cause the client out of memory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (THRIFT-3988) TFramedTransport's writeBuffer_ may cause the client OOM
[ https://issues.apache.org/jira/browse/THRIFT-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-3988. - > TFramedTransport's writeBuffer_ may cause the client OOM > > > Key: THRIFT-3988 > URL: https://issues.apache.org/jira/browse/THRIFT-3988 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.7, 0.8, 0.9 >Reporter: Walllee li >Assignee: James E. King III >Priority: Major > Fix For: 0.9.2 > > > In our application, using the Client connection pool, in the process of use, > the writeBuffer TFramedTransport‘s write buffer default is 1024,but when the > wrire data is more than 1024,then buffer can be widening and can not be > reduced.Cause the client out of memory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (THRIFT-3989) PHP socket client unsupports TFramedTransport
[ https://issues.apache.org/jira/browse/THRIFT-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-3989. - Resolution: Cannot Reproduce Assignee: James E. King III There is a TFramedTransport in 0.12.0 and the cross test proves that it works with php as a client and cpp as a server. > PHP socket client unsupports TFramedTransport > - > > Key: THRIFT-3989 > URL: https://issues.apache.org/jira/browse/THRIFT-3989 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.7, 0.9.3, 0.10.0, 0.11.0 >Reporter: Zuocheng Liu >Assignee: James E. King III >Priority: Major > Original Estimate: 336h > Remaining Estimate: 336h > > TFramedTransport for socket is unsupported. > My C++ thrift server use TFramedTransport, While my PHP thrift client can not > connect it. > I have written a php class named TFramedScoketTransport to solve this problem. > May I submit the code to the unreleased versions? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub
[
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757970#comment-16757970
]
James E. King III commented on THRIFT-4710:
---
Also, by moving into docs in the same repo we will use the same pull request
workflow we have today to enable users to fix documentation issues themselves,
without us having to check a second repository.
> 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)
[jira] [Commented] (THRIFT-4070) Generated PHP for Thrift sets are incompatible with PHP
[
https://issues.apache.org/jira/browse/THRIFT-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757986#comment-16757986
]
James E. King III commented on THRIFT-4070:
---
Pull requests are welcome here to resolve this, starting with a unit test for
php that shows the problem in trying to use generated code.
> Generated PHP for Thrift sets are incompatible with PHP
> ---
>
> Key: THRIFT-4070
> URL: https://issues.apache.org/jira/browse/THRIFT-4070
> Project: Thrift
> Issue Type: Bug
> Components: PHP - Compiler
>Reporter: David Reiman
>Priority: Major
>
> In the `TBase` class that all Thrift generated code inherits from, there is a
> `_writeList` method that takes a boolean of whether or not the "list" in
> question is a set. The assumption here is that since PHP has no built-in Set
> data type, we can duplicate the uniqueness constraint of Sets by looking at
> the keys of a PHP associative array. Here's the associated code in
> `_writeList`:
> ```
> foreach ($var as $key => $val) {
> $elem = $set ? $key : $val;
> if (isset($ewrite)) {
> $xfer += $output->$ewrite($elem);
> } else {
> switch ($etype) {
> case TType::STRUCT:
> $xfer += $elem->write($output);
> break;
> ```
> I want to point out again that if we're using a `TType::SET`, the `$set`
> variable will be `true`, and `$elem` will be the `$key`, not the `$value`.
> Here's the problem, from PHP array documentation
> (http://php.net/manual/en/language.types.array.php):
> "The key can either be an integer or a string. The value can be of any
> type...Arrays and objects can not be used as keys. Doing so will result in a
> warning: Illegal offset type."
> In other words, it is impossible to implement a Thrift set of anything other
> than strings or integers given the current implementation of PHP generated
> code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4002) Thrift exceptions are not hashable in Python 3
[ https://issues.apache.org/jira/browse/THRIFT-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757987#comment-16757987 ] James E. King III commented on THRIFT-4002: --- This still appears to be an issue in 0.12.0. > Thrift exceptions are not hashable in Python 3 > -- > > Key: THRIFT-4002 > URL: https://issues.apache.org/jira/browse/THRIFT-4002 > Project: Thrift > Issue Type: Bug > Components: Python - Compiler >Reporter: Jelle Zijlstra >Priority: Major > Labels: compiler, python > Attachments: thrift-hashable-exc.patch > > > The Thrift-to-Python compiler generates `__eq__` but not `__hash__` for > Thrift exception classes, which makes them not hashable in Python 3. Due to > http://bugs.python.org/issue28603, this can lead the Python standard library > to throw an error while printing tracebacks involving Thrift exceptions. > The attached patch generates `__hash__` for Thrift exceptions. This can > technically be incorrect since Thrift exceptions are mutable (compare > https://issues.apache.org/jira/browse/THRIFT-162), but in practice it seems > unlikely that people would mutate exception instances other than directly > after creating them, and without this patch some Thrift exceptions cannot be > displayed by the standard library. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (THRIFT-4122) ppc64le builds don't look in lib64 directory
[
https://issues.apache.org/jira/browse/THRIFT-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III closed THRIFT-4122.
-
> ppc64le builds don't look in lib64 directory
>
>
> Key: THRIFT-4122
> URL: https://issues.apache.org/jira/browse/THRIFT-4122
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.10.0
>Reporter: Christopher Tubbs
>Assignee: James E. King III
>Priority: Major
> Labels: autotools
> Fix For: 0.11.0
>
>
> In {{aclocal/ax_boost_base.m4}}, {{libsubdirs}} is set to inspect lib64
> directories when building on 64-bit architectures. However, ppc64le is
> missing from this list, causing a failure to link against boost-static
> properly during the build.
> The fix is trivial. Just substitute {{ppc64}} with {{ppc64|ppc64le}} in that
> list.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4002) Thrift exceptions are not hashable in Python 3
[ https://issues.apache.org/jira/browse/THRIFT-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757988#comment-16757988 ] James E. King III commented on THRIFT-4002: --- Could you submit your patch as a pull request? Thanks. > Thrift exceptions are not hashable in Python 3 > -- > > Key: THRIFT-4002 > URL: https://issues.apache.org/jira/browse/THRIFT-4002 > Project: Thrift > Issue Type: Bug > Components: Python - Compiler >Reporter: Jelle Zijlstra >Priority: Major > Labels: compiler, python > Attachments: thrift-hashable-exc.patch > > > The Thrift-to-Python compiler generates `__eq__` but not `__hash__` for > Thrift exception classes, which makes them not hashable in Python 3. Due to > http://bugs.python.org/issue28603, this can lead the Python standard library > to throw an error while printing tracebacks involving Thrift exceptions. > The attached patch generates `__hash__` for Thrift exceptions. This can > technically be incorrect since Thrift exceptions are mutable (compare > https://issues.apache.org/jira/browse/THRIFT-162), but in practice it seems > unlikely that people would mutate exception instances other than directly > after creating them, and without this patch some Thrift exceptions cannot be > displayed by the standard library. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (THRIFT-4030) CI jobs do not reuse downloaded docker images
[ https://issues.apache.org/jira/browse/THRIFT-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4030. - Resolution: Cannot Reproduce Assignee: James E. King III > CI jobs do not reuse downloaded docker images > - > > Key: THRIFT-4030 > URL: https://issues.apache.org/jira/browse/THRIFT-4030 > Project: Thrift > Issue Type: Bug > Components: Build Process >Reporter: Aki Sukegawa >Assignee: James E. King III >Priority: Minor > > The main motivation for me to introduce this script was to avoid docker build > which was failing too often due to occasional apt download failures. > But for some unknown reason apt is not failing any longer. > Although reusing reduces build time by ~10min for each job, we may well > remove the script and always build images from scratch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4122) ppc64le builds don't look in lib64 directory
[
https://issues.apache.org/jira/browse/THRIFT-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III resolved THRIFT-4122.
---
Resolution: Fixed
Assignee: James E. King III
Fix Version/s: 0.11.0
> ppc64le builds don't look in lib64 directory
>
>
> Key: THRIFT-4122
> URL: https://issues.apache.org/jira/browse/THRIFT-4122
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.10.0
>Reporter: Christopher Tubbs
>Assignee: James E. King III
>Priority: Major
> Labels: autotools
> Fix For: 0.11.0
>
>
> In {{aclocal/ax_boost_base.m4}}, {{libsubdirs}} is set to inspect lib64
> directories when building on 64-bit architectures. However, ppc64le is
> missing from this list, causing a failure to link against boost-static
> properly during the build.
> The fix is trivial. Just substitute {{ppc64}} with {{ppc64|ppc64le}} in that
> list.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (THRIFT-4124) Connection to non-thrift server crashes android app
[
https://issues.apache.org/jira/browse/THRIFT-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4124:
--
Labels: async (was: )
> Connection to non-thrift server crashes android app
> ---
>
> Key: THRIFT-4124
> URL: https://issues.apache.org/jira/browse/THRIFT-4124
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.10.0
> Environment: Android Studio
>Reporter: Alexey Andronov
>Priority: Major
> Labels: async
>
> I connect to server like this:
> {code}m_client = new DispatchBackend.AsyncClient(
> new TBinaryProtocol.Factory(),
> new TAsyncClientManager(),
> new TNonblockingSocket("google.com", 80)
> );{code}
> Then I execute request:
> {code}
> try {
> m_client.request();
> } catch (TException e) {
> // never reaches here
> }{code}
> And my app crashes with OOM error.
> The problem is that I can't catch exception from thrift library inside my
> application i.e.
> inner library exception always crashes my app which is very sad.
> P.S. I tried to catch Throwable instead of TException and it didn't help
> Stacktrace:
> {code}E/art: Throwing OutOfMemoryError "Failed to allocate a 1213486172 byte
> allocation with 3514240 free bytes and 122MB until OOM"
> E/AndroidRuntime: FATAL EXCEPTION: TAsyncClientManager#SelectorThread 9112
>Process: com.myapp, PID: 20608
>java.lang.OutOfMemoryError: Failed to allocate a 1213486172 byte
> allocation with 3514240 free bytes and 122MB until OOM
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:56)
> at
> org.apache.thrift.async.TAsyncMethodCall.doReadingResponseSize(TAsyncMethodCall.java:250)
> at
> org.apache.thrift.async.TAsyncMethodCall.transition(TAsyncMethodCall.java:198)
> at
> org.apache.thrift.async.TAsyncClientManager$SelectThread.transitionMethods(TAsyncClientManager.java:143)
> at
> org.apache.thrift.async.TAsyncClientManager$SelectThread.run(TAsyncClientManager.java:113){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (THRIFT-4127) The error message in TException isn't being propagated to the client
[ https://issues.apache.org/jira/browse/THRIFT-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4127. - Resolution: Won't Do Assignee: James E. King III Sending a message from TException would be a security issue since it would detail server, protocol, or transport internal messages. You can use TApplicationException or an exception you derive from it in the Thrift IDL from your handler code if you want to get an error message back to the client. > The error message in TException isn't being propagated to the client > > > Key: THRIFT-4127 > URL: https://issues.apache.org/jira/browse/THRIFT-4127 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.10.0 >Reporter: Nikolay Metchev >Assignee: James E. King III >Priority: Major > > The error message held in TException isn't making it across the wire to the > client. > It seems ProcessFunction is ignoring the error message and replacing it with > a generic "Internal error processing ". > Ideally the error message in TException would make it across so the client > gets a more meaningful response. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (THRIFT-4133) Flaky Dart build
[
https://issues.apache.org/jira/browse/THRIFT-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III closed THRIFT-4133.
-
Resolution: Cannot Reproduce
Assignee: James E. King III
CI has been stable in this area.
> Flaky Dart build
>
>
> Key: THRIFT-4133
> URL: https://issues.apache.org/jira/browse/THRIFT-4133
> Project: Thrift
> Issue Type: Bug
> Components: Dart - Library
>Affects Versions: 0.11.0
> Environment: Travis CI, Ubuntu 14.04.5
>Reporter: Jim Apple
>Assignee: James E. King III
>Priority: Major
> Labels: flaky-build
>
> https://travis-ci.org/apache/thrift/jobs/213970932, with the below
> parameters, failed in a documentation-only commit:
> https://github.com/apache/thrift/commit/847fae9388048aa9e09d5ed042e34f5452638248.
> This seems like an indicator of a flaky build.
> {noformat}
> $ export TEST_NAME=""
> $ export SCRIPT="cmake.sh"
> $ export BUILD_ARG=""
> $ export BUILD_ENV="-e CC=clang -e CXX=clang++"
> $ export DISTRO=ubuntu
> $ export BUILD_LIBS="CPP C_GLIB HASKELL JAVA PYTHON TESTING TUTORIALS"
> $ export TEST_NAME="Cross Language Tests (Debian) (Binary, Header,
> Multiplexed Protocols)"
> $ export SCRIPT="cross-test.sh"
> $ export BUILD_ARG="-'(binary|header|multiplexed)'"
> $ export BUILD_ENV="-e CC=clang -e CXX=clang++ -e
> THRIFT_CROSSTEST_CONCURRENCY=4"
> $ export DISTRO=debian
> {noformat}
> The final suspicious part of the console output is:
> {noformat}
> Downloading watcher 0.9.7+3...
> Connection closed while receiving data
> Makefile:606: recipe for target 'all-local' failed
> make[3]: *** [all-local] Error 69
> make[3]: Leaving directory '/thrift/src/lib/dart'
> Makefile:562: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory '/thrift/src/lib'
> Makefile:642: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/thrift/src'
> Makefile:555: recipe for target 'all' failed
> make: *** [all] Error 2
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (THRIFT-4710) Move all ASF CMS website content to GitHub
[
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III updated THRIFT-4710:
--
Summary: Move all ASF CMS website content to GitHub (was: Move all website
content to markdown within the project)
> 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)
[jira] [Closed] (THRIFT-4703) Update Doc Link for Flex
[
https://issues.apache.org/jira/browse/THRIFT-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III closed THRIFT-4703.
-
Resolution: Fixed
Assignee: James E. King III
> Update Doc Link for Flex
>
>
> Key: THRIFT-4703
> URL: https://issues.apache.org/jira/browse/THRIFT-4703
> Project: Thrift
> Issue Type: Documentation
> Components: Documentation
>Affects Versions: 0.12.0
>Reporter: BELUGA BEHR
>Assignee: James E. King III
>Priority: Trivial
>
> {quote}
> .. you need to install the [Flex library|http://flex.sourceforge.net/] (See
> also [Apache Thrift Requirements|https://thrift.apache.org/docs/install] )
> and re-run the configuration script.
> {quote}
> Please update Flex library link to: https://github.com/westes/flex
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-1439) debian packaging: do not download dependencies during build
[
https://issues.apache.org/jira/browse/THRIFT-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757974#comment-16757974
]
James E. King III commented on THRIFT-1439:
---
I looked at our debian/control file and it looks like it's woefully out of
date... leaving this open.
> debian packaging: do not download dependencies during build
> ---
>
> Key: THRIFT-1439
> URL: https://issues.apache.org/jira/browse/THRIFT-1439
> Project: Thrift
> Issue Type: Bug
> Components: Deployment
> Environment: any Debian-based OS
>Reporter: paul cannon
>Priority: Minor
> Labels: debian
>
> It is very much against Debian procedure and policy for a package build
> process to download dependencies from the internet. There are a lot of
> reasons for this; among them, guaranteed build repeatability, security
> auditability, non-reliance on websites remaining available, and license
> auditability.
> The thrift Debian packaging (in contrib/) should use Maven in offline mode,
> if Maven is actually required for the Java build phase. Build-dependencies
> should be expressed as a list of Debian packages under "{{Build-Depends:}}"
> in debian/control.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4710) Move all ASF CMS website content to GitHub
[
https://issues.apache.org/jira/browse/THRIFT-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757965#comment-16757965
]
James E. King III commented on THRIFT-4710:
---
There are advantages to keeping the documentation in the same repository. For
example links to code snippets can be relative. You can disable builds in CI
easily when committing documentation changes.
See this page for an example of "readthedocs" integration with a GitHub repo
that contains docs and code:
[https://solidity.readthedocs.io/en/v0.5.3/]
I don't want to have to maintain two repositories.
> 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)
[jira] [Commented] (THRIFT-4745) warning C4305: 'initializing' : truncation from '"__int64' to 'long'
[
https://issues.apache.org/jira/browse/THRIFT-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757962#comment-16757962
]
James E. King III commented on THRIFT-4745:
---
I fixed this issue as part of a couple other warnings in my THRIFT-4405 travels.
> warning C4305: 'initializing' : truncation from '"__int64' to 'long'
>
>
> Key: THRIFT-4745
> URL: https://issues.apache.org/jira/browse/THRIFT-4745
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler
> Environment: Visual Studio 2017
>Reporter: Jens Geyer
>Assignee: James E. King III
>Priority: Major
>
> {code}
> // largest consecutive integer representable by a double (2 ^ 53 - 1)
> static const long max_safe_integer = 0x1f;
> {code}
> Raises
> {code}warning C4305: 'initializing' : truncation from '"__int64' to
> 'long'{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (THRIFT-4745) warning C4305: 'initializing' : truncation from '"__int64' to 'long'
[
https://issues.apache.org/jira/browse/THRIFT-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III reassigned THRIFT-4745:
-
Assignee: James E. King III
> warning C4305: 'initializing' : truncation from '"__int64' to 'long'
>
>
> Key: THRIFT-4745
> URL: https://issues.apache.org/jira/browse/THRIFT-4745
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler
> Environment: Visual Studio 2017
>Reporter: Jens Geyer
>Assignee: James E. King III
>Priority: Major
>
> {code}
> // largest consecutive integer representable by a double (2 ^ 53 - 1)
> static const long max_safe_integer = 0x1f;
> {code}
> Raises
> {code}warning C4305: 'initializing' : truncation from '"__int64' to
> 'long'{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (THRIFT-4766) JDK9+ fails on missing annotations
[ https://issues.apache.org/jira/browse/THRIFT-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4766: -- Component/s: Java - Library > JDK9+ fails on missing annotations > -- > > Key: THRIFT-4766 > URL: https://issues.apache.org/jira/browse/THRIFT-4766 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Reporter: Fokko Driesprong >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the Java9 build fails because it can't find the annotations: > ``` > make[4]: Entering directory '/thrift/tutorial/cpp' > make[4]: Nothing to be done for 'install-exec-am'. > make[4]: Nothing to be done for 'install-data-am'. > make[4]: Leaving directory '/thrift/tutorial/cpp' > make[3]: Leaving directory '/thrift/tutorial/cpp' > make[2]: Leaving directory '/thrift/tutorial/cpp' > Making install in java > make[2]: Entering directory '/thrift/tutorial/java' > /usr/bin/ant compile > Buildfile: /thrift/tutorial/java/build.xml > init: > [mkdir] Created dir: /thrift/tutorial/java/build > [mkdir] Created dir: /thrift/tutorial/java/build/log > generate: > compile: > [javac] Compiling 7 source files to /thrift/tutorial/java/build > [javac] /thrift/tutorial/java/gen-java/shared/SharedService.java:10: > error: package javax.annotation does not exist > [javac] @javax.annotation.Generated(value = "Autogenerated by Thrift > Compiler (0.13.0)", date = "2019-01-30") > [javac] ^ > [javac] /thrift/tutorial/java/gen-java/shared/SharedStruct.java:10: > error: package javax.annotation does not exist > [javac] @javax.annotation.Generated(value = "Autogenerated by Thrift > Compiler (0.13.0)", date = "2019-01-30") > [javac] ^ > [javac] /thrift/tutorial/java/gen-java/tutorial/Calculator.java:10: > error: package javax.annotation does not exist > [javac] @javax.annotation.Generated(value = "Autogenerated by Thrift > Compiler (0.13.0)", date = "2019-01-30") > [javac] ^ > [javac] /thrift/tutorial/java/gen-java/tutorial/Work.java:19: error: > package javax.annotation does not exist > [javac] @javax.annotation.Generated(value = "Autogenerated by Thrift > Compiler (0.13.0)", date = "2019-01-30") > [javac] ^ > [javac] /thrift/tutorial/java/gen-java/tutorial/InvalidOperation.java:13: > error: package javax.annotation does not exist > [javac] @javax.annotation.Generated(value = "Autogenerated by Thrift > Compiler (0.13.0)", date = "2019-01-30") > [javac] ^ > [javac] /thrift/tutorial/java/gen-java/tutorial/Operation.java:14: error: > package javax.annotation does not exist > [javac] @javax.annotation.Generated(value = "Autogenerated by Thrift > Compiler (0.13.0)", date = "2019-01-30") > [javac] ^ > [javac] 6 errors > BUILD FAILED > /thrift/tutorial/java/build.xml:55: Compile failed; see the compiler error > output for details. > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4767) support tcp keepalive in python
[ https://issues.apache.org/jira/browse/THRIFT-4767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4767. --- Resolution: Fixed Assignee: James E. King III Fix Version/s: 0.13.0 > support tcp keepalive in python > --- > > Key: THRIFT-4767 > URL: https://issues.apache.org/jira/browse/THRIFT-4767 > Project: Thrift > Issue Type: Improvement > Components: Python - Library >Reporter: Jun >Assignee: James E. King III >Priority: Minor > Fix For: 0.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > TSocket not support TCP keep-alive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4541) Use new project system in "lib/csharp" and define supported platforms
[
https://issues.apache.org/jira/browse/THRIFT-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757944#comment-16757944
]
James E. King III commented on THRIFT-4541:
---
@jensg your work on {{netstd}} probably obsoletes this.
> Use new project system in "lib/csharp" and define supported platforms
> -
>
> Key: THRIFT-4541
> URL: https://issues.apache.org/jira/browse/THRIFT-4541
> Project: Thrift
> Issue Type: Umbrella
> Components: C# - Library
>Reporter: Christian Weiss
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As discussed in THRIFT-4535, it would be great if we could update
> "lib/csharp" to use the new "csproj" project system. This will allow us to
> target multiple platforms and the new ".NET Standard" with a single project.
> It's possible to support pretty much every platform there is with this new
> project format (see e.g.
> [Newtonsoft.Json|https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json/Newtonsoft.Json.csproj]),
> however supporting older platforms requires more work as this requires more
> #if statements etc.
> This means that we have to decide which platforms we want to support!
> Targeting ".NET Standard 2.0" would be the easiest option as this version
> [covers a much larger API
> surface|https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/].
> However, this would also mean that people have to use rather recent versions
> of their platforms to use it, as .NET Standard 2.0 requires the following
> minimum versions:
> * .NET 4.6.1 (adding support for .NET 4.5 is no problem though)
> * .NET Core 2.0
> * Mono 5.4
> * Xamarin.iOS 10.14
> * Xamarin.Mac 3.8
> * Xamarin.Android 8.0
> * UWP 10.0.16299
> I will create a PR that targets .NET Standard 2.0 and .NET 4.5 to show what
> the new project files would look like. If the approach is OK for you in
> general, then I can try to add support for whatever minimum versions you'd
> like to support.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (THRIFT-4230) Thrift server connection may hang forever
[ https://issues.apache.org/jira/browse/THRIFT-4230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III closed THRIFT-4230. - Resolution: Invalid Assignee: James E. King III > Thrift server connection may hang forever > - > > Key: THRIFT-4230 > URL: https://issues.apache.org/jira/browse/THRIFT-4230 > Project: Thrift > Issue Type: Bug > Components: Python - Library >Affects Versions: 0.9.3 > Environment: OS: RHEL 7.2 >Reporter: Egor Kromberg >Assignee: James E. King III >Priority: Major > > After a lot of tests with HBASE Thrift server we found a problem. > If the connection is dropped on the client side (using route or iptables) it > may be still opened on the Thrift server side. Such situation will occur in > case of unstable connection. > After several iterations the Thrift server application will have a lot of > opened connections and *will not accept *any new one. The only WA found is to > restart the Thrift server. > I believe Thrift server should have something like socket timeouts and > heartbeats. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (THRIFT-3737) Improve TSocket isOpen() implementation to give more accurate connection status.
[
https://issues.apache.org/jira/browse/THRIFT-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III closed THRIFT-3737.
-
Resolution: Invalid
Assignee: James E. King III
> Improve TSocket isOpen() implementation to give more accurate connection
> status.
>
>
> Key: THRIFT-3737
> URL: https://issues.apache.org/jira/browse/THRIFT-3737
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
>Reporter: Cherrot Luo
>Assignee: James E. King III
>Priority: Major
> Labels: patch
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> h2. Description
> Typically isOpen() of TSocket.py in python lib would *ALWAYS* return true,
> even if the underlying TCP connection has been closed or reset by the peer,
> unless you manually invoke its close() method.
> This is because the isOpen method takes a simple but kind of "irresponsible"
> way to judge connection status:
> {code:title=TSocket.py}
> def isOpen(self):
> return self.handle is not None
> {code}
> This may affect the downstream lib/tools' implementation to offer a
> *reliable* transport instance.
> For example, in [happybase|https://github.com/wbolster/happybase] (a
> developer-friendly Python library to interact with Apache HBase), it use
> isOpen() to judge whether it neccessary to reopen the connection in its
> [connection|https://github.com/wbolster/happybase/blob/9cbd718c10a3089f234f1eac1236b631e1f8e7cd/happybase/connection.py#L164]
> and connection pool.
> h2. Fix
> I've sent a github [Pull Request|https://github.com/apache/thrift/pull/945]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (THRIFT-4155) Unstable D language test has caused some CI build failures
[
https://issues.apache.org/jira/browse/THRIFT-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King III closed THRIFT-4155.
-
Resolution: Cannot Reproduce
Assignee: James E. King III
> Unstable D language test has caused some CI build failures
> --
>
> Key: THRIFT-4155
> URL: https://issues.apache.org/jira/browse/THRIFT-4155
> Project: Thrift
> Issue Type: Bug
> Components: D - Library
>Affects Versions: 0.11.0
> Environment: Travis CI Build Job #5
>Reporter: James E. King III
>Assignee: James E. King III
>Priority: Major
>
> For an example see:
> https://travis-ci.org/apache/thrift/jobs/217605837
> {noformat}
> make[4]: Leaving directory `/thrift/src/lib/d'
> make[3]: Leaving directory `/thrift/src/lib/d'
> Making check in test
> make[3]: Entering directory `/thrift/src/lib/d/test'
> openssl req -new -x509 -nodes -config openssl.test.cnf \
> -out server-certificate.pem
> Generating a 2048 bit RSA private key
> ...+++
> ...+++
> writing new private key to 'server-private-key.pem'
> -
> cat server-certificate.pem > trusted-ca-certificate.pem
> make check-am
> make[4]: Entering directory `/thrift/src/lib/d/test'
> make check-TESTS check-local
> make[5]: Entering directory `/thrift/src/lib/d/test'
> dmd -L-levent ../libthriftd-event.a -L-lssl -L-lcrypto ../libthriftd-ssl.a -w
> -wi -O -release -inline -I../../../lib/d/src -Igen-d
> ../../../lib/d/libthriftd.a -ofclient_pool_test client_pool_test.d
> dmd -L-levent ../libthriftd-event.a -L-lssl -L-lcrypto ../libthriftd-ssl.a -w
> -wi -O -release -inline -I../../../lib/d/src -Igen-d
> ../../../lib/d/libthriftd.a -oftransport_test transport_test.d
> dmd -L-levent ../libthriftd-event.a -L-lssl -L-lcrypto ../libthriftd-ssl.a -w
> -wi -O -release -inline -I../../../lib/d/src -Igen-d
> ../../../lib/d/libthriftd.a -ofasync_test async_test.d
> ../../../compiler/cpp/thrift --gen d ../../../test/ThriftTest.thrift
> [WARNING:/thrift/src/test/ThriftTest.thrift:45] No generator named 'noexist'
> could be found!
> [WARNING:/thrift/src/test/ThriftTest.thrift:47] cpp generator does not accept
> 'noexist' as sub-namespace!
> ../../../compiler/cpp/thrift --gen d ../../../test/ThriftTest.thrift
> [WARNING:/thrift/src/test/ThriftTest.thrift:45] No generator named 'noexist'
> could be found!
> [WARNING:/thrift/src/test/ThriftTest.thrift:47] cpp generator does not accept
> 'noexist' as sub-namespace!
> ../../../compiler/cpp/thrift --gen d -nowarn
> ../../../test/DebugProtoTest.thrift
> ../../../compiler/cpp/thrift --gen d ../../../test/StressTest.thrift
> [WARNING:/thrift/src/test/StressTest.thrift:31] Consider using the more
> efficient "binary" type instead of "list".
> [WARNING:/thrift/src/test/StressTest.thrift:31] Consider using the more
> efficient "binary" type instead of "list".
> ../../../compiler/cpp/thrift --gen d ../../../test/StressTest.thrift
> [WARNING:/thrift/src/test/StressTest.thrift:31] Consider using the more
> efficient "binary" type instead of "list".
> [WARNING:/thrift/src/test/StressTest.thrift:31] Consider using the more
> efficient "binary" type instead of "list".
> dmd -L-levent ../libthriftd-event.a -L-lssl -L-lcrypto ../libthriftd-ssl.a -w
> -wi -O -release -inline -I../../../lib/d/src -Igen-d
> ../../../lib/d/libthriftd.a -ofthrift_test_client thrift_test_client.d
> thrift_test_common.d gen-d/thrift/test/SecondService.d
> gen-d/thrift/test/ThriftTest.d gen-d/thrift/test/ThriftTest_constants.d
> gen-d/thrift/test/ThriftTest_types.d
> dmd -L-levent ../libthriftd-event.a -L-lssl -L-lcrypto ../libthriftd-ssl.a -w
> -wi -O -release -inline -I../../../lib/d/src -Igen-d
> ../../../lib/d/libthriftd.a -ofthrift_test_server thrift_test_server.d
> thrift_test_common.d test_utils.d gen-d/thrift/test/SecondService.d
> gen-d/thrift/test/ThriftTest.d gen-d/thrift/test/ThriftTest_constants.d
> gen-d/thrift/test/ThriftTest_types.d
> dmd -L-levent ../libthriftd-event.a -L-lssl -L-lcrypto ../libthriftd-ssl.a -w
> -wi -O -release -inline -I../../../lib/d/src -Igen-d
> ../../../lib/d/libthriftd.a -ofserialization_benchmark
> serialization_benchmark.d gen-d/DebugProtoTest_types.d
> dmd -L-levent ../libthriftd-event.a -L-lssl -L-lcrypto ../libthriftd-ssl.a -w
> -wi -O -release -inline -I../../../lib/d/src -Igen-d
> ../../../lib/d/libthriftd.a -ofstress_test_server stress_test_server.d
> test_utils.d gen-d/thrift/test/stress/Service.d
> gen-d/thrift/test/stress/StressTest_types.d
> thrift.transport.base.TTransportException@src/thrift/transport/socket.d(255):
> Failed to connect to 127.0.0.1:9090.
>
> ??:? void thrift.transport.socket.TSocket.open() [0x50b8a8]
> ??:? int
>
[jira] [Commented] (THRIFT-4764) Rust frontend emits deprecated clippy suppression attributes
[
https://issues.apache.org/jira/browse/THRIFT-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757618#comment-16757618
]
James E. King III commented on THRIFT-4764:
---
Feel free to submit a pull request with your fixes
> Rust frontend emits deprecated clippy suppression attributes
>
>
> Key: THRIFT-4764
> URL: https://issues.apache.org/jira/browse/THRIFT-4764
> Project: Thrift
> Issue Type: Improvement
> Components: Rust - Compiler
> Environment: Ubuntu Cosmic x64
> Thrift from master
>Reporter: Mikail Bagishov
>Priority: Minor
>
> Currently, following lines are inserted:
> {code:none}
> #![cfg_attr(feature = "cargo-clippy", allow(too_many_arguments,
> type_complexity))]
> {code}
> But this syntax is deprecated now.
> Following should be used instead:
> {code:none}
> #![allow(clippy::too_many_arguments, clippy::type_complexity)]
> {code}
> Note: I fixed this issue in my [fork|http://github.com/MikailBag/thrift], but
> I'm not sure if it will be easier for developers to merge my PR than apply
> changes themselves. Also, I'm student and my Git skills are not very good)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4550) Properly support Java 9
[ https://issues.apache.org/jira/browse/THRIFT-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757615#comment-16757615 ] James E. King III commented on THRIFT-4550: --- The gradle build for java sets sourceCompatibility and targetCompatibility to 1.8 so the compiled bytecode should be compatible however I think it would be safest on the 0.13.0 release to put openjdk-8 into the build environment and build the project with jdk 8 instead of jdk 11, but I'm open to suggestions. We already rest jdk 8 against the Ubuntu Xenial build, so now we have the same code working on JDK8 and JDK11 in our CI environment (when this issue is resolved). > Properly support Java 9 > --- > > Key: THRIFT-4550 > URL: https://issues.apache.org/jira/browse/THRIFT-4550 > Project: Thrift > Issue Type: Story > Components: Java - Compiler >Reporter: James E. King III >Priority: Major > > Some things like "javax.annotations" are no longer accessible in Java 9 > unless you jump through hoops and they have been deprecated and will be > removed in a future release. > The default java in Ubuntu Bionic appears to be Java 9, but 8 is available, > so I will make the docker file use that for now. > We use annotations and the "js" library "make check" fails to build when jdk9 > is in use. > See this page for more details: > [https://blog.codefx.org/java/java-9-migration-guide/] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (THRIFT-4405) Incorrect handling of sequence numbers that wrap to negative
[ https://issues.apache.org/jira/browse/THRIFT-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4405: -- Description: The following tests were added: * The cpp client for cross test did not use sequence numbers, so I added a testing protocol layer for TestClient on top of all protocols that uses a sequence ID that starts at INT32_MAX - 10, and advances until it wraps around. This caught a number of negative value handling issues. * The cpp client verifies the sequence ID that returns matches what was sent. * The python client was changed to use pedantic sequence ID checking on all protocols. The following errors were identified and fixed: * In c_glib, thrift_stored_message_protocol was limiting the sequence ID to [0..G_INTMAX]. This was changed to allow any 32-bit value, matching other implementations. * In cpp, JSON protocol, when the server read the header, it used a uint64_t for processing; this interacted with a bugfix from 2017 (THRIFT-4138) that dropped boost::lexical_cast and switched to std::stringstream, and this corrupted the negative sequence ID. * In python, compact protocol, a negative sequence ID was not handled properly because it is read in and written out as a "var int" which is always positive. Documentation was added for sequence number handling. was: The following tests were added: * The cpp client for cross test now uses a sequence ID that starts at INT32_MAX - 10, and advances until it wraps around. * The cpp client verifies the sequence ID that returns matches what was sent. * The python client was changed to use pedantic sequence ID checking on all protocols. The following errors were identified and fixed: * In c_glib, thrift_stored_message_protocol was limiting the sequence ID to [0..G_INTMAX]. This was changed to allow any 32-bit value, matching other implementations. * In cpp, JSON protocol, when the server read the header, it used a uint64_t for processing; this interacted with a bugfix from 2017 that dropped boost::lexical_cast and switched to std::stringstream, and this corrupted the negative sequence IDs. * In python, compact protocol, a negative sequence ID was not handled properly. Documentation was added for sequence number handling. > Incorrect handling of sequence numbers that wrap to negative > > > Key: THRIFT-4405 > URL: https://issues.apache.org/jira/browse/THRIFT-4405 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.11.0 > Environment: docker ubuntu-xenial >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The following tests were added: > * The cpp client for cross test did not use sequence numbers, so I added a > testing protocol layer for TestClient on top of all protocols that uses a > sequence ID that starts at INT32_MAX - 10, and advances until it wraps > around. This caught a number of negative value handling issues. > * The cpp client verifies the sequence ID that returns matches what was sent. > * The python client was changed to use pedantic sequence ID checking on all > protocols. > The following errors were identified and fixed: > * In c_glib, thrift_stored_message_protocol was limiting the sequence ID to > [0..G_INTMAX]. This was changed to allow any 32-bit value, matching other > implementations. > * In cpp, JSON protocol, when the server read the header, it used a uint64_t > for processing; this interacted with a bugfix from 2017 (THRIFT-4138) that > dropped boost::lexical_cast and switched to std::stringstream, and this > corrupted the negative sequence ID. > * In python, compact protocol, a negative sequence ID was not handled > properly because it is read in and written out as a "var int" which is always > positive. > Documentation was added for sequence number handling. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (THRIFT-4405) Incorrect handling of sequence numbers that wrap to negative
[ https://issues.apache.org/jira/browse/THRIFT-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4405: -- Description: The following tests were added: * The cpp client for cross test now uses a sequence ID that starts at INT32_MAX - 10, and advances until it wraps around. * The cpp client verifies the sequence ID that returns matches what was sent. * The python client was changed to use pedantic sequence ID checking on all protocols. The following errors were identified and fixed: * In c_glib, thrift_stored_message_protocol was limiting the sequence ID to [0..G_INTMAX]. This was changed to allow any 32-bit value, matching other implementations. * In cpp, JSON protocol, when the server read the header, it used a uint64_t for processing; this interacted with a bugfix from 2017 that dropped boost::lexical_cast and switched to std::stringstream, and this corrupted the negative sequence IDs. * In python, compact protocol, a negative sequence ID was not handled properly. Documentation was added for sequence number handling. was: 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 > Incorrect handling of sequence numbers that wrap to negative > > > Key: THRIFT-4405 > URL: https://issues.apache.org/jira/browse/THRIFT-4405 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.11.0 > Environment: docker ubuntu-xenial >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The following tests were added: > * The cpp client for cross test now uses a sequence ID that starts at > INT32_MAX - 10, and advances until it wraps around. > * The cpp client verifies the sequence ID that returns matches what was sent. > * The python client was changed to use pedantic sequence ID checking on all > protocols. > The following errors were identified and fixed: > * In c_glib, thrift_stored_message_protocol was limiting the sequence ID to > [0..G_INTMAX]. This was changed to allow any 32-bit value, matching other > implementations. > * In cpp, JSON protocol, when the server read the header, it used a uint64_t > for processing; this interacted with a bugfix from 2017 that dropped > boost::lexical_cast and switched to std::stringstream, and this corrupted the > negative sequence IDs. > * In python, compact protocol, a negative sequence ID was not handled > properly. > Documentation was added for sequence number handling. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (THRIFT-4405) Incorrect handling of sequence numbers that wrap to negative
[ https://issues.apache.org/jira/browse/THRIFT-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4405: -- Summary: Incorrect handling of sequence numbers that wrap to negative (was: c_glib does not accept seqid < 0, cpp json readHeaderBegin corrupts negative seqid) > Incorrect handling of sequence numbers that wrap to negative > > > Key: THRIFT-4405 > URL: https://issues.apache.org/jira/browse/THRIFT-4405 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.11.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-4550) Properly support Java 9
[ https://issues.apache.org/jira/browse/THRIFT-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757387#comment-16757387 ] David Jung commented on THRIFT-4550: For those of us not well versed in Java and Java build systems, who just need to build it for Java 9+ (OpenJDK10 in my case), is there a work-around in terms of editing some build configuration (Gradle?) to add the missing modules for javax.annotations? Q: If a solution for build is to use Java 8, will the resulting jar libraries run as-is on Java 9+ or cause runtime missing class errors? > Properly support Java 9 > --- > > Key: THRIFT-4550 > URL: https://issues.apache.org/jira/browse/THRIFT-4550 > Project: Thrift > Issue Type: Story > Components: Java - Compiler >Reporter: James E. King III >Priority: Major > > Some things like "javax.annotations" are no longer accessible in Java 9 > unless you jump through hoops and they have been deprecated and will be > removed in a future release. > The default java in Ubuntu Bionic appears to be Java 9, but 8 is available, > so I will make the docker file use that for now. > We use annotations and the "js" library "make check" fails to build when jdk9 > is in use. > See this page for more details: > [https://blog.codefx.org/java/java-9-migration-guide/] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: GSoC
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
[jira] [Commented] (THRIFT-4764) Rust frontend emits deprecated clippy suppression attributes
[
https://issues.apache.org/jira/browse/THRIFT-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757202#comment-16757202
]
Allen George commented on THRIFT-4764:
--
I'd be happy to move the compiler version forward. I've been holding off, and
waiting for async/await syntax to be finalized before bumping the minimum
version and making the next version of the library support the 2018 edition
only.
> Rust frontend emits deprecated clippy suppression attributes
>
>
> Key: THRIFT-4764
> URL: https://issues.apache.org/jira/browse/THRIFT-4764
> Project: Thrift
> Issue Type: Improvement
> Components: Rust - Compiler
> Environment: Ubuntu Cosmic x64
> Thrift from master
>Reporter: Mikail Bagishov
>Priority: Minor
>
> Currently, following lines are inserted:
> {code:none}
> #![cfg_attr(feature = "cargo-clippy", allow(too_many_arguments,
> type_complexity))]
> {code}
> But this syntax is deprecated now.
> Following should be used instead:
> {code:none}
> #![allow(clippy::too_many_arguments, clippy::type_complexity)]
> {code}
> Note: I fixed this issue in my [fork|http://github.com/MikailBag/thrift], but
> I'm not sure if it will be easier for developers to merge my PR than apply
> changes themselves. Also, I'm student and my Git skills are not very good)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (THRIFT-4767) support tcp keepalive in python
Jun created THRIFT-4767: --- Summary: support tcp keepalive in python Key: THRIFT-4767 URL: https://issues.apache.org/jira/browse/THRIFT-4767 Project: Thrift Issue Type: Improvement Components: Python - Library Reporter: Jun TSocket not support TCP keep-alive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
