[jira] [Resolved] (THRIFT-5824) Migrate, refactor and improve Delphi code generation test script
[ https://issues.apache.org/jira/browse/THRIFT-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5824. Fix Version/s: 0.22.0 Resolution: Fixed > Migrate, refactor and improve Delphi code generation test script > > > Key: THRIFT-5824 > URL: https://issues.apache.org/jira/browse/THRIFT-5824 > Project: Thrift > Issue Type: Test > Components: Delphi - Compiler >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Fix For: 0.22.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The existing Delphi code generation test script needs some significant > improvements and should be migrated from batch file into a Powershell script -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5823) Fix illegal uses of exceptions as normal struct type
[ https://issues.apache.org/jira/browse/THRIFT-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5823: --- Attachment: THRIFT-5823.thrift > Fix illegal uses of exceptions as normal struct type > > > Key: THRIFT-5823 > URL: https://issues.apache.org/jira/browse/THRIFT-5823 > Project: Thrift > Issue Type: Bug > Components: Test Suite >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Attachments: THRIFT-5823.thrift > > Time Spent: 40m > Remaining Estimate: 0h > > Fix illegal uses of exvceptions as normal struct type, which it really isn't. > Applies to a number of test IDL files and various tickets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5823) Fix illegal uses of exceptions as normal struct type
[ https://issues.apache.org/jira/browse/THRIFT-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5823: --- Attachment: THRIFT-5823.thrift > Fix illegal uses of exceptions as normal struct type > > > Key: THRIFT-5823 > URL: https://issues.apache.org/jira/browse/THRIFT-5823 > Project: Thrift > Issue Type: Bug > Components: Test Suite >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Fix illegal uses of exvceptions as normal struct type, which it really isn't. > Applies to a number of test IDL files and various tickets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5823) Fix illegal uses of exceptions as normal struct type
[ https://issues.apache.org/jira/browse/THRIFT-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5823: --- Attachment: (was: THRIFT-5823.thrift) > Fix illegal uses of exceptions as normal struct type > > > Key: THRIFT-5823 > URL: https://issues.apache.org/jira/browse/THRIFT-5823 > Project: Thrift > Issue Type: Bug > Components: Test Suite >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Fix illegal uses of exvceptions as normal struct type, which it really isn't. > Applies to a number of test IDL files and various tickets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5824) Migrate, refactor and improve Delphi code generation test script
[ https://issues.apache.org/jira/browse/THRIFT-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5824: --- Attachment: (was: 0001-THRIFT-5824-Migrate-refactor-and-improve-Delphi-code.patch) > Migrate, refactor and improve Delphi code generation test script > > > Key: THRIFT-5824 > URL: https://issues.apache.org/jira/browse/THRIFT-5824 > Project: Thrift > Issue Type: Test > Components: Delphi - Compiler >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > > The existing Delphi code generation test script needs some significant > improvements and should be migrated from batch file into a Powershell script -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5824) Migrate, refactor and improve Delphi code generation test script
[ https://issues.apache.org/jira/browse/THRIFT-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5824: --- Attachment: 0001-THRIFT-5824-Migrate-refactor-and-improve-Delphi-code.patch > Migrate, refactor and improve Delphi code generation test script > > > Key: THRIFT-5824 > URL: https://issues.apache.org/jira/browse/THRIFT-5824 > Project: Thrift > Issue Type: Test > Components: Delphi - Compiler >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Attachments: > 0001-THRIFT-5824-Migrate-refactor-and-improve-Delphi-code.patch > > > The existing Delphi code generation test script needs some significant > improvements and should be migrated from batch file into a Powershell script -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5824) Migrate, refactor and improve Delphi code generation test script
Jens Geyer created THRIFT-5824: -- Summary: Migrate, refactor and improve Delphi code generation test script Key: THRIFT-5824 URL: https://issues.apache.org/jira/browse/THRIFT-5824 Project: Thrift Issue Type: Test Components: Delphi - Compiler Reporter: Jens Geyer Assignee: Jens Geyer The existing Delphi code generation test script needs some significant improvements and should be migrated from batch file into a Powershell script -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (THRIFT-5637) Thrift compiler should be able to output c++ Aggregate types
[
https://issues.apache.org/jira/browse/THRIFT-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888655#comment-17888655
]
Alkis Evlogimenos commented on THRIFT-5637:
---
I have created [https://github.com/apache/thrift/pull/3037] to address this.
Emitting aggregates speeds up decoding by 10% because the compiler can generate
better constructors and/or inline them.
> Thrift compiler should be able to output c++ Aggregate types
>
>
> Key: THRIFT-5637
> URL: https://issues.apache.org/jira/browse/THRIFT-5637
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
>Affects Versions: 0.16.0, 0.17.0
>Reporter: Benjamin Gemmill
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If we have a thrift struct defined like this:
> {{struct thingamabob {}}
> {{ 1: i64 a = 0}}
> {{ 2: i64 b = 0}}
> {{ 3: i64 c = 0}}
> {{}}}
> Then the generated code contains a few constructors and assignment operators
> that look like this:
> {{thingamabob(const thingamabob&) noexcept;}}
> {{thingamabob&operator=(const thingamabob&) noexcept;}}
> {{{}thingamabob() noexcept{}}}{{{}: a(0),{}}}{{{}b(0),{}}}{{{}c(0)
> {{}}}{{{}}{}}}
> The issue here is that while this class could be an
> [AggregateType|http://example.com] and support aggregate initialization, the
> way these defaults are generated prevent it.
> If instead, thrift used default initializers like this where the the member
> objects are defined:
> int64_t a\{0};
> int64_t b\{0};
> int64_t c\{0};
> We could then initialize thrift structs with initializer lists, expect
> static_assert(std::is_aggregate_v) to work, and we'd still have default
> construction and copying.
>
> For this to work, the "templates" option passed to the c++ compiler should
> remove the virtual keyword from the generated printTo functions, and the
> generated __isset structs would also need to be changed similarly to look
> like:
> {{typedef struct_thingamabob__isset {}}
> {{bool a :1\{false};}}
> {{bool b :1\{false};}}
> {{bool c :1\{false};}}
> {{} _thingamabob__isset;}}
>
> {{Happy to take a stab at this and wanted to check for feedback first.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5822) Remove deprecated AnsiString functions from the library
[ https://issues.apache.org/jira/browse/THRIFT-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5822. Fix Version/s: 0.22.0 Resolution: Fixed > Remove deprecated AnsiString functions from the library > --- > > Key: THRIFT-5822 > URL: https://issues.apache.org/jira/browse/THRIFT-5822 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Affects Versions: 0.21.0 >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Minor > Fix For: 0.22.0 > > Attachments: > 0001-THRIFT-5822-Remove-deprecated-AnsiString-functions-f.patch > > > final removal of methods deprecated in THRIFT-5750 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5823) Fix illegal uses of exceptions as normal struct type
[ https://issues.apache.org/jira/browse/THRIFT-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5823: --- Description: Fix illegal uses of exvceptions as normal struct type, which it really isn't. Applies to a number of test IDFL files and various tickets. (was: Fix illegal uses of exvceptions as normal struct type, which it really isn't.) > Fix illegal uses of exceptions as normal struct type > > > Key: THRIFT-5823 > URL: https://issues.apache.org/jira/browse/THRIFT-5823 > Project: Thrift > Issue Type: Bug > Components: Test Suite >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > > Fix illegal uses of exvceptions as normal struct type, which it really isn't. > Applies to a number of test IDFL files and various tickets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5823) Fix illegal uses of exceptions as normal struct type
[ https://issues.apache.org/jira/browse/THRIFT-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5823: --- Description: Fix illegal uses of exvceptions as normal struct type, which it really isn't. Applies to a number of test IDL files and various tickets. (was: Fix illegal uses of exvceptions as normal struct type, which it really isn't. Applies to a number of test IDFL files and various tickets.) > Fix illegal uses of exceptions as normal struct type > > > Key: THRIFT-5823 > URL: https://issues.apache.org/jira/browse/THRIFT-5823 > Project: Thrift > Issue Type: Bug > Components: Test Suite >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > > Fix illegal uses of exvceptions as normal struct type, which it really isn't. > Applies to a number of test IDL files and various tickets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5823) Fix illegal uses of exceptions as normal struct type
[ https://issues.apache.org/jira/browse/THRIFT-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5823: --- Summary: Fix illegal uses of exceptions as normal struct type (was: Fix illegal uses of exvceptions as normal type) > Fix illegal uses of exceptions as normal struct type > > > Key: THRIFT-5823 > URL: https://issues.apache.org/jira/browse/THRIFT-5823 > Project: Thrift > Issue Type: Bug > Components: Test Suite >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > > Fix illegal uses of exvceptions as normal struct type, which it really isn't. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5823) Fix illegal uses of exvceptions as normal type
Jens Geyer created THRIFT-5823: -- Summary: Fix illegal uses of exvceptions as normal type Key: THRIFT-5823 URL: https://issues.apache.org/jira/browse/THRIFT-5823 Project: Thrift Issue Type: Bug Components: Test Suite Reporter: Jens Geyer Assignee: Jens Geyer Fix illegal uses of exvceptions as normal struct type, which it really isn't. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5822) Remove deprecated AnsiString functions from the library
[ https://issues.apache.org/jira/browse/THRIFT-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5822: --- Attachment: 0001-THRIFT-5822-Remove-deprecated-AnsiString-functions-f.patch > Remove deprecated AnsiString functions from the library > --- > > Key: THRIFT-5822 > URL: https://issues.apache.org/jira/browse/THRIFT-5822 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Affects Versions: 0.21.0 >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Minor > Attachments: > 0001-THRIFT-5822-Remove-deprecated-AnsiString-functions-f.patch > > > final removal of methods deprecated in THRIFT-5750 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5822) Remove deprecated AnsiString functions from the library
[ https://issues.apache.org/jira/browse/THRIFT-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5822: --- Attachment: (was: 0001-Bump-org.jetbrains.kotlinx-kotlinx-coroutines-jdk8-i.patch) > Remove deprecated AnsiString functions from the library > --- > > Key: THRIFT-5822 > URL: https://issues.apache.org/jira/browse/THRIFT-5822 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Affects Versions: 0.21.0 >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Minor > > final removal of methods deprecated in THRIFT-5750 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5822) Remove deprecated AnsiString functions from the library
[ https://issues.apache.org/jira/browse/THRIFT-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5822: --- Attachment: 0001-Bump-org.jetbrains.kotlinx-kotlinx-coroutines-jdk8-i.patch > Remove deprecated AnsiString functions from the library > --- > > Key: THRIFT-5822 > URL: https://issues.apache.org/jira/browse/THRIFT-5822 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Affects Versions: 0.21.0 >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Minor > > final removal of methods deprecated in THRIFT-5750 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (THRIFT-5605) Go client middleware has no (easy) access to IDL exceptions
[
https://issues.apache.org/jira/browse/THRIFT-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888477#comment-17888477
]
Jens Geyer commented on THRIFT-5605:
{code}
// This is a special case, we want to make sure that the middleware don't
// accidentally pull result as error.
exception FooResponse {
}
service ClientMiddlewareExceptionTest {
FooResponse foo() throws( // illegal return value
1: Exception1 error1,
2: Exception2 error2,
)
}
{code}
> Go client middleware has no (easy) access to IDL exceptions
> ---
>
> Key: THRIFT-5605
> URL: https://issues.apache.org/jira/browse/THRIFT-5605
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.16.0
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Minor
> Fix For: 0.17.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Similar to THRIFT-5527, this is the issue on the client side.
> But unlike THRIFT-5527, this cannot be resolved by a fix on the compiler
> code. We managed to write a [reflect based helper
> function|https://github.com/reddit/baseplate.go/blob/e34b108af09beab61f33126dfacf075ff58f5116/thriftbp/client_middlewares.go#L404-L443]
> to extract the IDL exceptions out of the result TStruct, I think upstream
> that helper function to be a provided ClientMiddleware would be helpful.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5605) Go client middleware has no (easy) access to IDL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888476#comment-17888476 ] Jens Geyer commented on THRIFT-5605: But returning an exceoptiin as a resuilt value (or a part of it) is technically illegal IDL. An exceoptin is not a normal struct. > Go client middleware has no (easy) access to IDL exceptions > --- > > Key: THRIFT-5605 > URL: https://issues.apache.org/jira/browse/THRIFT-5605 > Project: Thrift > Issue Type: Bug > Components: Go - Library >Affects Versions: 0.16.0 >Reporter: Yuxuan Wang >Assignee: Yuxuan Wang >Priority: Minor > Fix For: 0.17.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Similar to THRIFT-5527, this is the issue on the client side. > But unlike THRIFT-5527, this cannot be resolved by a fix on the compiler > code. We managed to write a [reflect based helper > function|https://github.com/reddit/baseplate.go/blob/e34b108af09beab61f33126dfacf075ff58f5116/thriftbp/client_middlewares.go#L404-L443] > to extract the IDL exceptions out of the result TStruct, I think upstream > that helper function to be a provided ClientMiddleware would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (THRIFT-5685) Compiler generates wrong go code for forward defined types in optional fields
[
https://issues.apache.org/jira/browse/THRIFT-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888471#comment-17888471
]
Jens Geyer commented on THRIFT-5685:
ForwardType.thrift contains a different test case as cdesvrinbed. Particularly
an ILLEGAL test case.
{code}
namespace go forwardtypetest
struct Struct {
1: optional Exc foo// this is ILLEGAL
}
exception Exc {
1: optional i32 code
}
{code}
> Compiler generates wrong go code for forward defined types in optional fields
> -
>
> Key: THRIFT-5685
> URL: https://issues.apache.org/jira/browse/THRIFT-5685
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.18.0
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
> Fix For: 0.18.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This is a bug introduced by the fix of THRIFT-5601.
> Given this thrift file:
> {code:java}
> struct Bar {
> 1: optional Foo bar
> }
> struct Foo {
> 1: optional i64 foo
> }
> {code}
> 0.18.0 with b39370ec3bc96d2 reverted will generate the following go code
> (expected):
> {code:go}
> ...
> var Bar_Bar_DEFAULT *Foo
> func (p *Bar) GetBar() *Foo {
> if !p.IsSetBar() {
> return Bar_Bar_DEFAULT
> }
> return p.Bar
> }
> ...
> {code}
> while 0.18.0 generates:
> {code:go}
> ...
> var Bar_Bar_DEFAULT Foo
> func (p *Bar) GetBar() Foo {
> if !p.IsSetBar() {
> return Bar_Bar_DEFAULT
> }
> return *p.Bar
> }
> ...
> {code}
> This makes usages like bar.GetBar().GetFoo() no longer compiles because
> GetBar now returns non-pointer type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (THRIFT-5822) Remove deprecated AnsiStrjkng functions from the library
Jens Geyer created THRIFT-5822: -- Summary: Remove deprecated AnsiStrjkng functions from the library Key: THRIFT-5822 URL: https://issues.apache.org/jira/browse/THRIFT-5822 Project: Thrift Issue Type: Improvement Components: Delphi - Library Affects Versions: 0.21.0 Reporter: Jens Geyer Assignee: Jens Geyer final removal of methods deprecated in THRIFT-5750 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5822) Remove deprecated AnsiString functions from the library
[ https://issues.apache.org/jira/browse/THRIFT-5822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5822: --- Summary: Remove deprecated AnsiString functions from the library (was: Remove deprecated AnsiStrjkng functions from the library) > Remove deprecated AnsiString functions from the library > --- > > Key: THRIFT-5822 > URL: https://issues.apache.org/jira/browse/THRIFT-5822 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Affects Versions: 0.21.0 >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Minor > > final removal of methods deprecated in THRIFT-5750 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5821) Cannot compile against aws-lc libcrypto (openssl replacement from AWS)
James E. King III created THRIFT-5821: - Summary: Cannot compile against aws-lc libcrypto (openssl replacement from AWS) Key: THRIFT-5821 URL: https://issues.apache.org/jira/browse/THRIFT-5821 Project: Thrift Issue Type: Task Components: C++ - Library Affects Versions: 0.20.0 Reporter: James E. King III Assignee: James E. King III Attachments: AWSLC.patch When attempting to build thrift 0.20.0 against aws-lc ([https://github.com/aws/aws-lc)] I had to use some local patches. This issue tracks getting those patches upstream into the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (THRIFT-5820) [TFileObjectTransport/TJSONProtocol] : Comparing a byte with a character can't succeed
[ https://issues.apache.org/jira/browse/THRIFT-5820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] didier31 closed THRIFT-5820. Resolution: Not A Bug > [TFileObjectTransport/TJSONProtocol] : Comparing a byte with a character > can't succeed > -- > > Key: THRIFT-5820 > URL: https://issues.apache.org/jira/browse/THRIFT-5820 > Project: Thrift > Issue Type: Bug > Components: Python - Library >Affects Versions: 0.16.0 > Environment: python 3.11 > FreeBSD 14.1 >Reporter: didier31 >Priority: Blocker > Attachments: Capture du 2024-09-30 12-08-19.png, server.py > > > Please, see capture as attachment all for details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5820) [TFileObjectTransport/TJSONProtocol] : Comparing a byte with a character can't succeed
didier31 created THRIFT-5820: Summary: [TFileObjectTransport/TJSONProtocol] : Comparing a byte with a character can't succeed Key: THRIFT-5820 URL: https://issues.apache.org/jira/browse/THRIFT-5820 Project: Thrift Issue Type: Bug Components: Python - Library Affects Versions: 0.16.0 Environment: python 3.11 FreeBSD 14.1 Reporter: didier31 Attachments: Capture du 2024-09-30 12-08-19.png, server.py Please, see capture as attachment all for details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5819) Upgrade thrift rust lib to 1.81
Liu Jiayu created THRIFT-5819: - Summary: Upgrade thrift rust lib to 1.81 Key: THRIFT-5819 URL: https://issues.apache.org/jira/browse/THRIFT-5819 Project: Thrift Issue Type: Bug Reporter: Liu Jiayu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5819) Upgrade thrift rust lib to 1.81
[ https://issues.apache.org/jira/browse/THRIFT-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Jiayu updated THRIFT-5819: -- Component/s: Rust - Library > Upgrade thrift rust lib to 1.81 > --- > > Key: THRIFT-5819 > URL: https://issues.apache.org/jira/browse/THRIFT-5819 > Project: Thrift > Issue Type: Improvement > Components: Rust - Library >Reporter: Liu Jiayu >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5819) Upgrade thrift rust lib to 1.81
[ https://issues.apache.org/jira/browse/THRIFT-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Jiayu updated THRIFT-5819: -- Issue Type: Improvement (was: Bug) > Upgrade thrift rust lib to 1.81 > --- > > Key: THRIFT-5819 > URL: https://issues.apache.org/jira/browse/THRIFT-5819 > Project: Thrift > Issue Type: Improvement >Reporter: Liu Jiayu >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5819) Upgrade thrift rust lib to 1.81
[ https://issues.apache.org/jira/browse/THRIFT-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Jiayu updated THRIFT-5819: -- Priority: Minor (was: Major) > Upgrade thrift rust lib to 1.81 > --- > > Key: THRIFT-5819 > URL: https://issues.apache.org/jira/browse/THRIFT-5819 > Project: Thrift > Issue Type: Improvement >Reporter: Liu Jiayu >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5818) Add AIX support
[
https://issues.apache.org/jira/browse/THRIFT-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuxuan Wang updated THRIFT-5818:
Affects Version/s: 0.21.0
> Add AIX support
> ---
>
> Key: THRIFT-5818
> URL: https://issues.apache.org/jira/browse/THRIFT-5818
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.21.0
> Environment: {noformat}
> -bash-5.2$ go version
> go version go1.23.1 aix/ppc64 {noformat}
>Reporter: John Troy
>Assignee: John Troy
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Building the Go library on AIX results in the following error:
> {noformat}
> -bash-5.2$ go build ./lib/go/thrift
> # github.com/apache/thrift/lib/go/thrift
> lib/go/thrift/socket_unix_conn.go:61:80: undefined:
> syscall.MSG_DONTWAIT{noformat}
> Unlike most other POSIX platforms, AIX does not have a MSG_DONTWAIT. On AIX
> matching behavior can be achieved with the MSG_NONBLOCK flag instead. I will
> open a PR on github with a suggested patch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (THRIFT-5818) Add AIX support
[
https://issues.apache.org/jira/browse/THRIFT-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuxuan Wang reassigned THRIFT-5818:
---
Assignee: John Troy
> Add AIX support
> ---
>
> Key: THRIFT-5818
> URL: https://issues.apache.org/jira/browse/THRIFT-5818
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
> Environment: {noformat}
> -bash-5.2$ go version
> go version go1.23.1 aix/ppc64 {noformat}
>Reporter: John Troy
>Assignee: John Troy
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Building the Go library on AIX results in the following error:
> {noformat}
> -bash-5.2$ go build ./lib/go/thrift
> # github.com/apache/thrift/lib/go/thrift
> lib/go/thrift/socket_unix_conn.go:61:80: undefined:
> syscall.MSG_DONTWAIT{noformat}
> Unlike most other POSIX platforms, AIX does not have a MSG_DONTWAIT. On AIX
> matching behavior can be achieved with the MSG_NONBLOCK flag instead. I will
> open a PR on github with a suggested patch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5818) Add AIX support
[
https://issues.apache.org/jira/browse/THRIFT-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuxuan Wang updated THRIFT-5818:
Fix Version/s: 0.22.0
> Add AIX support
> ---
>
> Key: THRIFT-5818
> URL: https://issues.apache.org/jira/browse/THRIFT-5818
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.21.0
> Environment: {noformat}
> -bash-5.2$ go version
> go version go1.23.1 aix/ppc64 {noformat}
>Reporter: John Troy
>Assignee: John Troy
>Priority: Major
> Fix For: 0.22.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Building the Go library on AIX results in the following error:
> {noformat}
> -bash-5.2$ go build ./lib/go/thrift
> # github.com/apache/thrift/lib/go/thrift
> lib/go/thrift/socket_unix_conn.go:61:80: undefined:
> syscall.MSG_DONTWAIT{noformat}
> Unlike most other POSIX platforms, AIX does not have a MSG_DONTWAIT. On AIX
> matching behavior can be achieved with the MSG_NONBLOCK flag instead. I will
> open a PR on github with a suggested patch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5775) Kotlin build failed
[
https://issues.apache.org/jira/browse/THRIFT-5775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885042#comment-17885042
]
Thomas Bruggink commented on THRIFT-5775:
-
This can be resolved by adding JDK 8 to the docker image.
> Kotlin build failed
> ---
>
> Key: THRIFT-5775
> URL: https://issues.apache.org/jira/browse/THRIFT-5775
> Project: Thrift
> Issue Type: Bug
> Components: Kotlin - Compiler, Kotlin - Library
>Reporter: Volodymyr Panivko
>Assignee: Thomas Bruggink
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm trying to run cross test in docker but i'm getting an error
>
>
> {code:java}
> Making all in kotlin
> make[3]: Entering directory '/thrift/src/lib/kotlin'
> /usr/local/bin/gradle assemble \
> -Pthrift.version=0.21.0 \
> -Pthrift.compiler=/thrift/src/compiler/cpp/thrift \
> --console=plain
> FAILURE: Build failed with an exception.
> * What went wrong:
> A problem occurred configuring root project 'libthrift-kotlin'.
> > Failed to calculate the value of task ':compileJava' property
> > 'javaCompiler'.
> > No matching toolchains found for requested specification:
> {languageVersion=8, vendor=any, implementation=vendor-specific} for LINUX on
> x86_64.
> > No locally installed toolchains match and toolchain download
> repositories have not been configured.
> * Try:
> > Learn more about toolchain auto-detection at
> > https://docs.gradle.org/8.4/userguide/toolchains.html#sec:auto_detection.
> > Learn more about toolchain repositories at
> > https://docs.gradle.org/8.4/userguide/toolchains.html#sub:download_repositories.
> > Run with --stacktrace option to get the stack trace.
> > Run with --info or --debug option to get more log output.
> > Run with --scan to get full insights.
> > Get more help at https://help.gradle.org.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (THRIFT-5775) Kotlin build failed
[
https://issues.apache.org/jira/browse/THRIFT-5775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bruggink reassigned THRIFT-5775:
---
Assignee: Thomas Bruggink
> Kotlin build failed
> ---
>
> Key: THRIFT-5775
> URL: https://issues.apache.org/jira/browse/THRIFT-5775
> Project: Thrift
> Issue Type: Bug
> Components: Kotlin - Compiler, Kotlin - Library
>Reporter: Volodymyr Panivko
>Assignee: Thomas Bruggink
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm trying to run cross test in docker but i'm getting an error
>
>
> {code:java}
> Making all in kotlin
> make[3]: Entering directory '/thrift/src/lib/kotlin'
> /usr/local/bin/gradle assemble \
> -Pthrift.version=0.21.0 \
> -Pthrift.compiler=/thrift/src/compiler/cpp/thrift \
> --console=plain
> FAILURE: Build failed with an exception.
> * What went wrong:
> A problem occurred configuring root project 'libthrift-kotlin'.
> > Failed to calculate the value of task ':compileJava' property
> > 'javaCompiler'.
> > No matching toolchains found for requested specification:
> {languageVersion=8, vendor=any, implementation=vendor-specific} for LINUX on
> x86_64.
> > No locally installed toolchains match and toolchain download
> repositories have not been configured.
> * Try:
> > Learn more about toolchain auto-detection at
> > https://docs.gradle.org/8.4/userguide/toolchains.html#sec:auto_detection.
> > Learn more about toolchain repositories at
> > https://docs.gradle.org/8.4/userguide/toolchains.html#sub:download_repositories.
> > Run with --stacktrace option to get the stack trace.
> > Run with --info or --debug option to get more log output.
> > Run with --scan to get full insights.
> > Get more help at https://help.gradle.org.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (THRIFT-5706) C++ SecurityTest/SecurityFromBufferTest won't build with OpenSSL v1
[
https://issues.apache.org/jira/browse/THRIFT-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bruggink reassigned THRIFT-5706:
---
Assignee: Thomas Bruggink
> C++ SecurityTest/SecurityFromBufferTest won't build with OpenSSL v1
> ---
>
> Key: THRIFT-5706
> URL: https://issues.apache.org/jira/browse/THRIFT-5706
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.19.0
>Reporter: Joe McDonnell
>Assignee: Thomas Bruggink
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> C++ SecurityTest / SecurityFromBufferTest hit this error when trying to build:
> {noformat}
> SecurityTest.cpp: In member function ‘void
> SecurityTest::ssl_security_matrix::test_method()’:
> SecurityTest.cpp:224:22: error: ‘OPENSSL_VERSION_MAJOR’ was not declared in
> this scope; did you mean ‘OPENSSL_VERSION_NUMBER’?
> 224 | bool ossl1 = OPENSSL_VERSION_MAJOR == 1;
> | ^
> | OPENSSL_VERSION_NUMBER
> make[5]: *** [Makefile:1407: SecurityTest.o] Error 1
> {noformat}
> OPENSSL_VERSION_MAJOR is new in OpenSSL 3. Older versions of OpenSSL used
> OPENSSL_VERSION_NUMBER. Here is the description from my Ubuntu 20 box:
> {noformat}
> /*-
> * Numeric release version identifier:
> * MNNFFPPS: major minor fix patch status
> * The status nibble has one of the values 0 for development, 1 to e for betas
> * 1 to 14, and f for release. The patch level is exactly that.
> * For example:
> * 0.9.3-dev 0x00903000
> * 0.9.3-beta1 0x00903001
> * 0.9.3-beta2-dev 0x00903002
> * 0.9.3-beta2 0x00903002 (same as ...beta2-dev)
> * 0.9.3 0x0090300f
> * 0.9.3a 0x0090301f
> * 0.9.4 0x0090400f
> * 1.2.3z 0x102031af
> *
> * For continuity reasons (because 0.9.5 is already out, and is coded
> * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level
> * part is slightly different, by setting the highest bit. This means
> * that 0.9.5a looks like this: 0x0090581f. At 0.9.6, we can start
> * with 0x0090600S...
> *
> * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.)
> * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for
> * major minor fix final patch/beta)
> */
> # define OPENSSL_VERSION_NUMBER 0x1010106fL{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5706) C++ SecurityTest/SecurityFromBufferTest won't build with OpenSSL v1
[
https://issues.apache.org/jira/browse/THRIFT-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Bruggink resolved THRIFT-5706.
-
Fix Version/s: 0.21.0
Resolution: Fixed
> C++ SecurityTest/SecurityFromBufferTest won't build with OpenSSL v1
> ---
>
> Key: THRIFT-5706
> URL: https://issues.apache.org/jira/browse/THRIFT-5706
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.19.0
>Reporter: Joe McDonnell
>Assignee: Thomas Bruggink
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> C++ SecurityTest / SecurityFromBufferTest hit this error when trying to build:
> {noformat}
> SecurityTest.cpp: In member function ‘void
> SecurityTest::ssl_security_matrix::test_method()’:
> SecurityTest.cpp:224:22: error: ‘OPENSSL_VERSION_MAJOR’ was not declared in
> this scope; did you mean ‘OPENSSL_VERSION_NUMBER’?
> 224 | bool ossl1 = OPENSSL_VERSION_MAJOR == 1;
> | ^
> | OPENSSL_VERSION_NUMBER
> make[5]: *** [Makefile:1407: SecurityTest.o] Error 1
> {noformat}
> OPENSSL_VERSION_MAJOR is new in OpenSSL 3. Older versions of OpenSSL used
> OPENSSL_VERSION_NUMBER. Here is the description from my Ubuntu 20 box:
> {noformat}
> /*-
> * Numeric release version identifier:
> * MNNFFPPS: major minor fix patch status
> * The status nibble has one of the values 0 for development, 1 to e for betas
> * 1 to 14, and f for release. The patch level is exactly that.
> * For example:
> * 0.9.3-dev 0x00903000
> * 0.9.3-beta1 0x00903001
> * 0.9.3-beta2-dev 0x00903002
> * 0.9.3-beta2 0x00903002 (same as ...beta2-dev)
> * 0.9.3 0x0090300f
> * 0.9.3a 0x0090301f
> * 0.9.4 0x0090400f
> * 1.2.3z 0x102031af
> *
> * For continuity reasons (because 0.9.5 is already out, and is coded
> * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level
> * part is slightly different, by setting the highest bit. This means
> * that 0.9.5a looks like this: 0x0090581f. At 0.9.6, we can start
> * with 0x0090600S...
> *
> * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.)
> * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for
> * major minor fix final patch/beta)
> */
> # define OPENSSL_VERSION_NUMBER 0x1010106fL{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5706) C++ SecurityTest/SecurityFromBufferTest won't build with OpenSSL v1
[
https://issues.apache.org/jira/browse/THRIFT-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885034#comment-17885034
]
Thomas Bruggink commented on THRIFT-5706:
-
confirmed as resolved in thrift 0.21.0
> C++ SecurityTest/SecurityFromBufferTest won't build with OpenSSL v1
> ---
>
> Key: THRIFT-5706
> URL: https://issues.apache.org/jira/browse/THRIFT-5706
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.19.0
>Reporter: Joe McDonnell
>Assignee: Thomas Bruggink
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> C++ SecurityTest / SecurityFromBufferTest hit this error when trying to build:
> {noformat}
> SecurityTest.cpp: In member function ‘void
> SecurityTest::ssl_security_matrix::test_method()’:
> SecurityTest.cpp:224:22: error: ‘OPENSSL_VERSION_MAJOR’ was not declared in
> this scope; did you mean ‘OPENSSL_VERSION_NUMBER’?
> 224 | bool ossl1 = OPENSSL_VERSION_MAJOR == 1;
> | ^
> | OPENSSL_VERSION_NUMBER
> make[5]: *** [Makefile:1407: SecurityTest.o] Error 1
> {noformat}
> OPENSSL_VERSION_MAJOR is new in OpenSSL 3. Older versions of OpenSSL used
> OPENSSL_VERSION_NUMBER. Here is the description from my Ubuntu 20 box:
> {noformat}
> /*-
> * Numeric release version identifier:
> * MNNFFPPS: major minor fix patch status
> * The status nibble has one of the values 0 for development, 1 to e for betas
> * 1 to 14, and f for release. The patch level is exactly that.
> * For example:
> * 0.9.3-dev 0x00903000
> * 0.9.3-beta1 0x00903001
> * 0.9.3-beta2-dev 0x00903002
> * 0.9.3-beta2 0x00903002 (same as ...beta2-dev)
> * 0.9.3 0x0090300f
> * 0.9.3a 0x0090301f
> * 0.9.4 0x0090400f
> * 1.2.3z 0x102031af
> *
> * For continuity reasons (because 0.9.5 is already out, and is coded
> * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level
> * part is slightly different, by setting the highest bit. This means
> * that 0.9.5a looks like this: 0x0090581f. At 0.9.6, we can start
> * with 0x0090600S...
> *
> * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.)
> * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for
> * major minor fix final patch/beta)
> */
> # define OPENSSL_VERSION_NUMBER 0x1010106fL{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5804) Add uuid support in Lua
[ https://issues.apache.org/jira/browse/THRIFT-5804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884995#comment-17884995 ] Thomas Bruggink commented on THRIFT-5804: - Implementation done here: https://github.com/apache/thrift/pull/3012/commits/b1d97999c998b9f14d635f401c9b133e0d2b1143 > Add uuid support in Lua > --- > > Key: THRIFT-5804 > URL: https://issues.apache.org/jira/browse/THRIFT-5804 > Project: Thrift > Issue Type: New Feature > Components: Lua - Compiler >Reporter: Thomas Bruggink >Assignee: Thomas Bruggink >Priority: Major > > Add support for the new uuid field in Lua for Binary, Compact and Json. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5818) Add AIX support
[
https://issues.apache.org/jira/browse/THRIFT-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Troy updated THRIFT-5818:
--
Summary: Add AIX support (was: Go library doesn't support AIX)
> Add AIX support
> ---
>
> Key: THRIFT-5818
> URL: https://issues.apache.org/jira/browse/THRIFT-5818
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
> Environment: {noformat}
> -bash-5.2$ go version
> go version go1.23.1 aix/ppc64 {noformat}
>Reporter: John Troy
>Priority: Major
>
> Building the Go library on AIX results in the following error:
> {noformat}
> -bash-5.2$ go build ./lib/go/thrift
> # github.com/apache/thrift/lib/go/thrift
> lib/go/thrift/socket_unix_conn.go:61:80: undefined:
> syscall.MSG_DONTWAIT{noformat}
> Unlike most other POSIX platforms, AIX does not have a MSG_DONTWAIT. On AIX
> matching behavior can be achieved with the MSG_NONBLOCK flag instead. I will
> open a PR on github with a suggested patch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (THRIFT-5818) Go library doesn't support AIX
John Troy created THRIFT-5818:
-
Summary: Go library doesn't support AIX
Key: THRIFT-5818
URL: https://issues.apache.org/jira/browse/THRIFT-5818
Project: Thrift
Issue Type: Bug
Components: Go - Library
Environment: {noformat}
-bash-5.2$ go version
go version go1.23.1 aix/ppc64 {noformat}
Reporter: John Troy
Building the Go library on AIX results in the following error:
{noformat}
-bash-5.2$ go build ./lib/go/thrift
# github.com/apache/thrift/lib/go/thrift
lib/go/thrift/socket_unix_conn.go:61:80: undefined:
syscall.MSG_DONTWAIT{noformat}
Unlike most other POSIX platforms, AIX does not have a MSG_DONTWAIT. On AIX
matching behavior can be achieved with the MSG_NONBLOCK flag instead. I will
open a PR on github with a suggested patch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5722) Thrift for Rust should support set timeout
[ https://issues.apache.org/jira/browse/THRIFT-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881658#comment-17881658 ] Nick commented on THRIFT-5722: -- I came here to post about being able to configure timeouts, graceful shutdown, etc.. This issue is fitting. I'll see how I go with `TTcpChannel`, but it would be nice if these things were configurable when creating a `TServer`, and like you say, configurable per procedure. > Thrift for Rust should support set timeout > -- > > Key: THRIFT-5722 > URL: https://issues.apache.org/jira/browse/THRIFT-5722 > Project: Thrift > Issue Type: Bug > Components: Rust - Library >Affects Versions: 0.18.1 >Reporter: Z Yn >Priority: Major > > There is no easy way to set timeout in Rust Client. User can only create a > TcpStreamand and set timeout as first, then build TTcpChannel from this > TcpStream. > [https://docs.rs/thrift/0.17.0/thrift/transport/struct.TTcpChannel.html#method.with_stream] > Also, It's impossible to set different read/write timeout for each function. > > TimedOut error kind exits. It comes from std::io::ErrorKind::TimedOut > [https://docs.rs/thrift/0.17.0/src/thrift/errors.rs.html#361-376] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880416#comment-17880416
]
Victor commented on THRIFT-5812:
Whoops, I deleted the repository indeed. Basically the issue is the server uses
a, say TCP transport, inside a {{TFramedTransport}}, while the client uses a
raw TCP transport. So your transport initialisation on the client side should
look like {{transport = TFramedTransport(TSocket(/* ... */))}}.
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0, 0.20.0
>Reporter: Victor
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0
>
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
> on this issue that also has the problem with clients in other languages so
> it probably comes from the Rust library. -Also I am reporting it on version
> 0.17.0 because it is the latest available version of thrift on crates.io.-
> The issue also occurs when using the latest 0.21.0 Rust library (commit
> e98d6b1).
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (THRIFT-5371) Max Message Size is eventually exceeded when using TFramedTransport
[ https://issues.apache.org/jira/browse/THRIFT-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880030#comment-17880030 ] Jens Geyer edited comment on THRIFT-5371 at 9/7/24 10:54 AM: - [~rrathmann] Great! This is a good starting point: [Apache Thrift - How To Contribute|https://thrift.apache.org/docs/HowToContribute] was (Author: jensg): Great! This is a good starting point: [Apache Thrift - How To Contribute|https://thrift.apache.org/docs/HowToContribute] > Max Message Size is eventually exceeded when using TFramedTransport > --- > > Key: THRIFT-5371 > URL: https://issues.apache.org/jira/browse/THRIFT-5371 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.14.1 > Environment: Windows 2010, Visual Studio 2017, CMake 3.15.2 >Reporter: Paul Caswell >Priority: Major > > I have been trying to upgrade our application from Thrift 0.11.0 to 0.14.1 > and have noticed what I think is a bug. > Our thrift application uses a TFramedTransport to transmit large quantities > of data from the client to the server using a oneway call. The transports > are all created using the (new) default TConfiguration class giving a maximum > message size of 100MB. > Our application sends data through the thrift library in circa 10MB blocks > using a oneway call. On the 10th call the server terminates with a > TTransportException thrown on line 329 of TTransport.h. > I believe this is happening because the TFramedTransport doesn't reset the > 'knownMessageSize_' and 'remainingMessageSize_' counters when a message > transfer is completed. This means that the counter continually reduces until > the exception is thrown. I am new to the thrift library and so perhaps I > have this wrong but it's what looks like is happening to me. > I can make the library work by adding resetConsumedMessageSize(); inside > TFramedTransport::readEnd() in file TBufferTransports.cpp (at line 310). Is > this the correct solution? > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (THRIFT-5371) Max Message Size is eventually exceeded when using TFramedTransport
[ https://issues.apache.org/jira/browse/THRIFT-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879672#comment-17879672 ] Raul Rathmann commented on THRIFT-5371: --- This issue is still present. Related to THRIFT-5492, which is marked as closed and accepted into 0.21.0. However, modifications performed did not address the problem for TFramedTransport. The suggested change by original reporter does seem to function correctly for TFramedTransport. Other Transport types may also be affected and not fixed by THRIFT-5492. I can attempt to form a pull request however I am new to posting issues and contributing to Apache repo. > Max Message Size is eventually exceeded when using TFramedTransport > --- > > Key: THRIFT-5371 > URL: https://issues.apache.org/jira/browse/THRIFT-5371 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.14.1 > Environment: Windows 2010, Visual Studio 2017, CMake 3.15.2 >Reporter: Paul Caswell >Priority: Major > > I have been trying to upgrade our application from Thrift 0.11.0 to 0.14.1 > and have noticed what I think is a bug. > Our thrift application uses a TFramedTransport to transmit large quantities > of data from the client to the server using a oneway call. The transports > are all created using the (new) default TConfiguration class giving a maximum > message size of 100MB. > Our application sends data through the thrift library in circa 10MB blocks > using a oneway call. On the 10th call the server terminates with a > TTransportException thrown on line 329 of TTransport.h. > I believe this is happening because the TFramedTransport doesn't reset the > 'knownMessageSize_' and 'remainingMessageSize_' counters when a message > transfer is completed. This means that the counter continually reduces until > the exception is thrown. I am new to the thrift library and so perhaps I > have this wrong but it's what looks like is happening to me. > I can make the library work by adding resetConsumedMessageSize(); inside > TFramedTransport::readEnd() in file TBufferTransports.cpp (at line 310). Is > this the correct solution? > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5817) [C++] Avoid copy of TUuid
Carel created THRIFT-5817: - Summary: [C++] Avoid copy of TUuid Key: THRIFT-5817 URL: https://issues.apache.org/jira/browse/THRIFT-5817 Project: Thrift Issue Type: Bug Components: C glib - Compiler, C++ - Compiler Environment: C++ and C generator Reporter: Carel Assignee: Carel Fix For: 0.21.0 The current implementation of the TUuid type generates code that copies the TUuid type and does not use cont reference like other complex types, like std::string. For consistency and performance the copy should be avoided and a const reference must be passed. See [this|https://github.com/apache/thrift/pull/3035#discussion_r1744537147] comment -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-5816) Fix UUID for boost 1.86.0 (change in {{data}} member usage)
[
https://issues.apache.org/jira/browse/THRIFT-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5816.
Fix Version/s: 0.21.0
Resolution: Fixed
> Fix UUID for boost 1.86.0 (change in {{data}} member usage)
> ---
>
> Key: THRIFT-5816
> URL: https://issues.apache.org/jira/browse/THRIFT-5816
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.20.0
>Reporter: Mario Emmenlauer
>Assignee: Carel
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I have just updated boost to 1.86.0 (current latest), and thrift to current
> latest master. Now the UUID support does not build for me. I can see that a
> relevant change was in the PR for this issue, but I don't know for sure if
> boost 1.86.0 is part of the breaking change.
> The following code does not build for me:
> {code}
> TUuid(const boost::uuids::uuid& buuid) noexcept
> {
> std::copy(std::begin(buuid.data), std::end(buuid.data),
> std::begin(this->data_));
> }
> {code}
> The error I get with clang 18 on Ubuntu 22.04 is:
> {code}
> [build] /data/tmp/Debug/thrift/lib/cpp/src/thrift/TUuid.h:93:15: error: no
> matching function for call to 'begin'
> [build]93 | std::copy(std::begin(buuid.data), std::end(buuid.data),
> std::begin(this->data_));
> [build] | ^~
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/initializer_list:90:5:
> note: candidate template ignored: could not match 'initializer_list<_Tp>'
> against 'data_type'
> [build]90 | begin(initializer_list<_Tp> __ils) noexcept
> [build] | ^
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:52:5:
> note: candidate template ignored: substitution failure [with _Container =
> const data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
> [build]52 | begin(_Container& __cont) -> decltype(__cont.begin())
> [build] | ^~
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:63:5:
> note: candidate template ignored: substitution failure [with _Container =
> data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
> [build]63 | begin(const _Container& __cont) ->
> decltype(__cont.begin())
> [build] | ^ ~
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:95:5:
> note: candidate template ignored: could not match '_Tp[_Nm]' against 'const
> data_type'
> [build]95 | begin(_Tp (&__arr)[_Nm]) noexcept
> [build] | ^
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:113:31:
> note: candidate template ignored: could not match 'valarray<_Tp>' against
> 'const data_type'
> [build] 113 | template _Tp* begin(valarray<_Tp>&) noexcept;
> [build] | ^
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:114:37:
> note: candidate template ignored: could not match 'const valarray<_Tp>'
> against 'const data_type'
> [build] 114 | template const _Tp* begin(const
> valarray<_Tp>&) noexcept;
> [build] | ^
> {code}
> I think the reason is that according to
> https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
> the use of the data member is now discouraged, and does not work in all
> cases any more. So it seems this broke with boost 1.86.0, but I'm not sure
> how well earlier boost versions supported this.
> I'm not really knowledgeable with boost::uuids. But according to a quick
> search, the iterators are available directly on the uuid, instead of the data
> member?! So the following compiles for me:
> {code}
> TUuid(const boost::uuids::uuid& buuid) noexcept
> {
> std::copy(std::begin(buuid), std::end(buuid), std::begin(this->data_));
> }
> {code}
> Highlight: Remove the {{.data}} from {{buuid}} in two places.
> Opinions?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5816) Fix UUID for boost 1.86.0 (change in {{data}} member usage)
[
https://issues.apache.org/jira/browse/THRIFT-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879339#comment-17879339
]
Carel commented on THRIFT-5816:
---
[~emmenlau] [~jensg]
I tested with boost 1.86 and the changes fixes the issue
> Fix UUID for boost 1.86.0 (change in {{data}} member usage)
> ---
>
> Key: THRIFT-5816
> URL: https://issues.apache.org/jira/browse/THRIFT-5816
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.20.0
>Reporter: Mario Emmenlauer
>Assignee: Carel
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I have just updated boost to 1.86.0 (current latest), and thrift to current
> latest master. Now the UUID support does not build for me. I can see that a
> relevant change was in the PR for this issue, but I don't know for sure if
> boost 1.86.0 is part of the breaking change.
> The following code does not build for me:
> {code}
> TUuid(const boost::uuids::uuid& buuid) noexcept
> {
> std::copy(std::begin(buuid.data), std::end(buuid.data),
> std::begin(this->data_));
> }
> {code}
> The error I get with clang 18 on Ubuntu 22.04 is:
> {code}
> [build] /data/tmp/Debug/thrift/lib/cpp/src/thrift/TUuid.h:93:15: error: no
> matching function for call to 'begin'
> [build]93 | std::copy(std::begin(buuid.data), std::end(buuid.data),
> std::begin(this->data_));
> [build] | ^~
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/initializer_list:90:5:
> note: candidate template ignored: could not match 'initializer_list<_Tp>'
> against 'data_type'
> [build]90 | begin(initializer_list<_Tp> __ils) noexcept
> [build] | ^
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:52:5:
> note: candidate template ignored: substitution failure [with _Container =
> const data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
> [build]52 | begin(_Container& __cont) -> decltype(__cont.begin())
> [build] | ^~
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:63:5:
> note: candidate template ignored: substitution failure [with _Container =
> data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
> [build]63 | begin(const _Container& __cont) ->
> decltype(__cont.begin())
> [build] | ^ ~
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:95:5:
> note: candidate template ignored: could not match '_Tp[_Nm]' against 'const
> data_type'
> [build]95 | begin(_Tp (&__arr)[_Nm]) noexcept
> [build] | ^
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:113:31:
> note: candidate template ignored: could not match 'valarray<_Tp>' against
> 'const data_type'
> [build] 113 | template _Tp* begin(valarray<_Tp>&) noexcept;
> [build] | ^
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:114:37:
> note: candidate template ignored: could not match 'const valarray<_Tp>'
> against 'const data_type'
> [build] 114 | template const _Tp* begin(const
> valarray<_Tp>&) noexcept;
> [build] | ^
> {code}
> I think the reason is that according to
> https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
> the use of the data member is now discouraged, and does not work in all
> cases any more. So it seems this broke with boost 1.86.0, but I'm not sure
> how well earlier boost versions supported this.
> I'm not really knowledgeable with boost::uuids. But according to a quick
> search, the iterators are available directly on the uuid, instead of the data
> member?! So the following compiles for me:
> {code}
> TUuid(const boost::uuids::uuid& buuid) noexcept
> {
> std::copy(std::begin(buuid), std::end(buuid), std::begin(this->data_));
> }
> {code}
> Highlight: Remove the {{.data}} from {{buuid}} in two places.
> Opinions?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5816) Fix UUID for boost 1.86.0 (change in {{data}} member usage)
[
https://issues.apache.org/jira/browse/THRIFT-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879016#comment-17879016
]
Carel commented on THRIFT-5816:
---
[~emmenlau] I did create a draft PR: https://github.com/apache/thrift/pull/3035
I am still trying to figure out how to get the latest boost in my development
container, I made the changes based on your comment/suggestion and it still
seems to work for the boost version that I have (looks like 1.74)
> Fix UUID for boost 1.86.0 (change in {{data}} member usage)
> ---
>
> Key: THRIFT-5816
> URL: https://issues.apache.org/jira/browse/THRIFT-5816
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.20.0
>Reporter: Mario Emmenlauer
>Assignee: Carel
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have just updated boost to 1.86.0 (current latest), and thrift to current
> latest master. Now the UUID support does not build for me. I can see that a
> relevant change was in the PR for this issue, but I don't know for sure if
> boost 1.86.0 is part of the breaking change.
> The following code does not build for me:
> {code}
> TUuid(const boost::uuids::uuid& buuid) noexcept
> {
> std::copy(std::begin(buuid.data), std::end(buuid.data),
> std::begin(this->data_));
> }
> {code}
> The error I get with clang 18 on Ubuntu 22.04 is:
> {code}
> [build] /data/tmp/Debug/thrift/lib/cpp/src/thrift/TUuid.h:93:15: error: no
> matching function for call to 'begin'
> [build]93 | std::copy(std::begin(buuid.data), std::end(buuid.data),
> std::begin(this->data_));
> [build] | ^~
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/initializer_list:90:5:
> note: candidate template ignored: could not match 'initializer_list<_Tp>'
> against 'data_type'
> [build]90 | begin(initializer_list<_Tp> __ils) noexcept
> [build] | ^
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:52:5:
> note: candidate template ignored: substitution failure [with _Container =
> const data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
> [build]52 | begin(_Container& __cont) -> decltype(__cont.begin())
> [build] | ^~
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:63:5:
> note: candidate template ignored: substitution failure [with _Container =
> data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
> [build]63 | begin(const _Container& __cont) ->
> decltype(__cont.begin())
> [build] | ^ ~
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:95:5:
> note: candidate template ignored: could not match '_Tp[_Nm]' against 'const
> data_type'
> [build]95 | begin(_Tp (&__arr)[_Nm]) noexcept
> [build] | ^
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:113:31:
> note: candidate template ignored: could not match 'valarray<_Tp>' against
> 'const data_type'
> [build] 113 | template _Tp* begin(valarray<_Tp>&) noexcept;
> [build] | ^
> [build]
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:114:37:
> note: candidate template ignored: could not match 'const valarray<_Tp>'
> against 'const data_type'
> [build] 114 | template const _Tp* begin(const
> valarray<_Tp>&) noexcept;
> [build] | ^
> {code}
> I think the reason is that according to
> https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
> the use of the data member is now discouraged, and does not work in all
> cases any more. So it seems this broke with boost 1.86.0, but I'm not sure
> how well earlier boost versions supported this.
> I'm not really knowledgeable with boost::uuids. But according to a quick
> search, the iterators are available directly on the uuid, instead of the data
> member?! So the following compiles for me:
> {code}
> TUuid(const boost::uuids::uuid& buuid) noexcept
> {
> std::copy(std::begin(buuid), std::end(buuid), std::begin(this->data_));
> }
> {code}
> Highlight: Remove the {{.data}} from {{buuid}} in two places.
> Opinions?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5773) UUID wrapper for C++
[ https://issues.apache.org/jira/browse/THRIFT-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878900#comment-17878900 ] Mario Emmenlauer commented on THRIFT-5773: -- The follow-up is now in https://issues.apache.org/jira/browse/THRIFT-5816 > UUID wrapper for C++ > > > Key: THRIFT-5773 > URL: https://issues.apache.org/jira/browse/THRIFT-5773 > Project: Thrift > Issue Type: New Feature > Components: C++ - Compiler >Reporter: Carel >Assignee: Carel >Priority: Major > Fix For: 0.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Continuation of THRIFT-5772 > Add a strong wrapper type for UUID support in C++ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5816) Fix UUID for boost 1.86.0 (change in {{data}} member usage)
Mario Emmenlauer created THRIFT-5816:
Summary: Fix UUID for boost 1.86.0 (change in {{data}} member
usage)
Key: THRIFT-5816
URL: https://issues.apache.org/jira/browse/THRIFT-5816
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.20.0
Reporter: Mario Emmenlauer
Assignee: Carel
I have just updated boost to 1.86.0 (current latest), and thrift to current
latest master. Now the UUID support does not build for me. I can see that a
relevant change was in the PR for this issue, but I don't know for sure if
boost 1.86.0 is part of the breaking change.
The following code does not build for me:
{code}
TUuid(const boost::uuids::uuid& buuid) noexcept
{
std::copy(std::begin(buuid.data), std::end(buuid.data),
std::begin(this->data_));
}
{code}
The error I get with clang 18 on Ubuntu 22.04 is:
{code}
[build] /data/tmp/Debug/thrift/lib/cpp/src/thrift/TUuid.h:93:15: error: no
matching function for call to 'begin'
[build]93 | std::copy(std::begin(buuid.data), std::end(buuid.data),
std::begin(this->data_));
[build] | ^~
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/initializer_list:90:5:
note: candidate template ignored: could not match 'initializer_list<_Tp>'
against 'data_type'
[build]90 | begin(initializer_list<_Tp> __ils) noexcept
[build] | ^
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:52:5:
note: candidate template ignored: substitution failure [with _Container =
const data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]52 | begin(_Container& __cont) -> decltype(__cont.begin())
[build] | ^~
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:63:5:
note: candidate template ignored: substitution failure [with _Container =
data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]63 | begin(const _Container& __cont) -> decltype(__cont.begin())
[build] | ^ ~
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:95:5:
note: candidate template ignored: could not match '_Tp[_Nm]' against 'const
data_type'
[build]95 | begin(_Tp (&__arr)[_Nm]) noexcept
[build] | ^
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:113:31:
note: candidate template ignored: could not match 'valarray<_Tp>' against
'const data_type'
[build] 113 | template _Tp* begin(valarray<_Tp>&) noexcept;
[build] | ^
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:114:37:
note: candidate template ignored: could not match 'const valarray<_Tp>'
against 'const data_type'
[build] 114 | template const _Tp* begin(const valarray<_Tp>&)
noexcept;
[build] | ^
{code}
I think the reason is that according to
https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
the use of the data member is now discouraged, and does not work in all cases
any more. So it seems this broke with boost 1.86.0, but I'm not sure how well
earlier boost versions supported this.
I'm not really knowledgeable with boost::uuids. But according to a quick
search, the iterators are available directly on the uuid, instead of the data
member?! So the following compiles for me:
{code}
TUuid(const boost::uuids::uuid& buuid) noexcept
{
std::copy(std::begin(buuid), std::end(buuid), std::begin(this->data_));
}
{code}
Highlight: Remove the {{.data}} from {{buuid}} in two places.
Opinions?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5773) UUID wrapper for C++
[ https://issues.apache.org/jira/browse/THRIFT-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878890#comment-17878890 ] Carel commented on THRIFT-5773: --- [~emmenlau] That looks like the correct solution yes, I guess it should still work for older boost versions. Would you be willing to create a new ticket for this and assign to me, I will try to look into it tonight. PS: I also don't like the 'please create a ticket' response but in the larger scheme of things (project level) it makes sense if each issue has a ticket and it is always best if the name of the person that found it is attached to the 'reporter' (you get some street creds). Otherwise I can see if I can create the ticket and try to fix as soon as possible. > UUID wrapper for C++ > > > Key: THRIFT-5773 > URL: https://issues.apache.org/jira/browse/THRIFT-5773 > Project: Thrift > Issue Type: New Feature > Components: C++ - Compiler >Reporter: Carel >Assignee: Carel >Priority: Major > Fix For: 0.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Continuation of THRIFT-5772 > Add a strong wrapper type for UUID support in C++ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (THRIFT-5773) UUID wrapper for C++
[
https://issues.apache.org/jira/browse/THRIFT-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878870#comment-17878870
]
Mario Emmenlauer edited comment on THRIFT-5773 at 9/3/24 12:48 PM:
---
Sorry to be a bit late to the party. I have just updated boost to 1.86.0
(current latest), and thrift to current latest master. Now the UUID support
does not build for me. I can see that a relevant change was in the PR for this
issue, but I don't know for sure if boost 1.86.0 is part of the breaking
change.
The following code does not build for me:
{code}
TUuid(const boost::uuids::uuid& buuid) noexcept
{
std::copy(std::begin(buuid.data), std::end(buuid.data),
std::begin(this->data_));
}
{code}
The error I get with clang 18 on Ubuntu 22.04 is:
{code}
[build] /data/tmp/Debug/thrift/lib/cpp/src/thrift/TUuid.h:93:15: error: no
matching function for call to 'begin'
[build]93 | std::copy(std::begin(buuid.data), std::end(buuid.data),
std::begin(this->data_));
[build] | ^~
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/initializer_list:90:5:
note: candidate template ignored: could not match 'initializer_list<_Tp>'
against 'data_type'
[build]90 | begin(initializer_list<_Tp> __ils) noexcept
[build] | ^
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:52:5:
note: candidate template ignored: substitution failure [with _Container =
const data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]52 | begin(_Container& __cont) -> decltype(__cont.begin())
[build] | ^~
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:63:5:
note: candidate template ignored: substitution failure [with _Container =
data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]63 | begin(const _Container& __cont) -> decltype(__cont.begin())
[build] | ^ ~
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:95:5:
note: candidate template ignored: could not match '_Tp[_Nm]' against 'const
data_type'
[build]95 | begin(_Tp (&__arr)[_Nm]) noexcept
[build] | ^
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:113:31:
note: candidate template ignored: could not match 'valarray<_Tp>' against
'const data_type'
[build] 113 | template _Tp* begin(valarray<_Tp>&) noexcept;
[build] | ^
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:114:37:
note: candidate template ignored: could not match 'const valarray<_Tp>'
against 'const data_type'
[build] 114 | template const _Tp* begin(const valarray<_Tp>&)
noexcept;
[build] | ^
{code}
I think the reason is that according to
https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
the use of the data member is now discouraged, and does not work in all cases
any more. So it seems this broke with boost 1.86.0, but I'm not sure how well
earlier boost versions supported this.
I'm not really knowledgeable with boost::uuids. But according to a quick
search, the iterators are available directly on the uuid, instead of the data
member?! So the following compiles for me:
{code}
TUuid(const boost::uuids::uuid& buuid) noexcept
{
std::copy(std::begin(buuid), std::end(buuid), std::begin(this->data_));
}
{code}
Highlight: Remove the {{.data}} from {{buuid}} in two places.
Opinions?
was (Author: emmenlau):
Sorry to be a bit late to the party. I have just updated boost to 1.86.0
(current latest), and thrift to current latest master. Now the UUID support
does not build for me. I can see that a relevant change was in the PR for this
issue, but I don't know if boost 1.86.0 is part of the breaking change.
The following code does not build for me:
{code}
TUuid(const boost::uuids::uuid& buuid) noexcept
{
std::copy(std::begin(buuid.data), std::end(buuid.data),
std::begin(this->data_));
}
{code}
I think the reason is that according to
https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
the use of the data member is now discouraged, and does not work in all cases
any more. The error I get with cla
[jira] [Commented] (THRIFT-5773) UUID wrapper for C++
[
https://issues.apache.org/jira/browse/THRIFT-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878870#comment-17878870
]
Mario Emmenlauer commented on THRIFT-5773:
--
Sorry to be a bit late to the party. I have just updated boost to 1.86.0
(current latest), and thrift to current latest master. Now the UUID support
does not build for me. I can see that a relevant change was in the PR for this
issue, but I don't know if boost 1.86.0 is part of the breaking change.
The following code does not build for me:
{code}
TUuid(const boost::uuids::uuid& buuid) noexcept
{
std::copy(std::begin(buuid.data), std::end(buuid.data),
std::begin(this->data_));
}
{code}
I think the reason is that according to
https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
the use of the data member is now discouraged, and does not work in all cases
any more. The error I get with clang 18 is:
{code}
[build] /data/tmp/Debug/thrift/lib/cpp/src/thrift/TUuid.h:93:15: error: no
matching function for call to 'begin'
[build]93 | std::copy(std::begin(buuid.data), std::end(buuid.data),
std::begin(this->data_));
[build] | ^~
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/initializer_list:90:5:
note: candidate template ignored: could not match 'initializer_list<_Tp>'
against 'data_type'
[build]90 | begin(initializer_list<_Tp> __ils) noexcept
[build] | ^
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:52:5:
note: candidate template ignored: substitution failure [with _Container =
const data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]52 | begin(_Container& __cont) -> decltype(__cont.begin())
[build] | ^~
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:63:5:
note: candidate template ignored: substitution failure [with _Container =
data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]63 | begin(const _Container& __cont) -> decltype(__cont.begin())
[build] | ^ ~
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:95:5:
note: candidate template ignored: could not match '_Tp[_Nm]' against 'const
data_type'
[build]95 | begin(_Tp (&__arr)[_Nm]) noexcept
[build] | ^
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:113:31:
note: candidate template ignored: could not match 'valarray<_Tp>' against
'const data_type'
[build] 113 | template _Tp* begin(valarray<_Tp>&) noexcept;
[build] | ^
[build]
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:114:37:
note: candidate template ignored: could not match 'const valarray<_Tp>'
against 'const data_type'
[build] 114 | template const _Tp* begin(const valarray<_Tp>&)
noexcept;
[build] | ^
{code}
I'm not really knowledgeable with boost::uuids, but according to a quick
search, the iterators are available directly on the uuid? So the following
compiles for me:
{code}
TUuid(const boost::uuids::uuid& buuid) noexcept
{
std::copy(std::begin(buuid), std::end(buuid), std::begin(this->data_));
}
{code}
Opinions?
> UUID wrapper for C++
>
>
> Key: THRIFT-5773
> URL: https://issues.apache.org/jira/browse/THRIFT-5773
> Project: Thrift
> Issue Type: New Feature
> Components: C++ - Compiler
>Reporter: Carel
>Assignee: Carel
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Continuation of THRIFT-5772
> Add a strong wrapper type for UUID support in C++
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5815) veralign.sh broken and incomplete
[ https://issues.apache.org/jira/browse/THRIFT-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5815: --- Attachment: 0002-THRIFT-5815-veralign.sh-broken-and-incomplete.patch > veralign.sh broken and incomplete > - > > Key: THRIFT-5815 > URL: https://issues.apache.org/jira/browse/THRIFT-5815 > Project: Thrift > Issue Type: Bug > Components: Build Process >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Trivial > Fix For: 0.21.0 > > Attachments: > 0001-THRIFT-5815-veralign.sh-broken-and-incomplete.patch, > 0002-THRIFT-5815-veralign.sh-broken-and-incomplete.patch > > > * Benchmark.csproj is missing (and lacks version number) > * path to Thrift.IntegrationTests is incorrect -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-5815) veralign.sh broken and incomplete
[ https://issues.apache.org/jira/browse/THRIFT-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5815. Fix Version/s: 0.21.0 Resolution: Fixed > veralign.sh broken and incomplete > - > > Key: THRIFT-5815 > URL: https://issues.apache.org/jira/browse/THRIFT-5815 > Project: Thrift > Issue Type: Bug > Components: Build Process >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Trivial > Fix For: 0.21.0 > > Attachments: 0001-THRIFT-5815-veralign.sh-broken-and-incomplete.patch > > > * Benchmark.csproj is missing (and lacks version number) > * path to Thrift.IntegrationTests is incorrect -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5815) veralign.sh broken and incomplete
[ https://issues.apache.org/jira/browse/THRIFT-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5815: --- Attachment: 0001-THRIFT-5815-veralign.sh-broken-and-incomplete.patch > veralign.sh broken and incomplete > - > > Key: THRIFT-5815 > URL: https://issues.apache.org/jira/browse/THRIFT-5815 > Project: Thrift > Issue Type: Bug > Components: Build Process >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Trivial > Attachments: 0001-THRIFT-5815-veralign.sh-broken-and-incomplete.patch > > > * Benchmark.csproj is missing (and lacks version number) > * path to Thrift.IntegrationTests is incorrect -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5815) veralign.sh broken and incomplete
Jens Geyer created THRIFT-5815: -- Summary: veralign.sh broken and incomplete Key: THRIFT-5815 URL: https://issues.apache.org/jira/browse/THRIFT-5815 Project: Thrift Issue Type: Bug Components: Build Process Reporter: Jens Geyer Assignee: Jens Geyer * Benchmark.csproj is missing (and lacks version number) * path to Thrift.IntegrationTests is incorrect -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-3877) C++ library don't work with HTTP (csharp server, cpp client; need cross test enhancement)
[ https://issues.apache.org/jira/browse/THRIFT-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-3877. Fix Version/s: 0.20.0 Resolution: Fixed Merged long time ago [THRIFT-3877: cpp http server buffering bug oneway · apache/thrift@ad08a8b (github.com)|https://github.com/apache/thrift/commit/ad08a8b168d95b30ca6b81ff4e6eeb62b24ce9c6] > C++ library don't work with HTTP (csharp server, cpp client; need cross test > enhancement) > - > > Key: THRIFT-3877 > URL: https://issues.apache.org/jira/browse/THRIFT-3877 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.3, 0.10.0 > Environment: Windows 7, Visual Studio 2013 (C#), Qt 5.7 (MSVC 12). > Thrift from git repo, SHA-1: 5a3f855b4e6882184f13c698855c877241144a12 (master) >Reporter: Sergey Fasman >Assignee: James E. King III >Priority: Critical > Fix For: 0.20.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Client on C++. > Tested on C# HTTP server and client — work ideal. > Then create client on C++. Client after request starts infinitly wait for > data. > For example, JSON protocol read data symbol by symbol, when trying read: it > always try to call recv function (even all data already received). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5468) Swift service generator doesn't support oneway
[ https://issues.apache.org/jira/browse/THRIFT-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5468: --- Priority: Major (was: Critical) > Swift service generator doesn't support oneway > -- > > Key: THRIFT-5468 > URL: https://issues.apache.org/jira/browse/THRIFT-5468 > Project: Thrift > Issue Type: Bug > Components: Swift - Compiler >Reporter: Kevin Wojniak >Priority: Major > > https://github.com/apache/thrift/blob/master/compiler/cpp/src/thrift/generate/t_swift_generator.cc#L2377 > This block is the logic for non-oneway functions, but there is no "else" > condition so oneway functions won't be called. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (THRIFT-5468) Swift service generator doesn't support oneway
[ https://issues.apache.org/jira/browse/THRIFT-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878663#comment-17878663 ] Jens Geyer commented on THRIFT-5468: Ping [~kwojniak_box] > Swift service generator doesn't support oneway > -- > > Key: THRIFT-5468 > URL: https://issues.apache.org/jira/browse/THRIFT-5468 > Project: Thrift > Issue Type: Bug > Components: Swift - Compiler >Reporter: Kevin Wojniak >Priority: Critical > > https://github.com/apache/thrift/blob/master/compiler/cpp/src/thrift/generate/t_swift_generator.cc#L2377 > This block is the logic for non-oneway functions, but there is no "else" > condition so oneway functions won't be called. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5530) could not resolve plugin artifact 'com.github.johnrengelman.shadow:com.github.johnrengelman.shadow.gradle.plugin:4.0.4'
[
https://issues.apache.org/jira/browse/THRIFT-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5530:
---
Fix Version/s: 0.21.0
> could not resolve plugin artifact
> 'com.github.johnrengelman.shadow:com.github.johnrengelman.shadow.gradle.plugin:4.0.4'
> ---
>
> Key: THRIFT-5530
> URL: https://issues.apache.org/jira/browse/THRIFT-5530
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Blocker
> Fix For: 0.21.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The builds started to fail all pointing to one cause:
> {code}
> * Where:
> Build file '/thrift/src/thrift-0.17.0/lib/java/build.gradle' line: 42
> * What went wrong:
> Plugin [id: 'com.github.johnrengelman.shadow', version: '4.0.4'] was not
> found in any of the following sources:
> - Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
> - Plugin Repositories (could not resolve plugin artifact
> 'com.github.johnrengelman.shadow:com.github.johnrengelman.shadow.gradle.plugin:4.0.4')
> Searched in the following repositories:
> Gradle Central Plugin Repository
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5800) "Could not find include file foo.thrift" probably should be failure instead of warning
[
https://issues.apache.org/jira/browse/THRIFT-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5800.
Fix Version/s: 0.21.0
Resolution: Fixed
> "Could not find include file foo.thrift" probably should be failure instead
> of warning
> --
>
> Key: THRIFT-5800
> URL: https://issues.apache.org/jira/browse/THRIFT-5800
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.20.0
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Minor
> Fix For: 0.21.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when a thrift file includes a non-exist file and don't reference it
> in any way otherwise, like this:
> {code}
> include "foo.thrift" // does not exist
> ... // don't reference anything that's foo.*
> {code}
> The compiler will generate a warning:
> {code}
> [WARNING:/path/to/file.thrift:N] Could not find include file foo.thrift
> {code}
> This probably should be failure instead of warning? Or at least be a failure
> when -strict arg is passed in, and keep at warning without -strict.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5786) Full deprecation support for go
[ https://issues.apache.org/jira/browse/THRIFT-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5786. Fix Version/s: 0.21.0 Resolution: Fixed > Full deprecation support for go > --- > > Key: THRIFT-5786 > URL: https://issues.apache.org/jira/browse/THRIFT-5786 > Project: Thrift > Issue Type: Sub-task > Components: Go - Compiler >Affects Versions: 0.20.0 >Reporter: Yuxuan Wang >Assignee: Yuxuan Wang >Priority: Major > Fix For: 0.21.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Same as THRIFT-5781 but for Go, use "Deprecated:" doccomment that's supported > by staticcheck and godoc (pkg.go.dev). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-5813) Clarify TSocket state after isOpen
[
https://issues.apache.org/jira/browse/THRIFT-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5813.
Fix Version/s: 0.21.0
Resolution: Fixed
> Clarify TSocket state after isOpen
> --
>
> Key: THRIFT-5813
> URL: https://issues.apache.org/jira/browse/THRIFT-5813
> Project: Thrift
> Issue Type: Improvement
> Components: Python - Library
>Affects Versions: 0.20.0
>Reporter: Csaba Ringhofer
>Assignee: Csaba Ringhofer
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since 0.14.0 TSocket.py tries to peek into the socket during isOpen() and
> returns false if the connection seems to be disconnected (THRIFT-5248). The
> question is whether to close the socket in that case - currently isOpen()
> doesn't close the socket, while most clients probably expect it to be closed
> if isOpen() returned false.
> This makes it hard to create a "reopen if needed" logic that works both with
> THttpClient and TSocket:
> {code}
> if not transport.isOpen():
>transport.close()
>transport.open()
> {code}
> close() throws an exception in THttpClient, while calling it is needed for
> TSocket if isOpen() returned false due to the failing peek, otherwise open()
> will throw TTransportException.ALREADY_OPEN
> Found a ticket about the same issue in Go: THRIFT-5509
> The conclusion there was to close the socket during isOpen().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5813) Clarify TSocket state after isOpen
[
https://issues.apache.org/jira/browse/THRIFT-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5813:
---
Fix Version/s: (was: 0.21.0)
> Clarify TSocket state after isOpen
> --
>
> Key: THRIFT-5813
> URL: https://issues.apache.org/jira/browse/THRIFT-5813
> Project: Thrift
> Issue Type: Improvement
> Components: Python - Library
>Affects Versions: 0.20.0
>Reporter: Csaba Ringhofer
>Assignee: Csaba Ringhofer
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since 0.14.0 TSocket.py tries to peek into the socket during isOpen() and
> returns false if the connection seems to be disconnected (THRIFT-5248). The
> question is whether to close the socket in that case - currently isOpen()
> doesn't close the socket, while most clients probably expect it to be closed
> if isOpen() returned false.
> This makes it hard to create a "reopen if needed" logic that works both with
> THttpClient and TSocket:
> {code}
> if not transport.isOpen():
>transport.close()
>transport.open()
> {code}
> close() throws an exception in THttpClient, while calling it is needed for
> TSocket if isOpen() returned false due to the failing peek, otherwise open()
> will throw TTransportException.ALREADY_OPEN
> Found a ticket about the same issue in Go: THRIFT-5509
> The conclusion there was to close the socket during isOpen().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5786) Full deprecation support for go
[ https://issues.apache.org/jira/browse/THRIFT-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5786: --- Fix Version/s: (was: 0.21.0) > Full deprecation support for go > --- > > Key: THRIFT-5786 > URL: https://issues.apache.org/jira/browse/THRIFT-5786 > Project: Thrift > Issue Type: Sub-task > Components: Go - Compiler >Affects Versions: 0.20.0 >Reporter: Yuxuan Wang >Assignee: Yuxuan Wang >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Same as THRIFT-5781 but for Go, use "Deprecated:" doccomment that's supported > by staticcheck and godoc (pkg.go.dev). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5800) "Could not find include file foo.thrift" probably should be failure instead of warning
[
https://issues.apache.org/jira/browse/THRIFT-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5800:
---
Fix Version/s: (was: 0.21.0)
> "Could not find include file foo.thrift" probably should be failure instead
> of warning
> --
>
> Key: THRIFT-5800
> URL: https://issues.apache.org/jira/browse/THRIFT-5800
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.20.0
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when a thrift file includes a non-exist file and don't reference it
> in any way otherwise, like this:
> {code}
> include "foo.thrift" // does not exist
> ... // don't reference anything that's foo.*
> {code}
> The compiler will generate a warning:
> {code}
> [WARNING:/path/to/file.thrift:N] Could not find include file foo.thrift
> {code}
> This probably should be failure instead of warning? Or at least be a failure
> when -strict arg is passed in, and keep at warning without -strict.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5809) Under header_http-ip-ssl protocol, Go will prompt TLS handshake error
[
https://issues.apache.org/jira/browse/THRIFT-5809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5809:
---
Component/s: Go - Library
> Under header_http-ip-ssl protocol, Go will prompt TLS handshake error
> -
>
> Key: THRIFT-5809
> URL: https://issues.apache.org/jira/browse/THRIFT-5809
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Reporter: Team_RPCtester
>Priority: Major
>
> Hi,
> We find that when using Node.js as the client and Go as the server, there is
> an error on the server side: http: TLS handshake error from 127.0.0.1:42648:
> EOF. This occurs under the header_http-ip-ssl protocol. Despite the error,
> the server is still able to transmit the value. While other protocols do not
> prompt this error.
> The test case is as follows:
>
> {code:java}
> namespace go commonResource
> service DataService {
> i8 Method_0(1: i8 agr_method_0)
> }
> {code}
>
> Thank you
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5806) Inconsistent Handling of Unset Union Fields in Structs Across Languages
[
https://issues.apache.org/jira/browse/THRIFT-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5806:
---
Component/s: Go - Library
> Inconsistent Handling of Unset Union Fields in Structs Across Languages
> ---
>
> Key: THRIFT-5806
> URL: https://issues.apache.org/jira/browse/THRIFT-5806
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Reporter: Team_RPCtester
>Priority: Major
>
> Hi,
> We discover an inconsistent behavior regarding unset values in unions within
> structs. Specifically, when a union field in a struct is not explicitly set,
> Go will report an error. In contrast, other languages pass a null value,
> allowing for smooth transmission. This inconsistency can be illustrated with
> the following example:
> Thrift Definition:
>
> {code:java}
> namespace go commonResource
> union Union_1 {
> 1: bool uitem_1;
> 2: i16 uitem_2=1;
> }
> struct StructClass_0 {
> 1: required bool f_1=1,
> 2: Union_1 f_2
> }
> service DataService {
> StructClass_0 Method_1(1: StructClass_0 agr_method_1)
> }
> {code}
> The Go client side, when it passes the agr_method_1_0 to method_1, it will
> prompt “panic: runtime error: invalid memory address or nil pointer
> dereference”.
> {code:java}
> agr_method_1_0 := commonResource.NewStructClass_0()
> fmt.Println("Method_1 sends ", agr_method_1_0, " end")
> method_1_re_agr_method_1_0, err :=
> dataserviceclient.Method_1(context.Background(),agr_method_1_0)
> {code}
>
> The Node.js client does not check whether the union field is set or not and
> successfully passes the arg_Method_1 to the server.
>
> {code:java}
> const arg_Method_1 = new StructClass_0();
> console.log("Method_1 sends ", arg_Method_1, " end");
> // arg_Method_1 {"f_1":true,"f_2":null}
> try {
> const res_Method_1 = await client.Method_1(arg_Method_1);
> console.log("Method_1 receives ", JSON.stringify(res_Method_1, replacer), "
> back");
> } catch (error) {
> console.log("Method_1 receives error ", error, " back");
> }
> {code}
>
> The Python client behaves similarly to the Node.js client, not checking
> whether the union field is set and successfully passing the arg_Method_1 to
> the server.
>
> {code:java}
> agr_method_1 = StructClass_0()
> print("Method_1 sends ",agr_method_1, " end")
> try:
> method_1_re_agr_method_1 = client.Method_1(agr_method_1)
> print("Method_1 receives ",method_1_re_agr_method_1," back")
> except Exception as ex:
> print(f"Method_1 receives error {ex} back")
> {code}
>
> Can you help check this issue? Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5808) Different transport protocols can lead to varying outcomes
[
https://issues.apache.org/jira/browse/THRIFT-5808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5808:
---
Component/s: Go - Library
> Different transport protocols can lead to varying outcomes
> --
>
> Key: THRIFT-5808
> URL: https://issues.apache.org/jira/browse/THRIFT-5808
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.19.0, 0.20.0
>Reporter: Team_RPCtester
>Priority: Major
>
> Hi,
> We discover an inconsistent behavior illustrated by the following example.
>
> {code:java}
> namespace go commonResource
> service DataService {
> i8 Method_0(1: i8 agr_method_0)
> }
> {code}
>
> When using Go as the client and Node.js as the server, transmitting the value
> 51 for the i8 type results in an error ‘HTTP Response code 403’ under the
> header_http-ip protocol. However, other protocols work correctly.
> Can you help check this issue?
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5803) Inconsistencies in Handling Default Values for Required Fields Across Thrift Implementations
[
https://issues.apache.org/jira/browse/THRIFT-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5803:
---
Component/s: Go - Compiler
> Inconsistencies in Handling Default Values for Required Fields Across Thrift
> Implementations
>
>
> Key: THRIFT-5803
> URL: https://issues.apache.org/jira/browse/THRIFT-5803
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.19.0, 0.20.0
>Reporter: Team_RPCtester
>Priority: Major
>
> Hi,
> We discover an inconsistent behavior with respect to default values for
> required string fields. Specifically, in Go, a required string field is
> automatically initialized to an empty string if not explicitly set, whereas
> other languages do not automatically initialize this field. This
> inconsistency can be illustrated with the following example:
> Thrift Definition:
> {code:java}
> namespace go commonResource
> struct StructClass_0 {
> 1: required string f_1,
> }
> service DataService {
> StructClass_0 Method_1(1: StructClass_0 agr_method_1)
> }
> {code}
> Go client side,
> {code:java}
> agr_method_1_0 := commonResource.NewStructClass_0()
> fmt.Println(agr_method_1_0)
> // method_1_re_agr_method_1_0: StructClass_0({F_1:})
> {code}
> python client side
> {code:java}
> agr_method_1 = StructClass_0()
> print(agr_method_1)
> # StructClass_0(f_1=None)
> {code}
> nodejs client side
> {code:java}
> arg_Method_1 = new ttypes.StructClass_0();
> console.log(arg_Method_1);
> // { f_1: null }
> {code}
> GO server side
> {code:java}
> func (d DataServiceHandler) Method_1(ctx context.Context, agr_method_1
> *commonResource.StructClass_0) (re_agr_method_1
> *commonResource.StructClass_0, _err error) {
> re_agr_method_1 = agr_method_1
> return re_agr_method_1, nil
> }
> {code}
> *Behavior Observed:*
> * On the Go client side, if agr_method_1_0 is sent with an uninitialized
> f_1, Go automatically sets f_1 to an empty string. The server receives this
> empty string and processes it accordingly.
> * On the Node.js client side, if arg_Method_1 is sent with an uninitialized
> f_1, Node.js client reports an error: "Required field f_1 is unset!" and does
> not allow the call to proceed.
> * On the Python client side, if agr_method_1 is sent with f_1 as null, the
> Go server reports: "*commonResource.StructClass_0 error reading struct:
> Required field F_1 is not, the Nodejs server will prompt “"Required field f_1
> is unset!"”, the Python server will return what it receives.
> Can you help check this issue.
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5778) Machine readable way to describe client-side service bindings
[ https://issues.apache.org/jira/browse/THRIFT-5778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5778: --- Component/s: Compiler (General) > Machine readable way to describe client-side service bindings > - > > Key: THRIFT-5778 > URL: https://issues.apache.org/jira/browse/THRIFT-5778 > Project: Thrift > Issue Type: New Feature > Components: Compiler (General) >Reporter: Jens Geyer >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Describing the endpoint specifics for a Thrift API today is a purely > text-adventure like exercise, which leaves the client end with the task to > set up and stack together a proper protocol/transport stack. That sometimes > even leads to headaches, e.g. if the server requires e.g. framed protocol > which might not be obvious. > The use of a generally accepted, machine-readable and extensible format to > describe client bindings could streamline that process. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5773) UUID wrapper for C++
[ https://issues.apache.org/jira/browse/THRIFT-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5773: --- Component/s: C++ - Compiler (was: C++ - Library) > UUID wrapper for C++ > > > Key: THRIFT-5773 > URL: https://issues.apache.org/jira/browse/THRIFT-5773 > Project: Thrift > Issue Type: New Feature > Components: C++ - Compiler >Reporter: Carel >Assignee: Carel >Priority: Major > Fix For: 0.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Continuation of THRIFT-5772 > Add a strong wrapper type for UUID support in C++ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5773) UUID wrapper for C++
[ https://issues.apache.org/jira/browse/THRIFT-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5773: --- Component/s: C++ - Library > UUID wrapper for C++ > > > Key: THRIFT-5773 > URL: https://issues.apache.org/jira/browse/THRIFT-5773 > Project: Thrift > Issue Type: New Feature > Components: C++ - Library >Reporter: Carel >Assignee: Carel >Priority: Major > Fix For: 0.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Continuation of THRIFT-5772 > Add a strong wrapper type for UUID support in C++ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5768) Building kotlin is always skipped when calling configure
[
https://issues.apache.org/jira/browse/THRIFT-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5768:
---
Component/s: Build Process
> Building kotlin is always skipped when calling configure
>
>
> Key: THRIFT-5768
> URL: https://issues.apache.org/jira/browse/THRIFT-5768
> Project: Thrift
> Issue Type: New Feature
> Components: Build Process
>Reporter: Thomas Bruggink
>Assignee: Thomas Bruggink
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When running `./bootstrap && ./configure` the build output is always:
> {code:java}
> thrift 0.21.0
> Building C (GLib) Library : yes
> Building C++ Library . : yes
> Building Common Lisp Library.. : yes
> Building D Library ... : yes
> Building Dart Library : yes
> Building .NET Standard Library : yes
> Building Erlang Library .. : yes
> Building Go Library .. : yes
> Building Haxe Library : yes
> Building Java Library : yes
> Building Kotlin Library .. : no
> Building Lua Library . : yes
> Building NodeJS Library .. : yes
> Building Perl Library : yes
> Building PHP Library . : yes
> Building Python Library .. : yes
> Building Py3 Library . : yes
> Building Ruby Library : yes
> Building Rust Library : yes
> Building Swift Library ... : yes
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5810) Wrong installation path for static MSVC libs.
[ https://issues.apache.org/jira/browse/THRIFT-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5810. Fix Version/s: 0.21.0 Assignee: Alexander Kurz Resolution: Fixed > Wrong installation path for static MSVC libs. > - > > Key: THRIFT-5810 > URL: https://issues.apache.org/jira/browse/THRIFT-5810 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.14.0, 0.15.0, 0.16.0, 0.17.0, 0.18.0, 0.19.0, 0.20.0 >Reporter: Alexander Kurz >Assignee: Alexander Kurz >Priority: Minor > Fix For: 0.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > With THRIFT-5109 the LIB_INSTALL_DIR for MSVC libs chanaged from lib/ to bin/ > regardless if shared or static libraries were built. > While for shared MSVC libraries, installation to bin/ folder is correct, the > commonly used installation path of static libraries (not only for MSVC) is > the lib/ folder. The changes made in THRIFT-5109 do not distinguish between > static and shared MSVC libs. > Static MSVC libraries should be installed into the lib/ folder, as it has > been done in 0.13.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-5272) printTo does not properly handle i8 datatypes
[
https://issues.apache.org/jira/browse/THRIFT-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5272.
Fix Version/s: 0.21.0
Assignee: Jens Geyer
Resolution: Fixed
Thanks [Sven Roederer|[SvenRoederer (Sven Roederer)
(github.com)|https://github.com/SvenRoederer]]!
> printTo does not properly handle i8 datatypes
> -
>
> Key: THRIFT-5272
> URL: https://issues.apache.org/jira/browse/THRIFT-5272
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.13.0
> Environment: MSVC 2019 *and* Linux gcc 10.1.0
>Reporter: Jeroen van Oosten
>Assignee: Jens Geyer
>Priority: Minor
> Fix For: 0.21.0
>
> Attachments: TToString.h.patch
>
> Original Estimate: 0.5h
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have defined a datastructure with an i8 type in it, like so:
> {code:java}
> struct Meta
> {
> 1: i8 channel,
> 2: i32 sequence
> }
> {code}
> For debugging / logging purposes we are printing the information with Meta::
> printTo, however the otuput is a bit odd. For example, we see this when the
> channel number is 0:
> Meta(channel= , sequence=5)
> I would expect to see "channel=0", just like all other integer types.
>
> Further investigation shows that at the empty space after "channel=" there is
> in fact a null byte. And if I change 'channel' to 65, I get a "channel=A".
> Clearly the ASCII value is being dumped, not the integer value.
>
> I have traced down the problem to TToString.h, line 34. The template function
> "to_string" there in combination with ostringstream does something weird when
> the input is a int8_t, which corresponds to a 'char' of course.
>
> The fix is to add a specialization of that template for int8_t:
> {code:java}
> inline std::string my_string(const int8_t& t) {
> std::ostringstream o;
> o << static_cast(t);
> return o.str();
> }
> {code}
> For your information: std::to_string *does* produce the expected result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (THRIFT-5813) Clarify TSocket state after isOpen
[
https://issues.apache.org/jira/browse/THRIFT-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer reassigned THRIFT-5813:
--
Assignee: Csaba Ringhofer
> Clarify TSocket state after isOpen
> --
>
> Key: THRIFT-5813
> URL: https://issues.apache.org/jira/browse/THRIFT-5813
> Project: Thrift
> Issue Type: Improvement
> Components: Python - Library
>Affects Versions: 0.20.0
>Reporter: Csaba Ringhofer
>Assignee: Csaba Ringhofer
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since 0.14.0 TSocket.py tries to peek into the socket during isOpen() and
> returns false if the connection seems to be disconnected (THRIFT-5248). The
> question is whether to close the socket in that case - currently isOpen()
> doesn't close the socket, while most clients probably expect it to be closed
> if isOpen() returned false.
> This makes it hard to create a "reopen if needed" logic that works both with
> THttpClient and TSocket:
> {code}
> if not transport.isOpen():
>transport.close()
>transport.open()
> {code}
> close() throws an exception in THttpClient, while calling it is needed for
> TSocket if isOpen() returned false due to the failing peek, otherwise open()
> will throw TTransportException.ALREADY_OPEN
> Found a ticket about the same issue in Go: THRIFT-5509
> The conclusion there was to close the socket during isOpen().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5813) Clarify TSocket state after isOpen
[
https://issues.apache.org/jira/browse/THRIFT-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876299#comment-17876299
]
Yuxuan Wang commented on THRIFT-5813:
-
I can't assign the ticket to you. Can you self-assign? If not then maybe
[~jensg] can do it during the release process of 0.21.0.
> Clarify TSocket state after isOpen
> --
>
> Key: THRIFT-5813
> URL: https://issues.apache.org/jira/browse/THRIFT-5813
> Project: Thrift
> Issue Type: Improvement
> Components: Python - Library
>Affects Versions: 0.20.0
>Reporter: Csaba Ringhofer
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since 0.14.0 TSocket.py tries to peek into the socket during isOpen() and
> returns false if the connection seems to be disconnected (THRIFT-5248). The
> question is whether to close the socket in that case - currently isOpen()
> doesn't close the socket, while most clients probably expect it to be closed
> if isOpen() returned false.
> This makes it hard to create a "reopen if needed" logic that works both with
> THttpClient and TSocket:
> {code}
> if not transport.isOpen():
>transport.close()
>transport.open()
> {code}
> close() throws an exception in THttpClient, while calling it is needed for
> TSocket if isOpen() returned false due to the failing peek, otherwise open()
> will throw TTransportException.ALREADY_OPEN
> Found a ticket about the same issue in Go: THRIFT-5509
> The conclusion there was to close the socket during isOpen().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5813) Clarify TSocket state after isOpen
[
https://issues.apache.org/jira/browse/THRIFT-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuxuan Wang updated THRIFT-5813:
Fix Version/s: 0.21.0
> Clarify TSocket state after isOpen
> --
>
> Key: THRIFT-5813
> URL: https://issues.apache.org/jira/browse/THRIFT-5813
> Project: Thrift
> Issue Type: Improvement
> Components: Python - Library
>Affects Versions: 0.20.0
>Reporter: Csaba Ringhofer
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since 0.14.0 TSocket.py tries to peek into the socket during isOpen() and
> returns false if the connection seems to be disconnected (THRIFT-5248). The
> question is whether to close the socket in that case - currently isOpen()
> doesn't close the socket, while most clients probably expect it to be closed
> if isOpen() returned false.
> This makes it hard to create a "reopen if needed" logic that works both with
> THttpClient and TSocket:
> {code}
> if not transport.isOpen():
>transport.close()
>transport.open()
> {code}
> close() throws an exception in THttpClient, while calling it is needed for
> TSocket if isOpen() returned false due to the failing peek, otherwise open()
> will throw TTransportException.ALREADY_OPEN
> Found a ticket about the same issue in Go: THRIFT-5509
> The conclusion there was to close the socket during isOpen().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5813) Clarify TSocket state after isOpen
[
https://issues.apache.org/jira/browse/THRIFT-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuxuan Wang updated THRIFT-5813:
Affects Version/s: 0.20.0
> Clarify TSocket state after isOpen
> --
>
> Key: THRIFT-5813
> URL: https://issues.apache.org/jira/browse/THRIFT-5813
> Project: Thrift
> Issue Type: Improvement
> Components: Python - Library
>Affects Versions: 0.20.0
>Reporter: Csaba Ringhofer
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since 0.14.0 TSocket.py tries to peek into the socket during isOpen() and
> returns false if the connection seems to be disconnected (THRIFT-5248). The
> question is whether to close the socket in that case - currently isOpen()
> doesn't close the socket, while most clients probably expect it to be closed
> if isOpen() returned false.
> This makes it hard to create a "reopen if needed" logic that works both with
> THttpClient and TSocket:
> {code}
> if not transport.isOpen():
>transport.close()
>transport.open()
> {code}
> close() throws an exception in THttpClient, while calling it is needed for
> TSocket if isOpen() returned false due to the failing peek, otherwise open()
> will throw TTransportException.ALREADY_OPEN
> Found a ticket about the same issue in Go: THRIFT-5509
> The conclusion there was to close the socket during isOpen().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5813) Clarify TSocket state after isOpen
[
https://issues.apache.org/jira/browse/THRIFT-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876247#comment-17876247
]
Csaba Ringhofer commented on THRIFT-5813:
-
[~fishywang] yes, please assign the ticket to me
Created a PR: https://github.com/apache/thrift/pull/3029
> Clarify TSocket state after isOpen
> --
>
> Key: THRIFT-5813
> URL: https://issues.apache.org/jira/browse/THRIFT-5813
> Project: Thrift
> Issue Type: Improvement
> Components: Python - Library
>Reporter: Csaba Ringhofer
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since 0.14.0 TSocket.py tries to peek into the socket during isOpen() and
> returns false if the connection seems to be disconnected (THRIFT-5248). The
> question is whether to close the socket in that case - currently isOpen()
> doesn't close the socket, while most clients probably expect it to be closed
> if isOpen() returned false.
> This makes it hard to create a "reopen if needed" logic that works both with
> THttpClient and TSocket:
> {code}
> if not transport.isOpen():
>transport.close()
>transport.open()
> {code}
> close() throws an exception in THttpClient, while calling it is needed for
> TSocket if isOpen() returned false due to the failing peek, otherwise open()
> will throw TTransportException.ALREADY_OPEN
> Found a ticket about the same issue in Go: THRIFT-5509
> The conclusion there was to close the socket during isOpen().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5814) go: Flaky test TestNoHangDuringStopFromClientNoDataSendDuringAcceptLoop
[ https://issues.apache.org/jira/browse/THRIFT-5814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876057#comment-17876057 ] Yuxuan Wang commented on THRIFT-5814: - So far I tried a few ways, none of them actually fixes the flakiness: * Replace the tcp connection with a unix domain socket * After the client established the connection and sleep for a small period of time, do a connectivity check to make sure the connection is still good, and if not, retry establishing a client connection again * Disable tcp keep-alive * Change tcp keep-alive to a much shorter interval > go: Flaky test TestNoHangDuringStopFromClientNoDataSendDuringAcceptLoop > --- > > Key: THRIFT-5814 > URL: https://issues.apache.org/jira/browse/THRIFT-5814 > Project: Thrift > Issue Type: Task > Components: Go - Library >Affects Versions: 0.20.0 >Reporter: Yuxuan Wang >Priority: Minor > > Currently the > [TestNoHangDuringStopFromClientNoDataSendDuringAcceptLoop|https://github.com/apache/thrift/blob/cb9ceada554f47aa5ebbedfe3984de0983cf0226/lib/go/thrift/simple_server_test.go#L164] > test in go library can be flaky (fails at roughly 1-in-100 chance) > What this test does is roughly: > # Create a local server listening on a random local port (via localhost:0) > # Create a tcp client that connects to the server (via net.Dial) but does > nothing after established the connection (so to server's PoV this is an idle > client) > # Tries to shutdown the server > # Verifies that the shutting down of the server took at least the configured > timeout, before server forcefully close idle client connections > Step 4 can occasionally (rarely) fail because the server shutdown much faster > than expected. I did some digging, the reason seems to be that the > client-server tcp connection is broken after established (killed by the os or > something?) > So we need to find a way to keep the connection until server kills it to fix > the flakiness of this test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5814) go: Flaky test TestNoHangDuringStopFromClientNoDataSendDuringAcceptLoop
Yuxuan Wang created THRIFT-5814: --- Summary: go: Flaky test TestNoHangDuringStopFromClientNoDataSendDuringAcceptLoop Key: THRIFT-5814 URL: https://issues.apache.org/jira/browse/THRIFT-5814 Project: Thrift Issue Type: Task Components: Go - Library Affects Versions: 0.20.0 Reporter: Yuxuan Wang Currently the [TestNoHangDuringStopFromClientNoDataSendDuringAcceptLoop|https://github.com/apache/thrift/blob/cb9ceada554f47aa5ebbedfe3984de0983cf0226/lib/go/thrift/simple_server_test.go#L164] test in go library can be flaky (fails at roughly 1-in-100 chance) What this test does is roughly: # Create a local server listening on a random local port (via localhost:0) # Create a tcp client that connects to the server (via net.Dial) but does nothing after established the connection (so to server's PoV this is an idle client) # Tries to shutdown the server # Verifies that the shutting down of the server took at least the configured timeout, before server forcefully close idle client connections Step 4 can occasionally (rarely) fail because the server shutdown much faster than expected. I did some digging, the reason seems to be that the client-server tcp connection is broken after established (killed by the os or something?) So we need to find a way to keep the connection until server kills it to fix the flakiness of this test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (THRIFT-5813) Clarify TSocket state after isOpen
[
https://issues.apache.org/jira/browse/THRIFT-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875890#comment-17875890
]
Yuxuan Wang commented on THRIFT-5813:
-
Agree with the conclusion. Do you want to take the ticket and send a PR?
> Clarify TSocket state after isOpen
> --
>
> Key: THRIFT-5813
> URL: https://issues.apache.org/jira/browse/THRIFT-5813
> Project: Thrift
> Issue Type: Improvement
> Components: Python - Library
>Reporter: Csaba Ringhofer
>Priority: Major
>
> Since 0.14.0 TSocket.py tries to peek into the socket during isOpen() and
> returns false if the connection seems to be disconnected (THRIFT-5248). The
> question is whether to close the socket in that case - currently isOpen()
> doesn't close the socket, while most clients probably expect it to be closed
> if isOpen() returned false.
> This makes it hard to create a "reopen if needed" logic that works both with
> THttpClient and TSocket:
> {code}
> if not transport.isOpen():
>transport.close()
>transport.open()
> {code}
> close() throws an exception in THttpClient, while calling it is needed for
> TSocket if isOpen() returned false due to the failing peek, otherwise open()
> will throw TTransportException.ALREADY_OPEN
> Found a ticket about the same issue in Go: THRIFT-5509
> The conclusion there was to close the socket during isOpen().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (THRIFT-5813) Clarify TSocket state after isOpen
Csaba Ringhofer created THRIFT-5813:
---
Summary: Clarify TSocket state after isOpen
Key: THRIFT-5813
URL: https://issues.apache.org/jira/browse/THRIFT-5813
Project: Thrift
Issue Type: Improvement
Components: Python - Library
Reporter: Csaba Ringhofer
Since 0.14.0 TSocket.py tries to peek into the socket during isOpen() and
returns false if the connection seems to be disconnected (THRIFT-5248). The
question is whether to close the socket in that case - currently isOpen()
doesn't close the socket, while most clients probably expect it to be closed if
isOpen() returned false.
This makes it hard to create a "reopen if needed" logic that works both with
THttpClient and TSocket:
{code}
if not transport.isOpen():
transport.close()
transport.open()
{code}
close() throws an exception in THttpClient, while calling it is needed for
TSocket if isOpen() returned false due to the failing peek, otherwise open()
will throw TTransportException.ALREADY_OPEN
Found a ticket about the same issue in Go: THRIFT-5509
The conclusion there was to close the socket during isOpen().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875820#comment-17875820
]
Jens Geyer commented on THRIFT-5812:
There is no ETA, the current proposal is sort of dropped. But there's hope :)
The second proposal I have in mind already will be different from the first -
if I only get a matching time slot to prepare it.
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0, 0.20.0
>Reporter: Victor
>Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
> on this issue that also has the problem with clients in other languages so
> it probably comes from the Rust library. -Also I am reporting it on version
> 0.17.0 because it is the latest available version of thrift on crates.io.-
> The issue also occurs when using the latest 0.21.0 Rust library (commit
> e98d6b1).
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5812.
Fix Version/s: 0.21.0
Assignee: Jens Geyer
Resolution: Not A Problem
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0, 0.20.0
>Reporter: Victor
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0
>
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
> on this issue that also has the problem with clients in other languages so
> it probably comes from the Rust library. -Also I am reporting it on version
> 0.17.0 because it is the latest available version of thrift on crates.io.-
> The issue also occurs when using the latest 0.21.0 Rust library (commit
> e98d6b1).
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5139) Type hinting for Python library
[ https://issues.apache.org/jira/browse/THRIFT-5139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5139. Fix Version/s: 0.21.0 Assignee: Jens Geyer Resolution: Duplicate > Type hinting for Python library > --- > > Key: THRIFT-5139 > URL: https://issues.apache.org/jira/browse/THRIFT-5139 > Project: Thrift > Issue Type: Improvement > Components: Python - Library >Reporter: Neil Williams >Assignee: Jens Geyer >Priority: Major > Fix For: 0.21.0 > > Time Spent: 11h 20m > Remaining Estimate: 0h > > Similarly to THRIFT-4181, it'd be useful to have type hints for the Python > Thrift library itself. > There are a few possible approaches: > 1) Add type stubs to the [typeshed|[https://github.com/python/typeshed]]. > This would require no changes to the library itself but also would mean the > types are always potentially out of sync with the library and come from > different places. > 2) Add type stubs in separate .pyi files within the main library codebase. > This allows the library to maintain compatibility with Python versions lower > than 3.5 while also providing proper annotations to modern implementations. > Like with typeshed it runs the risk of types and implementations being out of > sync, but the risk should be lower because the code lives side-by-side. > 3) Add type annotations directly to the Python code. The code and types would > be combined and so would always stay in sync. This would essentially break > compatibility with Python 3.4 and lower (incl. Python 2.7). While this sounds > drastic, [Python 3.4 went end-of-life in March 2019 and Python 2.7 in January > 2020|https://devguide.python.org/devcycle/#end-of-life-branches]. This is the > most drastic option, but explicitly dropping support for those versions would > also open up a bunch of cleanups in the code so might be desirable for other > reasons. > Do you all have any suggestion for which approach to take? I'd be happy to do > the type hinting itself if I know the direction to take. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (THRIFT-4181) PEP 484 Type Hinting on generated code
[ https://issues.apache.org/jira/browse/THRIFT-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875663#comment-17875663 ] Jens Geyer edited comment on THRIFT-4181 at 8/21/24 8:57 PM: - Thanks [arkuhn|https://github.com/arkuhn] and [cspwizard|https://github.com/cspwizard]! was (Author: jensg): Thanks [arkuhn (Adam Kuhn) (github.com)|https://github.com/arkuhn] and [cspwizard (Konstantin Pozdniakov) (github.com)|https://github.com/cspwizard]! > PEP 484 Type Hinting on generated code > -- > > Key: THRIFT-4181 > URL: https://issues.apache.org/jira/browse/THRIFT-4181 > Project: Thrift > Issue Type: New Feature > Components: Python - Compiler >Reporter: NEGORO Tetsuya >Assignee: Jens Geyer >Priority: Minor > Fix For: 0.21.0 > > > Dear maintainers, > I think it is useful if Thrift Python compiler has option to enable generated > code contain type hints proposed in PEP 484. > https://www.python.org/dev/peps/pep-0484 > Though it does no effect on semantics currently, there are several linting > tools use it. It also helps people who work with generated code. > This syntax is supported by Python 3.5> only, but for versions below we can > still use special type comments for annotations. > https://www.python.org/dev/peps/pep-0484/#suggested-syntax-for-python-2-7-and-straddling-code > Thanks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-4181) PEP 484 Type Hinting on generated code
[ https://issues.apache.org/jira/browse/THRIFT-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-4181. Fix Version/s: 0.21.0 Assignee: Jens Geyer Resolution: Fixed Thanks [arkuhn (Adam Kuhn) (github.com)|https://github.com/arkuhn] and [cspwizard (Konstantin Pozdniakov) (github.com)|https://github.com/cspwizard]! > PEP 484 Type Hinting on generated code > -- > > Key: THRIFT-4181 > URL: https://issues.apache.org/jira/browse/THRIFT-4181 > Project: Thrift > Issue Type: New Feature > Components: Python - Compiler >Reporter: NEGORO Tetsuya >Assignee: Jens Geyer >Priority: Minor > Fix For: 0.21.0 > > > Dear maintainers, > I think it is useful if Thrift Python compiler has option to enable generated > code contain type hints proposed in PEP 484. > https://www.python.org/dev/peps/pep-0484 > Though it does no effect on semantics currently, there are several linting > tools use it. It also helps people who work with generated code. > This syntax is supported by Python 3.5> only, but for versions below we can > still use special type comments for annotations. > https://www.python.org/dev/peps/pep-0484/#suggested-syntax-for-python-2-7-and-straddling-code > Thanks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875376#comment-17875376
]
Victor edited comment on THRIFT-5812 at 8/21/24 7:14 AM:
-
This was the issue indeed. See
[0dc184d|https://github.com/victorbnl/thrift-rs-capacity-overflow/commit/0dc184d58eec5ec2e4820fc8c7fcf6615d26cc16]
for the fix.
Your proposal looks good! Depending on its ETA, maybe a temporary fix should be
worked on? Could the server display an error when the wrong transport is used,
like it does when the wrong Thrift version is? If that looks feasible, I might
give it a try later.
was (Author: JIRAUSER306277):
This was the issue indeed. See
[0dc184d|[https://github.com/victorbnl/thrift-rs-capacity-overflow/commit/0dc184d58eec5ec2e4820fc8c7fcf6615d26cc16]]
for the fix.
Your proposal looks good! Depending on its ETA, maybe a temporary fix should be
worked on? Could the server display an error when the wrong transport is used,
like it does when the wrong Thrift version is? If that looks feasible, I might
give it a try later.
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0, 0.20.0
>Reporter: Victor
>Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
> on this issue that also has the problem with clients in other languages so
> it probably comes from the Rust library. -Also I am reporting it on version
> 0.17.0 because it is the latest available version of thrift on crates.io.-
> The issue also occurs when using the latest 0.21.0 Rust library (commit
> e98d6b1).
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875376#comment-17875376
]
Victor commented on THRIFT-5812:
This was the issue indeed. See
[0dc184d|[https://github.com/victorbnl/thrift-rs-capacity-overflow/commit/0dc184d58eec5ec2e4820fc8c7fcf6615d26cc16]]
for the fix.
Your proposal looks good! Depending on its ETA, maybe a temporary fix should be
worked on? Could the server display an error when the wrong transport is used,
like it does when the wrong Thrift version is? If that looks feasible, I might
give it a try later.
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0, 0.20.0
>Reporter: Victor
>Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
> on this issue that also has the problem with clients in other languages so
> it probably comes from the Rust library. -Also I am reporting it on version
> 0.17.0 because it is the latest available version of thrift on crates.io.-
> The issue also occurs when using the latest 0.21.0 Rust library (commit
> e98d6b1).
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875241#comment-17875241
]
Jens Geyer commented on THRIFT-5812:
Ok I see [the server uses
TFramedTransport|https://github.com/victorbnl/thrift-rs-capacity-overflow/blob/eb6d60625c1e21e6428853fbe7f4c0cb2ebd7611/server/src/main.rs#L13C23-L13C50].
Does your sync client use TFramedTransport as well?
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0, 0.20.0
>Reporter: Victor
>Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
> on this issue that also has the problem with clients in other languages so
> it probably comes from the Rust library. -Also I am reporting it on version
> 0.17.0 because it is the latest available version of thrift on crates.io.-
> The issue also occurs when using the latest 0.21.0 Rust library (commit
> e98d6b1).
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875231#comment-17875231
]
Jens Geyer commented on THRIFT-5812:
I haven't checked the testcase (thanks for preparing it), but something
immediately popped up ... there are certain server-side elements that
implicitly require client-side usage of {*}{{TFramedTransport}}{*}. Could that
be the case here? Just educated guesswork here, it might as well be sth else,
but that's a common trap.
PS: That's one reason for [THRIFT-5778]
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0, 0.20.0
>Reporter: Victor
>Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
> on this issue that also has the problem with clients in other languages so
> it probably comes from the Rust library. -Also I am reporting it on version
> 0.17.0 because it is the latest available version of thrift on crates.io.-
> The issue also occurs when using the latest 0.21.0 Rust library (commit
> e98d6b1).
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victor updated THRIFT-5812:
---
Affects Version/s: 0.20.0
Description:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There, it
reads an i32 to check the message length. At this step, for some reason, when
the message has been sent with a sync client, it reads {{82 21 01 04}} (the
Thrift header, that contains the protocol version, message type and sequence
id), when it has been sent with an async client, it reads {{00 00 00 09}}
(which is the right length).
When analysing the packets, it seems that the only difference (apart from the
TCP headers) in both protocols is the seqid, which turns out to be 0 with the
async client, 1 with the sync client.
-I am not sure whether this is an issue on the Rust or Java side (although I
think Rust).- I found [a
topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
on this issue that also has the problem with clients in other languages so it
probably comes from the Rust library. -Also I am reporting it on version 0.17.0
because it is the latest available version of thrift on crates.io.- The issue
also occurs when using the latest 0.21.0 Rust library (commit e98d6b1).
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
was:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There, it
reads an i32 to check the message length. At this step, for some reason, when
the message has been sent with a sync client, it reads {{82 21 01 04}} (the
Thrift header, that contains the protocol version, message type and sequence
id), when it has been sent with an async client, it reads {{00 00 00 09}}
(which is the right length).
When analysing the packets, it seems that the only difference (apart from the
TCP headers) in both protocols is the seqid, which turns out to be 0 with the
async client, 1 with the sync client.
-I am not sure whether this is an issue on the Rust or Java side (although I
think Rust).- I found [a
topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
on this issue that also has the problem with clients in other languages so it
probably comes from the Rust library. Also I am reporting it on version 0.17.0
because it is the latest available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0, 0.20.0
>Reporter: Victor
>Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-
[jira] [Updated] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victor updated THRIFT-5812:
---
Description:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There, it
reads an i32 to check the message length. At this step, for some reason, when
the message has been sent with a sync client, it reads {{82 21 01 04}} (the
Thrift header, that contains the protocol version, message type and sequence
id), when it has been sent with an async client, it reads {{00 00 00 09}}
(which is the right length).
When analysing the packets, it seems that the only difference (apart from the
TCP headers) in both protocols is the seqid, which turns out to be 0 with the
async client, 1 with the sync client.
-I am not sure whether this is an issue on the Rust or Java side (although I
think Rust).- I found [a
topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
on this issue that also has the problem with clients in other languages so it
probably comes from the Rust library. Also I am reporting it on version 0.17.0
because it is the latest available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
was:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
an i32 to check the message length. At this step, for some reason, when the
message has been sent with a sync client, it reads {{82 21 01 04}} (the Thrift
header, that contains the protocol version, message type and sequence id), when
it has been sent with an async client, it reads {{00 00 00 09}} (which is the
right length).
When analysing the packets, it seems that the only difference (apart from the
TCP headers) in both protocols is the seqid, which turns out to be 0 with the
async client, 1 with the sync client.
I am not sure whether this is an issue on the Rust or Java side (although I
think Rust). Also I am reporting it on version 0.17.0 because it is the latest
available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0
>Reporter: Victor
>Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{{}read_message_begin{}}}, which calls the transport’s {{{}read{}}}. There,
> it reads an i32 to check the message length. At this step, for some reason,
> when the message has been sent with a sync client, it reads {{82 21 01 04}}
> (the Thrift header, that contains the protocol version, message type and
> sequence id), when it has been sent with an async client, it reads {{00 00 00
> 09}} (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> -I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust).- I found [a
> topic|https://users.rust-lang.org/t/first-rust-thrift-server-crashing-on-returning-i32/83271]
> on this issue that also has the problem with clients in other languages so
> it probably comes from the Rust library. Also I am reporting it on version
> 0.17.0 because it is the latest available version of thrift on crates.io.
> See here for more details and a reproducible example:
> [https://gith
[jira] [Updated] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victor updated THRIFT-5812:
---
Description:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
an i32 to check the message length. At this step, for some reason, when the
message has been sent with a sync client, it reads {{82 21 01 04}} (the Thrift
header, that contains the protocol version, message type and sequence id), when
it has been sent with an async client, it reads {{00 00 00 09}} (which is the
right length).
When analysing the packets, it seems that the only difference (apart from the
TCP headers) in both protocols is the seqid, which turns out to be 0 with the
async client, 1 with the sync client.
I am not sure whether this is an issue on the Rust or Java side (although I
think Rust). Also I am reporting it on version 0.17.0 because it is the latest
available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
was:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
an i32 to check the message length. At this step, for some reason, when the
message has been sent with a sync client, it reads {{82 21 01 04}} (the Thrift
header, that contains the protocol version, message type and sequence id), when
it has been sent with an async client, it reads {{00 00 00 09}} (which is the
right length).
I am not sure whether this is an issue on the Rust or Java side (although I
think Rust). Also I am reporting it on version 0.17.0 because it is the latest
available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0
>Reporter: Victor
>Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
> an i32 to check the message length. At this step, for some reason, when the
> message has been sent with a sync client, it reads {{82 21 01 04}} (the
> Thrift header, that contains the protocol version, message type and sequence
> id), when it has been sent with an async client, it reads {{00 00 00 09}}
> (which is the right length).
> When analysing the packets, it seems that the only difference (apart from the
> TCP headers) in both protocols is the seqid, which turns out to be 0 with the
> async client, 1 with the sync client.
> I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust). Also I am reporting it on version 0.17.0 because it is the
> latest available version of thrift on crates.io.
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victor updated THRIFT-5812:
---
Description:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
an i32 to check the message length. At this step, for some reason, when the
message has been sent with a sync client, it reads 82 21 01 04 (the Thrift
header, that contains the protocol version, message type and sequence id), when
it has been sent with an async client, it reads 00 00 00 09 (which is the right
length).
I am not sure whether this is an issue on the Rust or Java side (although I
think Rust). Also I am reporting it on version 0.17.0 because it is the latest
available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
was:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
I am not sure whether this is an issue on the Rust or Java side. Also I am
reporting it on version 0.17.0 because it is the latest available version of
thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0
>Reporter: Victor
>Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
> an i32 to check the message length. At this step, for some reason, when the
> message has been sent with a sync client, it reads 82 21 01 04 (the Thrift
> header, that contains the protocol version, message type and sequence id),
> when it has been sent with an async client, it reads 00 00 00 09 (which is
> the right length).
> I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust). Also I am reporting it on version 0.17.0 because it is the
> latest available version of thrift on crates.io.
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5812) Capacity overflow in Rust server
[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victor updated THRIFT-5812:
---
Description:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
an i32 to check the message length. At this step, for some reason, when the
message has been sent with a sync client, it reads {{82 21 01 04}} (the Thrift
header, that contains the protocol version, message type and sequence id), when
it has been sent with an async client, it reads {{00 00 00 09}} (which is the
right length).
I am not sure whether this is an issue on the Rust or Java side (although I
think Rust). Also I am reporting it on version 0.17.0 because it is the latest
available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
was:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
an i32 to check the message length. At this step, for some reason, when the
message has been sent with a sync client, it reads 82 21 01 04 (the Thrift
header, that contains the protocol version, message type and sequence id), when
it has been sent with an async client, it reads 00 00 00 09 (which is the right
length).
I am not sure whether this is an issue on the Rust or Java side (although I
think Rust). Also I am reporting it on version 0.17.0 because it is the latest
available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
> Capacity overflow in Rust server
>
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.17.0
>Reporter: Victor
>Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
> an i32 to check the message length. At this step, for some reason, when the
> message has been sent with a sync client, it reads {{82 21 01 04}} (the
> Thrift header, that contains the protocol version, message type and sequence
> id), when it has been sent with an async client, it reads {{00 00 00 09}}
> (which is the right length).
> I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust). Also I am reporting it on version 0.17.0 because it is the
> latest available version of thrift on crates.io.
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5812) Capacity overflow in Rust server
[ https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Victor updated THRIFT-5812: --- Description: I am trying to interact with a Rust Thrift server using a Java client. When using the sync client, the server misreads the length of the message and panics with a capacity overflow error. However, the async client works fine for some reason. It happens on both the compact and binary protocols. I am not sure whether this is an issue on the Rust or Java side. Also I am reporting it on version 0.17.0 because it is the latest available version of thrift on crates.io. See here for more details and a reproducible example: [https://github.com/victorbnl/thrift-rs-capacity-overflow]. was: I am trying to interact with a Rust Thrift server using a Java client. When using the sync client, the server misreads the length of the message and panics with a capacity overflow error. However, the async client works fine for some reason. When the issue occurs, the server considers that the first four bytes are the length of the message (whereas those are actually the version, message type and seqid). It happens on both the compact and binary protocols. I am not sure whether this is an issue on the Rust or Java side. Also I am reporting it on version 0.17.0 because it is the latest available version of thrift on crates.io. See here for more details and a reproducible example: [https://github.com/victorbnl/thrift-rs-capacity-overflow]. > Capacity overflow in Rust server > > > Key: THRIFT-5812 > URL: https://issues.apache.org/jira/browse/THRIFT-5812 > Project: Thrift > Issue Type: Bug > Components: Rust - Library >Affects Versions: 0.17.0 >Reporter: Victor >Priority: Major > > I am trying to interact with a Rust Thrift server using a Java client. When > using the sync client, the server misreads the length of the message and > panics with a capacity overflow error. However, the async client works fine > for some reason. It happens on both the compact and binary protocols. > I am not sure whether this is an issue on the Rust or Java side. Also I am > reporting it on version 0.17.0 because it is the latest available version of > thrift on crates.io. > See here for more details and a reproducible example: > [https://github.com/victorbnl/thrift-rs-capacity-overflow]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
