[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] [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] [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-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] [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] [Comment Edited] (THRIFT-4847) CancelledKeyException causes TThreadedSelectorServer to fail.
[
https://issues.apache.org/jira/browse/THRIFT-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871057#comment-17871057
]
Jens Geyer edited comment on THRIFT-4847 at 8/6/24 1:58 PM:
{quote}is there an ETA on the next release?{quote}
Not yet. When ready. We usually release twice a year, but there is no fixed
date.
was (Author: jensg):
What about tomorrow?
Sent from mobile device.
> CancelledKeyException causes TThreadedSelectorServer to fail.
> -
>
> Key: THRIFT-4847
> URL: https://issues.apache.org/jira/browse/THRIFT-4847
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.12.0
>Reporter: Keith Turner
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> When attempting to use TThreadedSelectorServer I see the following exception
> and then the server becomes inoperable.
> {noformat}
> 2019-04-03 11:50:37,638 [server.TThreadedSelectorServer] ERROR: run() on
> SelectorThread exiting due to uncaught error
> java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.changeSelectInterests(AbstractNonblockingServer.java:440)
> at
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.processInterestChanges(AbstractNonblockingServer.java:191)
> at
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:548)
> {noformat}
> I tracked this down and I think it is caused by the following events :
> # A frame buffer is created and given a selection key
> [TThreadedSelectorServer.java line
> 691|https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/TThreadedSelectorServer.java#L691]
> # The rebuild selector code introduced in THRIFT-4251 is triggered and all
> selectors key are canceled when the selector is closed
> [TThreadedSelectorServer.java line
> 668|https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/TThreadedSelectorServer.java#L668]
> # A frame buffer attempts to modify its invalid selection key causing an
> exception [AbstractNonblockingServer.java line
> 440|https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/AbstractNonblockingServer.java#L440]
> I added some logging and found that {{selector.select()}} would return 0
> hundreds of times, but not infinitely. I changed
> SELECTOR_AUTO_REBUILD_THRESHOLD from 512 to 1,000,000 and the bug did not
> happen. I don't think this change is the fix, its just what I did as part of
> debugging this. Not sure what the best fix for this is.
> The situation that triggers this seems to be lots of connections in a very
> short time period.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-4847) CancelledKeyException causes TThreadedSelectorServer to fail.
[
https://issues.apache.org/jira/browse/THRIFT-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871057#comment-17871057
]
Jens Geyer commented on THRIFT-4847:
What about tomorrow?
Sent from mobile device.
> CancelledKeyException causes TThreadedSelectorServer to fail.
> -
>
> Key: THRIFT-4847
> URL: https://issues.apache.org/jira/browse/THRIFT-4847
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.12.0
>Reporter: Keith Turner
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> When attempting to use TThreadedSelectorServer I see the following exception
> and then the server becomes inoperable.
> {noformat}
> 2019-04-03 11:50:37,638 [server.TThreadedSelectorServer] ERROR: run() on
> SelectorThread exiting due to uncaught error
> java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.changeSelectInterests(AbstractNonblockingServer.java:440)
> at
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.processInterestChanges(AbstractNonblockingServer.java:191)
> at
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:548)
> {noformat}
> I tracked this down and I think it is caused by the following events :
> # A frame buffer is created and given a selection key
> [TThreadedSelectorServer.java line
> 691|https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/TThreadedSelectorServer.java#L691]
> # The rebuild selector code introduced in THRIFT-4251 is triggered and all
> selectors key are canceled when the selector is closed
> [TThreadedSelectorServer.java line
> 668|https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/TThreadedSelectorServer.java#L668]
> # A frame buffer attempts to modify its invalid selection key causing an
> exception [AbstractNonblockingServer.java line
> 440|https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/AbstractNonblockingServer.java#L440]
> I added some logging and found that {{selector.select()}} would return 0
> hundreds of times, but not infinitely. I changed
> SELECTOR_AUTO_REBUILD_THRESHOLD from 512 to 1,000,000 and the bug did not
> happen. I don't think this change is the fix, its just what I did as part of
> debugging this. Not sure what the best fix for this is.
> The situation that triggers this seems to be lots of connections in a very
> short time period.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-4847) CancelledKeyException causes TThreadedSelectorServer to fail.
[
https://issues.apache.org/jira/browse/THRIFT-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-4847.
Fix Version/s: 0.21.0
Assignee: Jens Geyer
Resolution: Fixed
> CancelledKeyException causes TThreadedSelectorServer to fail.
> -
>
> Key: THRIFT-4847
> URL: https://issues.apache.org/jira/browse/THRIFT-4847
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.12.0
>Reporter: Keith Turner
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> When attempting to use TThreadedSelectorServer I see the following exception
> and then the server becomes inoperable.
> {noformat}
> 2019-04-03 11:50:37,638 [server.TThreadedSelectorServer] ERROR: run() on
> SelectorThread exiting due to uncaught error
> java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.changeSelectInterests(AbstractNonblockingServer.java:440)
> at
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.processInterestChanges(AbstractNonblockingServer.java:191)
> at
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:548)
> {noformat}
> I tracked this down and I think it is caused by the following events :
> # A frame buffer is created and given a selection key
> [TThreadedSelectorServer.java line
> 691|https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/TThreadedSelectorServer.java#L691]
> # The rebuild selector code introduced in THRIFT-4251 is triggered and all
> selectors key are canceled when the selector is closed
> [TThreadedSelectorServer.java line
> 668|https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/TThreadedSelectorServer.java#L668]
> # A frame buffer attempts to modify its invalid selection key causing an
> exception [AbstractNonblockingServer.java line
> 440|https://github.com/apache/thrift/blob/v0.12.0/lib/java/src/org/apache/thrift/server/AbstractNonblockingServer.java#L440]
> I added some logging and found that {{selector.select()}} would return 0
> hundreds of times, but not infinitely. I changed
> SELECTOR_AUTO_REBUILD_THRESHOLD from 512 to 1,000,000 and the bug did not
> happen. I don't think this change is the fix, its just what I did as part of
> debugging this. Not sure what the best fix for this is.
> The situation that triggers this seems to be lots of connections in a very
> short time period.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (THRIFT-5230) Fix connection leak and CancelledKeyException when handling Epoll bug
[
https://issues.apache.org/jira/browse/THRIFT-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer reassigned THRIFT-5230:
--
Assignee: Jens Geyer
> Fix connection leak and CancelledKeyException when handling Epoll bug
> -
>
> Key: THRIFT-5230
> URL: https://issues.apache.org/jira/browse/THRIFT-5230
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.13.0
> Environment: java version "1.8.0_161"
>Reporter: zengji
>Assignee: Jens Geyer
>Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> 1. When Epoll bug occurs, the TThreadedSelectorServer.rebuildSelector
> rebuilds only the channel has events, the idle connection was ignored and
> caused connection leak
>
> {code:java}
> for (SelectionKey key : oldSelector.selectedKeys()) {
> if (!key.isValid() && key.readyOps() == 0)
> continue;
> SelectableChannel channel = key.channel();
> Object attachment = key.attachment();
> try {
> if (attachment == null) {
> channel.register(newSelector, key.readyOps());
> } else {
> channel.register(newSelector, key.readyOps(), attachment);
> }
> } catch (ClosedChannelException e) {
> LOGGER.error("Register new selector key error.", e);
> }
> }
> selector = newSelector;
> try {
> oldSelector.close();
> } catch (IOException e) {
> LOGGER.error("Close old selector error.", e);
> }
> {code}
> 2. When re-register the channel to new selector, the interested ops should
> same as before, not only the readyOps
>
> 3. In the same code block, the channel will be registered to a new selector
> and the previous selector will be closed, but the FrameBuffer is still
> holding the previous selector causing the FrameBuffer in a wrong state. When
> the FrameBuffer is trying to processing the channel, it may occur a
> CancelledKeyException.This issue (CancelledKeyException) has been reported
> before:https://issues.apache.org/jira/browse/THRIFT-4847
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5230) Fix connection leak and CancelledKeyException when handling Epoll bug
[
https://issues.apache.org/jira/browse/THRIFT-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5230.
Fix Version/s: 0.21.0
Resolution: Fixed
> Fix connection leak and CancelledKeyException when handling Epoll bug
> -
>
> Key: THRIFT-5230
> URL: https://issues.apache.org/jira/browse/THRIFT-5230
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.13.0
> Environment: java version "1.8.0_161"
>Reporter: zengji
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> 1. When Epoll bug occurs, the TThreadedSelectorServer.rebuildSelector
> rebuilds only the channel has events, the idle connection was ignored and
> caused connection leak
>
> {code:java}
> for (SelectionKey key : oldSelector.selectedKeys()) {
> if (!key.isValid() && key.readyOps() == 0)
> continue;
> SelectableChannel channel = key.channel();
> Object attachment = key.attachment();
> try {
> if (attachment == null) {
> channel.register(newSelector, key.readyOps());
> } else {
> channel.register(newSelector, key.readyOps(), attachment);
> }
> } catch (ClosedChannelException e) {
> LOGGER.error("Register new selector key error.", e);
> }
> }
> selector = newSelector;
> try {
> oldSelector.close();
> } catch (IOException e) {
> LOGGER.error("Close old selector error.", e);
> }
> {code}
> 2. When re-register the channel to new selector, the interested ops should
> same as before, not only the readyOps
>
> 3. In the same code block, the channel will be registered to a new selector
> and the previous selector will be closed, but the FrameBuffer is still
> holding the previous selector causing the FrameBuffer in a wrong state. When
> the FrameBuffer is trying to processing the channel, it may occur a
> CancelledKeyException.This issue (CancelledKeyException) has been reported
> before:https://issues.apache.org/jira/browse/THRIFT-4847
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5807) Generated Go enums' always appear to be for out of ranges values in enum
[
https://issues.apache.org/jira/browse/THRIFT-5807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5807:
---
Component/s: Go - Library
> Generated Go enums' always appear to be for out of ranges values in
> enum
>
>
> Key: THRIFT-5807
> URL: https://issues.apache.org/jira/browse/THRIFT-5807
> 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
> enum Enum_0 {
> e_0 = 0,
> e_1 = 1,
> }
> struct StructClass_0 {
> 1: required Enum_0 f_1,
> }
> service DataService {
> StructClass_0 Method_3(1: StructClass_0 agr_method_3)
> }
> {code}
>
> When the value of f_1 is set to 10(which is out of 0 and 1), the Go client
> side displays UNSET, while other languages correctly transmit the value 10.
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (THRIFT-5802) Inconsistent Validation for transmitted values
[
https://issues.apache.org/jira/browse/THRIFT-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869950#comment-17869950
]
Jens Geyer edited comment on THRIFT-5802 at 7/31/24 3:57 PM:
-
Ping. I really would appreciate an answer here. We would.
was (Author: jensg):
Ping. I really would appreciate an answer here.
> Inconsistent Validation for transmitted values
> ---
>
> Key: THRIFT-5802
> URL: https://issues.apache.org/jira/browse/THRIFT-5802
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.19.0, 0.20.0
>Reporter: Team_RPCtester
>Priority: Major
>
> *Hi,*
> We discover an inconsistent behavior under V20.0 and V19.0 by the following
> example.
> The thrift file:
> {code:java}
> namespace java com.example
> namespace go commonResource
> service DataService {
> set Method_1(1: set agr_method_1)
> }
> {code}
> When using Go,Py3 and Node.js as the client side(writer) and Node.js as the
> server side(reader) with the protocol set to “json” and the transport set to
> “framed“. We sent the value [10, 43, 38, 38, -2]to the server, but the server
> received differently. The received are respectively nothing, [10, 43, 38, -2]
> and [10, 43, 38, 38, -2] from Go,Py3 and Node.js which is unexpected. Here
> is the relevant code:We use agr_method_1_0 as the parameter sent to the
> client side(writer).
> Go client side : It throws an error “[]int8 error writing set field: slice
> is not unique back”
> {code:java}
> set_item_0 := []int8 {10, 43, 38, 38, -2}
> re_1, err := dataserviceclient.Method_1(context.Background(),set_item_0)
> if err != nil {
> fmt.Println("Method_1 receives error ", err, " back")
> } else {
> fmt.Println("Method_1 receives ", re_1, " back")
> }
> {code}
> py3 client side
> {code:java}
> agr_method_1 = [10, 43, 38, 38, -2]
> try:
> re_1 = client.Method_1(agr_method_1)
> # re_1: [10, 43, 38, -2]
> except Exception as ex:
> print(f"Method_1 receives error {ex} back")
> {code}
> Nodejs client side
> {code:java}
> const arg_Method_1 = [10, 43, 38, 38, -2];
> console.log("Method_1 sends ", arg_Method_1, " end");
> try {
> const re_1 = await client.Method_1(arg_Method_1);
> console.log("Method_1 receives ", re_1, " back");
> //re_1 [10, 43, 38, 38, -2]
> } catch (error) {
> console.log("Method_1 receives error ", error, " back");
> }
> {code}
> Nodejs server:
> {code:java}
> Method_1: async function(agr_method_1, result) {
> console.log("Method_1 receives ", agr_method_1);
> result(null, agr_method_1);
> }
> {code}
> The Go client throws an error before transmitting the parameter, indicating
> that the items are not unique. The Node.js client transmits the duplicate
> values and receives duplicated values from the Node.js server. The Python
> client automatically de-duplicates the values and receives the de-duplicated
> values. This behavior is inconsistent across the different clients.
> Can you help check the issue?
> Thank you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5802) Inconsistent Validation for transmitted values
[
https://issues.apache.org/jira/browse/THRIFT-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869950#comment-17869950
]
Jens Geyer commented on THRIFT-5802:
Ping. I really would appreciate an answer here.
> Inconsistent Validation for transmitted values
> ---
>
> Key: THRIFT-5802
> URL: https://issues.apache.org/jira/browse/THRIFT-5802
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.19.0, 0.20.0
>Reporter: Team_RPCtester
>Priority: Major
>
> *Hi,*
> We discover an inconsistent behavior under V20.0 and V19.0 by the following
> example.
> The thrift file:
> {code:java}
> namespace java com.example
> namespace go commonResource
> service DataService {
> set Method_1(1: set agr_method_1)
> }
> {code}
> When using Go,Py3 and Node.js as the client side(writer) and Node.js as the
> server side(reader) with the protocol set to “json” and the transport set to
> “framed“. We sent the value [10, 43, 38, 38, -2]to the server, but the server
> received differently. The received are respectively nothing, [10, 43, 38, -2]
> and [10, 43, 38, 38, -2] from Go,Py3 and Node.js which is unexpected. Here
> is the relevant code:We use agr_method_1_0 as the parameter sent to the
> client side(writer).
> Go client side : It throws an error “[]int8 error writing set field: slice
> is not unique back”
> {code:java}
> set_item_0 := []int8 {10, 43, 38, 38, -2}
> re_1, err := dataserviceclient.Method_1(context.Background(),set_item_0)
> if err != nil {
> fmt.Println("Method_1 receives error ", err, " back")
> } else {
> fmt.Println("Method_1 receives ", re_1, " back")
> }
> {code}
> py3 client side
> {code:java}
> agr_method_1 = [10, 43, 38, 38, -2]
> try:
> re_1 = client.Method_1(agr_method_1)
> # re_1: [10, 43, 38, -2]
> except Exception as ex:
> print(f"Method_1 receives error {ex} back")
> {code}
> Nodejs client side
> {code:java}
> const arg_Method_1 = [10, 43, 38, 38, -2];
> console.log("Method_1 sends ", arg_Method_1, " end");
> try {
> const re_1 = await client.Method_1(arg_Method_1);
> console.log("Method_1 receives ", re_1, " back");
> //re_1 [10, 43, 38, 38, -2]
> } catch (error) {
> console.log("Method_1 receives error ", error, " back");
> }
> {code}
> Nodejs server:
> {code:java}
> Method_1: async function(agr_method_1, result) {
> console.log("Method_1 receives ", agr_method_1);
> result(null, agr_method_1);
> }
> {code}
> The Go client throws an error before transmitting the parameter, indicating
> that the items are not unique. The Node.js client transmits the duplicate
> values and receives duplicated values from the Node.js server. The Python
> client automatically de-duplicates the values and receives the de-duplicated
> values. This behavior is inconsistent across the different clients.
> Can you help check the issue?
> Thank you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17869948#comment-17869948
]
Jens Geyer commented on THRIFT-5803:
You explained "consistency". You did not explain "suggesteed need" for it. Do
we need consistency or is it optional, and if so, why?
> 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
>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-5804) Add uuid support in Lua
[ https://issues.apache.org/jira/browse/THRIFT-5804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5804: --- Component/s: Lua - Compiler > 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] [Commented] (THRIFT-5801) Go does not handle the default value of list type correctly
[
https://issues.apache.org/jira/browse/THRIFT-5801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869878#comment-17869878
]
Jens Geyer commented on THRIFT-5801:
All of you? At once?
> Go does not handle the default value of list type correctly
> ---
>
> Key: THRIFT-5801
> URL: https://issues.apache.org/jira/browse/THRIFT-5801
> 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 illustrated by the following example.
> {code:java}
> namespace go commonResourcestruct
> StructClass_0 {
> 1: optional list f_1 = ["a", "b"],
> }
> service DataService {
> StructClass_0 Method_1(1: StructClass_0 agr_method_1)
> } {code}
> When default values are set for optional container type fields (e.g., lists,
> sets), these fields are not automatically initialized in Go if not explicitly
> set, whereas in other languages, these container type fields are
> automatically initialized according to the default values. For example, in
> the Go client side, our code are as follows:
> {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}
> In the Python client side:
> {code:java}
> agr_method_1 = StructClass_0()
> print(agr_method_1)
> # agr_method_1: StructClass_0(f_1-[’a’,’b’]) {code}
> In Go, the field f_1 is nil, while in Python, the field f_1 is automatically
> set to its default value ['a', 'b'].
> Can you help check the issue?
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (THRIFT-5802) Inconsistent Validation for transmitted values
[
https://issues.apache.org/jira/browse/THRIFT-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868949#comment-17868949
]
Jens Geyer edited comment on THRIFT-5802 at 7/26/24 1:49 PM:
-
{quote}Thank you for inspecting the issue. Your feedback is valuable to us.
{quote}
Thanks for the report. Is there also a "Team Patch Provider" maybe? Because
that would be even more valuable to us.
PS: Plus it would be super helpful if the team could add also the related *test
cases in code* to those PRs or patches. Nobody is going to skim a ton of
tickets and reproduce all of this by hand. The reports in their actual form
are highly appreciated, yet there is indeed room for improvement.
was (Author: jensg):
{quote}
Thank you for inspecting the issue. Your feedback is valuable to us.
{quote}
Thanks for the report. Is there also a "Team Patch Provider" maybe? Because
that would be even more valuable to us.
> Inconsistent Validation for transmitted values
> ---
>
> Key: THRIFT-5802
> URL: https://issues.apache.org/jira/browse/THRIFT-5802
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.19.0, 0.20.0
>Reporter: Team_RPCtester
>Priority: Major
>
> *Hi,*
> We discover an inconsistent behavior under V20.0 and V19.0 by the following
> example.
> The thrift file:
> {code:java}
> namespace java com.example
> namespace go commonResource
> service DataService {
> set Method_1(1: set agr_method_1)
> }
> {code}
> When using Go,Py3 and Node.js as the client side(writer) and Node.js as the
> server side(reader) with the protocol set to “json” and the transport set to
> “framed“. We sent the value [10, 43, 38, 38, -2]to the server, but the server
> received differently. The received are respectively nothing, [10, 43, 38, -2]
> and [10, 43, 38, 38, -2] from Go,Py3 and Node.js which is unexpected. Here
> is the relevant code:We use agr_method_1_0 as the parameter sent to the
> client side(writer).
> Go client side : It throws an error “[]int8 error writing set field: slice
> is not unique back”
> {code:java}
> set_item_0 := []int8 {10, 43, 38, 38, -2}
> re_1, err := dataserviceclient.Method_1(context.Background(),set_item_0)
> if err != nil {
> fmt.Println("Method_1 receives error ", err, " back")
> } else {
> fmt.Println("Method_1 receives ", re_1, " back")
> }
> {code}
> py3 client side
> {code:java}
> agr_method_1 = [10, 43, 38, 38, -2]
> try:
> re_1 = client.Method_1(agr_method_1)
> # re_1: [10, 43, 38, -2]
> except Exception as ex:
> print(f"Method_1 receives error {ex} back")
> {code}
> Nodejs client side
> {code:java}
> const arg_Method_1 = [10, 43, 38, 38, -2];
> console.log("Method_1 sends ", arg_Method_1, " end");
> try {
> const re_1 = await client.Method_1(arg_Method_1);
> console.log("Method_1 receives ", re_1, " back");
> //re_1 [10, 43, 38, 38, -2]
> } catch (error) {
> console.log("Method_1 receives error ", error, " back");
> }
> {code}
> Nodejs server:
> {code:java}
> Method_1: async function(agr_method_1, result) {
> console.log("Method_1 receives ", agr_method_1);
> result(null, agr_method_1);
> }
> {code}
> The Go client throws an error before transmitting the parameter, indicating
> that the items are not unique. The Node.js client transmits the duplicate
> values and receives duplicated values from the Node.js server. The Python
> client automatically de-duplicates the values and receives the de-duplicated
> values. This behavior is inconsistent across the different clients.
> Can you help check the issue?
> Thank you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17868948#comment-17868948
]
Jens Geyer commented on THRIFT-5803:
{quote}
While we do think that required fields should be set before transmission.
{quote}
We think that you all are right. That's exactly what REQUIRED means.
{quote}
the behavior observed across different languages suggests a need for
consistency. It would be beneficial if all languages handled the default values
and required field initialization in a similar manner.
{quote}
What on earth is a "suggested need for consistency"?
> 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
>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] [Commented] (THRIFT-5802) Inconsistent Validation for transmitted values
[
https://issues.apache.org/jira/browse/THRIFT-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868949#comment-17868949
]
Jens Geyer commented on THRIFT-5802:
{quote}
Thank you for inspecting the issue. Your feedback is valuable to us.
{quote}
Thanks for the report. Is there also a "Team Patch Provider" maybe? Because
that would be even more valuable to us.
> Inconsistent Validation for transmitted values
> ---
>
> Key: THRIFT-5802
> URL: https://issues.apache.org/jira/browse/THRIFT-5802
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.19.0, 0.20.0
>Reporter: Team_RPCtester
>Priority: Major
>
> *Hi,*
> We discover an inconsistent behavior under V20.0 and V19.0 by the following
> example.
> The thrift file:
> {code:java}
> namespace java com.example
> namespace go commonResource
> service DataService {
> set Method_1(1: set agr_method_1)
> }
> {code}
> When using Go,Py3 and Node.js as the client side(writer) and Node.js as the
> server side(reader) with the protocol set to “json” and the transport set to
> “framed“. We sent the value [10, 43, 38, 38, -2]to the server, but the server
> received differently. The received are respectively nothing, [10, 43, 38, -2]
> and [10, 43, 38, 38, -2] from Go,Py3 and Node.js which is unexpected. Here
> is the relevant code:We use agr_method_1_0 as the parameter sent to the
> client side(writer).
> Go client side : It throws an error “[]int8 error writing set field: slice
> is not unique back”
> {code:java}
> set_item_0 := []int8 {10, 43, 38, 38, -2}
> re_1, err := dataserviceclient.Method_1(context.Background(),set_item_0)
> if err != nil {
> fmt.Println("Method_1 receives error ", err, " back")
> } else {
> fmt.Println("Method_1 receives ", re_1, " back")
> }
> {code}
> py3 client side
> {code:java}
> agr_method_1 = [10, 43, 38, 38, -2]
> try:
> re_1 = client.Method_1(agr_method_1)
> # re_1: [10, 43, 38, -2]
> except Exception as ex:
> print(f"Method_1 receives error {ex} back")
> {code}
> Nodejs client side
> {code:java}
> const arg_Method_1 = [10, 43, 38, 38, -2];
> console.log("Method_1 sends ", arg_Method_1, " end");
> try {
> const re_1 = await client.Method_1(arg_Method_1);
> console.log("Method_1 receives ", re_1, " back");
> //re_1 [10, 43, 38, 38, -2]
> } catch (error) {
> console.log("Method_1 receives error ", error, " back");
> }
> {code}
> Nodejs server:
> {code:java}
> Method_1: async function(agr_method_1, result) {
> console.log("Method_1 receives ", agr_method_1);
> result(null, agr_method_1);
> }
> {code}
> The Go client throws an error before transmitting the parameter, indicating
> that the items are not unique. The Node.js client transmits the duplicate
> values and receives duplicated values from the Node.js server. The Python
> client automatically de-duplicates the values and receives the de-duplicated
> values. This behavior is inconsistent across the different clients.
> Can you help check the issue?
> Thank you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5801) Handling Default Values for Optional Container Type Fields
[
https://issues.apache.org/jira/browse/THRIFT-5801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5801:
---
Component/s: Go - Compiler
> Handling Default Values for Optional Container Type Fields
> --
>
> Key: THRIFT-5801
> URL: https://issues.apache.org/jira/browse/THRIFT-5801
> 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 illustrated by the following example.
> {code:java}
> namespace go commonResourcestruct
> StructClass_0 {
> 1: optional list f_1 = ["a", "b"],
> }
> service DataService {
> StructClass_0 Method_1(1: StructClass_0 agr_method_1)
> } {code}
> When default values are set for optional container type fields (e.g., lists,
> sets), these fields are not automatically initialized in Go if not explicitly
> set, whereas in other languages, these container type fields are
> automatically initialized according to the default values. For example, in
> the Go client side, our code are as follows:
> {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}
> In the Python client side:
> {code:java}
> agr_method_1 = StructClass_0()
> print(agr_method_1)
> # agr_method_1: StructClass_0(f_1-[’a’,’b’]) {code}
> In Go, the field f_1 is nil, while in Python, the field f_1 is automatically
> set to its default value ['a', 'b'].
> Can you help check the issue?
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5802) Inconsistent Validation for transmitted values
[
https://issues.apache.org/jira/browse/THRIFT-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5802:
---
Component/s: Node.js - Library
> Inconsistent Validation for transmitted values
> ---
>
> Key: THRIFT-5802
> URL: https://issues.apache.org/jira/browse/THRIFT-5802
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.19.0, 0.20.0
>Reporter: Team_RPCtester
>Priority: Major
>
> *Hi,*
> We discover an inconsistent behavior under V20.0 and V19.0 by the following
> example.
> The thrift file:
> {code:java}
> namespace java com.example
> namespace go commonResource
> service DataService {
> set Method_1(1: set agr_method_1)
> }
> {code}
> When using Go,Py3 and Node.js as the client side(writer) and Node.js as the
> server side(reader) with the protocol set to “json” and the transport set to
> “framed“. We sent the value [10, 43, 38, 38, -2]to the server, but the server
> received differently. The received are respectively nothing, [10, 43, 38, -2]
> and [10, 43, 38, 38, -2] from Go,Py3 and Node.js which is unexpected. Here
> is the relevant code:We use agr_method_1_0 as the parameter sent to the
> client side(writer).
> Go client side : It throws an error “[]int8 error writing set field: slice
> is not unique back”
> {code:java}
> set_item_0 := []int8 {10, 43, 38, 38, -2}
> re_1, err := dataserviceclient.Method_1(context.Background(),set_item_0)
> if err != nil {
> fmt.Println("Method_1 receives error ", err, " back")
> } else {
> fmt.Println("Method_1 receives ", re_1, " back")
> }
> {code}
> py3 client side
> {code:java}
> agr_method_1 = [10, 43, 38, 38, -2]
> try:
> re_1 = client.Method_1(agr_method_1)
> # re_1: [10, 43, 38, -2]
> except Exception as ex:
> print(f"Method_1 receives error {ex} back")
> {code}
> Nodejs client side
> {code:java}
> const arg_Method_1 = [10, 43, 38, 38, -2];
> console.log("Method_1 sends ", arg_Method_1, " end");
> try {
> const re_1 = await client.Method_1(arg_Method_1);
> console.log("Method_1 receives ", re_1, " back");
> //re_1 [10, 43, 38, 38, -2]
> } catch (error) {
> console.log("Method_1 receives error ", error, " back");
> }
> {code}
> Nodejs server:
> {code:java}
> Method_1: async function(agr_method_1, result) {
> console.log("Method_1 receives ", agr_method_1);
> result(null, agr_method_1);
> }
> {code}
> The Go client throws an error before transmitting the parameter, indicating
> that the items are not unique. The Node.js client transmits the duplicate
> values and receives duplicated values from the Node.js server. The Python
> client automatically de-duplicates the values and receives the de-duplicated
> values. This behavior is inconsistent across the different clients.
> Can you help check the issue?
> Thank you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5801) Handling Default Values for Optional Container Type Fields
[
https://issues.apache.org/jira/browse/THRIFT-5801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868798#comment-17868798
]
Jens Geyer commented on THRIFT-5801:
{quote}
When default values are set for optional container type fields (e.g., lists,
sets), these fields are not automatically initialized in Go if not explicitly
set, whereas in other languages, these container type fields are automatically
initialized according to the default values.
{quote}
Should probably be the title of that ticket then, right?
> Handling Default Values for Optional Container Type Fields
> --
>
> Key: THRIFT-5801
> URL: https://issues.apache.org/jira/browse/THRIFT-5801
> Project: Thrift
> Issue Type: Bug
>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 commonResourcestruct
> StructClass_0 {
> 1: optional list f_1 = ["a", "b"],
> }
> service DataService {
> StructClass_0 Method_1(1: StructClass_0 agr_method_1)
> } {code}
> When default values are set for optional container type fields (e.g., lists,
> sets), these fields are not automatically initialized in Go if not explicitly
> set, whereas in other languages, these container type fields are
> automatically initialized according to the default values. For example, in
> the Go client side, our code are as follows:
> {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}
> In the Python client side:
> {code:java}
> agr_method_1 = StructClass_0()
> print(agr_method_1)
> # agr_method_1: StructClass_0(f_1-[’a’,’b’]) {code}
> In Go, the field f_1 is nil, while in Python, the field f_1 is automatically
> set to its default value ['a', 'b'].
> Can you help check the issue?
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5802) Inconsistent Validation for transmitted values
[
https://issues.apache.org/jira/browse/THRIFT-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868628#comment-17868628
]
Jens Geyer commented on THRIFT-5802:
{quote}
set: An unordered set of unique elements. Translates to an STL set, Java
HashSet, set in Python, etc. Note: PHP does not support sets, so it is treated
similar to a List
{quote}
So sending duplicated values is already incorrect. Hence, both Go and Py
respond in an equally valid manner. I would prefer Gos reaction but the input
data are illegal so the server can basically do whatever he wants. What IMHO
indeed should be fixed is returning the incorrect data, as Node does.
https://thrift.apache.org/docs/types
> Inconsistent Validation for transmitted values
> ---
>
> Key: THRIFT-5802
> URL: https://issues.apache.org/jira/browse/THRIFT-5802
> Project: Thrift
> Issue Type: Bug
>Affects Versions: 0.19.0, 0.20.0
>Reporter: Team_RPCtester
>Priority: Major
>
> *Hi,*
> We discover an inconsistent behavior under V20.0 and V19.0 by the following
> example.
> The thrift file:
> {code:java}
> namespace java com.example
> namespace go commonResource
> service DataService {
> set Method_1(1: set agr_method_1)
> }
> {code}
> When using Go,Py3 and Node.js as the client side(writer) and Node.js as the
> server side(reader) with the protocol set to “json” and the transport set to
> “framed“. We sent the value [10, 43, 38, 38, -2]to the server, but the server
> received differently. The received are respectively nothing, [10, 43, 38, -2]
> and [10, 43, 38, 38, -2] from Go,Py3 and Node.js which is unexpected. Here
> is the relevant code:We use agr_method_1_0 as the parameter sent to the
> client side(writer).
> Go client side : It throws an error “[]int8 error writing set field: slice
> is not unique back”
> {code:java}
> set_item_0 := []int8 {10, 43, 38, 38, -2}
> re_1, err := dataserviceclient.Method_1(context.Background(),set_item_0)
> if err != nil {
> fmt.Println("Method_1 receives error ", err, " back")
> } else {
> fmt.Println("Method_1 receives ", re_1, " back")
> }
> {code}
> py3 client side
> {code:java}
> agr_method_1 = [10, 43, 38, 38, -2]
> try:
> re_1 = client.Method_1(agr_method_1)
> # re_1: [10, 43, 38, -2]
> except Exception as ex:
> print(f"Method_1 receives error {ex} back")
> {code}
> Nodejs client side
> {code:java}
> const arg_Method_1 = [10, 43, 38, 38, -2];
> console.log("Method_1 sends ", arg_Method_1, " end");
> try {
> const re_1 = await client.Method_1(arg_Method_1);
> console.log("Method_1 receives ", re_1, " back");
> //re_1 [10, 43, 38, 38, -2]
> } catch (error) {
> console.log("Method_1 receives error ", error, " back");
> }
> {code}
> Nodejs server:
> {code:java}
> Method_1: async function(agr_method_1, result) {
> console.log("Method_1 receives ", agr_method_1);
> result(null, agr_method_1);
> }
> {code}
> The Go client throws an error before transmitting the parameter, indicating
> that the items are not unique. The Node.js client transmits the duplicate
> values and receives duplicated values from the Node.js server. The Python
> client automatically de-duplicates the values and receives the de-duplicated
> values. This behavior is inconsistent across the different clients.
> Can you help check the issue?
> Thank you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (THRIFT-5802) Inconsistent Validation for transmitted values
[
https://issues.apache.org/jira/browse/THRIFT-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868628#comment-17868628
]
Jens Geyer edited comment on THRIFT-5802 at 7/25/24 10:09 AM:
--
{quote}set: An unordered set of unique elements. Translates to an STL set, Java
HashSet, set in Python, etc. Note: PHP does not support sets, so it is treated
similar to a List
{quote}
So sending duplicated values is already incorrect. Hence, both Go and Py
respond in an equally valid manner. I would prefer Gos reaction but the input
data are illegal so the server can basically do whatever he wants - there is no
clear spec what should happen in such a case.
What IMHO indeed should be fixed is returning the incorrect data, as Node does.
[https://thrift.apache.org/docs/types]
was (Author: jensg):
{quote}
set: An unordered set of unique elements. Translates to an STL set, Java
HashSet, set in Python, etc. Note: PHP does not support sets, so it is treated
similar to a List
{quote}
So sending duplicated values is already incorrect. Hence, both Go and Py
respond in an equally valid manner. I would prefer Gos reaction but the input
data are illegal so the server can basically do whatever he wants. What IMHO
indeed should be fixed is returning the incorrect data, as Node does.
https://thrift.apache.org/docs/types
> Inconsistent Validation for transmitted values
> ---
>
> Key: THRIFT-5802
> URL: https://issues.apache.org/jira/browse/THRIFT-5802
> Project: Thrift
> Issue Type: Bug
>Affects Versions: 0.19.0, 0.20.0
>Reporter: Team_RPCtester
>Priority: Major
>
> *Hi,*
> We discover an inconsistent behavior under V20.0 and V19.0 by the following
> example.
> The thrift file:
> {code:java}
> namespace java com.example
> namespace go commonResource
> service DataService {
> set Method_1(1: set agr_method_1)
> }
> {code}
> When using Go,Py3 and Node.js as the client side(writer) and Node.js as the
> server side(reader) with the protocol set to “json” and the transport set to
> “framed“. We sent the value [10, 43, 38, 38, -2]to the server, but the server
> received differently. The received are respectively nothing, [10, 43, 38, -2]
> and [10, 43, 38, 38, -2] from Go,Py3 and Node.js which is unexpected. Here
> is the relevant code:We use agr_method_1_0 as the parameter sent to the
> client side(writer).
> Go client side : It throws an error “[]int8 error writing set field: slice
> is not unique back”
> {code:java}
> set_item_0 := []int8 {10, 43, 38, 38, -2}
> re_1, err := dataserviceclient.Method_1(context.Background(),set_item_0)
> if err != nil {
> fmt.Println("Method_1 receives error ", err, " back")
> } else {
> fmt.Println("Method_1 receives ", re_1, " back")
> }
> {code}
> py3 client side
> {code:java}
> agr_method_1 = [10, 43, 38, 38, -2]
> try:
> re_1 = client.Method_1(agr_method_1)
> # re_1: [10, 43, 38, -2]
> except Exception as ex:
> print(f"Method_1 receives error {ex} back")
> {code}
> Nodejs client side
> {code:java}
> const arg_Method_1 = [10, 43, 38, 38, -2];
> console.log("Method_1 sends ", arg_Method_1, " end");
> try {
> const re_1 = await client.Method_1(arg_Method_1);
> console.log("Method_1 receives ", re_1, " back");
> //re_1 [10, 43, 38, 38, -2]
> } catch (error) {
> console.log("Method_1 receives error ", error, " back");
> }
> {code}
> Nodejs server:
> {code:java}
> Method_1: async function(agr_method_1, result) {
> console.log("Method_1 receives ", agr_method_1);
> result(null, agr_method_1);
> }
> {code}
> The Go client throws an error before transmitting the parameter, indicating
> that the items are not unique. The Node.js client transmits the duplicate
> values and receives duplicated values from the Node.js server. The Python
> client automatically de-duplicates the values and receives the de-duplicated
> values. This behavior is inconsistent across the different clients.
> Can you help check the issue?
> Thank you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17868472#comment-17868472
]
Jens Geyer commented on THRIFT-5800:
Agree with -strict
> "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)
>Reporter: Yuxuan Wang
>Priority: Minor
>
> 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-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:
---
Priority: Minor (was: Major)
> "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)
>Reporter: Yuxuan Wang
>Priority: Minor
>
> 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-5798) Expand netstd compile tests to fully cover all current target environments
[ https://issues.apache.org/jira/browse/THRIFT-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5798. Fix Version/s: 0.21.0 Resolution: Fixed > Expand netstd compile tests to fully cover all current target environments > -- > > Key: THRIFT-5798 > URL: https://issues.apache.org/jira/browse/THRIFT-5798 > Project: Thrift > Issue Type: Sub-task > Components: netstd - Compiler >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Fix For: 0.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The netstd compile tests basically only cover net8 right now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-5796) Indicate target environment via #if check
[ https://issues.apache.org/jira/browse/THRIFT-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5796. Fix Version/s: 0.21.0 Resolution: Fixed > Indicate target environment via #if check > - > > Key: THRIFT-5796 > URL: https://issues.apache.org/jira/browse/THRIFT-5796 > Project: Thrift > Issue Type: Improvement > Components: netstd - Compiler >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Fix For: 0.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The special implications of net6 and net8 options are not always clear and > are somewhat prone to be mis-used. The generated code should escalate that > issue more prominently and point to the --help documentation page. > The side-effect of breaking incorrectly used combinations is absolutely > intended and the whole point here. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5797) HashSet() CTOR takes no argument for net < 5
[
https://issues.apache.org/jira/browse/THRIFT-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5797:
---
Component/s: netstd - Compiler
> HashSet() CTOR takes no argument for net < 5
>
>
> Key: THRIFT-5797
> URL: https://issues.apache.org/jira/browse/THRIFT-5797
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Compiler
>Reporter: Jens Geyer
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Generating code for HashSet<>targeting netstd 2 produces uncompilable code,
> since the count parameter cannot be passed in:
> {code:java}
> var bar = new HashSet(count); // requires net >= 5
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5797) HashSet() CTOR takes no argument for net < 5
[
https://issues.apache.org/jira/browse/THRIFT-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5797.
Fix Version/s: 0.21.0
Assignee: Jens Geyer
Resolution: Fixed
> HashSet() CTOR takes no argument for net < 5
>
>
> Key: THRIFT-5797
> URL: https://issues.apache.org/jira/browse/THRIFT-5797
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Generating code for HashSet<>targeting netstd 2 produces uncompilable code,
> since the count parameter cannot be passed in:
> {code:java}
> var bar = new HashSet(count); // requires net >= 5
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (THRIFT-5798) Expand netstd compile tests to fully cover all current target environments
Jens Geyer created THRIFT-5798: -- Summary: Expand netstd compile tests to fully cover all current target environments Key: THRIFT-5798 URL: https://issues.apache.org/jira/browse/THRIFT-5798 Project: Thrift Issue Type: Sub-task Components: netstd - Compiler Reporter: Jens Geyer Assignee: Jens Geyer The netstd compile tests basically only cover net8 right now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5797) HashSet() CTOR takes no argument for net < 5
Jens Geyer created THRIFT-5797:
--
Summary: HashSet() CTOR takes no argument for net < 5
Key: THRIFT-5797
URL: https://issues.apache.org/jira/browse/THRIFT-5797
Project: Thrift
Issue Type: Bug
Reporter: Jens Geyer
Generating code for HashSet<>targeting netstd 2 produces uncompilable code,
since the count parameter cannot be passed in:
{code:java}
var bar = new HashSet(count); // requires net >= 5
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (THRIFT-5796) Indicate target environment via #if check
Jens Geyer created THRIFT-5796: -- Summary: Indicate target environment via #if check Key: THRIFT-5796 URL: https://issues.apache.org/jira/browse/THRIFT-5796 Project: Thrift Issue Type: Improvement Components: netstd - Compiler Reporter: Jens Geyer Assignee: Jens Geyer The special implications of net6 and net8 options are not always clear and are somewhat prone to be mis-used. The generated code should escalate that issue more prominently and point to the --help documentation page. The side-effect of breaking incorrectly used combinations is absolutely intended and the whole point here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-5795) namespace not properly escaped
[
https://issues.apache.org/jira/browse/THRIFT-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5795.
Fix Version/s: 0.21.0
Resolution: Fixed
> namespace not properly escaped
> --
>
> Key: THRIFT-5795
> URL: https://issues.apache.org/jira/browse/THRIFT-5795
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This IDL produces an illegal namespace name (default is a C# keyword)
> {code:java}
> namespace * some.default
> struct foo {
> 1: double bar;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5795) namespace not properly escaped
[
https://issues.apache.org/jira/browse/THRIFT-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5795:
---
Component/s: netstd - Compiler
> namespace not properly escaped
> --
>
> Key: THRIFT-5795
> URL: https://issues.apache.org/jira/browse/THRIFT-5795
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
>
> This IDL produces an illegal namespace name (default is a C# keyword)
> {code:java}
> namespace * some.default
> struct foo {
> 1: double bar;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5795) namespace not properly escaped
[
https://issues.apache.org/jira/browse/THRIFT-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5795:
---
Summary: namespace not properly escaped (was: namespace not properly
escaped fro keywords)
> namespace not properly escaped
> --
>
> Key: THRIFT-5795
> URL: https://issues.apache.org/jira/browse/THRIFT-5795
> Project: Thrift
> Issue Type: Bug
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
>
> This IDL produces an illegal namespace name (default is a C# keyword)
> {code:java}
> namespace * some.default
> struct foo {
> 1: double bar;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (THRIFT-5795) namespace not properly escaped fro keywords
Jens Geyer created THRIFT-5795:
--
Summary: namespace not properly escaped fro keywords
Key: THRIFT-5795
URL: https://issues.apache.org/jira/browse/THRIFT-5795
Project: Thrift
Issue Type: Bug
Reporter: Jens Geyer
Assignee: Jens Geyer
This IDL produces an illegal namespace name (default is a C# keyword)
{code:java}
namespace * some.default
struct foo {
1: double bar;
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5678) TConnectedClient: warning due to non-virtual dtor
[
https://issues.apache.org/jira/browse/THRIFT-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5678.
Fix Version/s: 0.21.0
Assignee: Christopher Friedt
Resolution: Fixed
> TConnectedClient: warning due to non-virtual dtor
> -
>
> Key: THRIFT-5678
> URL: https://issues.apache.org/jira/browse/THRIFT-5678
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.13.0, 0.14.0, 0.15.0, 0.14.1, 0.14.2, 0.16.0, 0.17.0
>Reporter: Christopher Friedt
>Assignee: Christopher Friedt
>Priority: Minor
> Fix For: 0.21.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> In TConnectedClient.h the destructor is non-virtual, which causes the warning
> below.
> {code:java}
> In member function 'void
> apache::thrift::server::TServerFramework::disposeConnectedClient(apache::thrift::server::TConnectedClient*)':
> lib/cpp/src/thrift/server/TServerFramework.cpp:234:3: warning: deleting
> object of polymorphic class type 'apache::thrift::server::TConnectedClient'
> which has non-virtual destructor might cause undefined behavior
> [-Wdelete-non-virtual-dtor]
> 234 | delete pClient;
> | ^~{code}
> Not itself a major problem, but Zephyr CI promotes all warnings to errors,
> which causes builds to fail.
> TConnectedClient.cpp has the following line of code:
> {code:java}
> TConnectedClient::~TConnectedClient() = default;{code}
> It might be considered a regression. The commit that removed the virtual
> qualifier was 042580f53441efe1bc5c80c89351fcb30740659e
> Suggested fix is to mark it as virtual and set it to default in the header,
> and then delete the definition in the .cpp file.
> Alternatively, keep the .cpp dtor, but simply re-add the virtual keyword in
> the header
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5492) Bogus END_OF_FILE exception
[
https://issues.apache.org/jira/browse/THRIFT-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5492.
Fix Version/s: 0.21.0
Assignee: Steven Licking
Resolution: Fixed
I merged the fix part in
[{{86b05bf}}|https://github.com/apache/thrift/commit/86b05bf2294de5202f22033a2713f100c493b067],
but left the rest, as there are unfortunately [still open
questions|https://github.com/apache/thrift/pull/2496#issuecomment-1772415350]
etc.
> Bogus END_OF_FILE exception
> ---
>
> Key: THRIFT-5492
> URL: https://issues.apache.org/jira/browse/THRIFT-5492
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.14.1
>Reporter: Steven Licking
>Assignee: Steven Licking
>Priority: Major
> Fix For: 0.21.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When using a TMultiplexedProcessor server with TBufferedTransportFactory and
> TBinaryProtocolFactory a connection to a client will be closed due to an
> END_OF_FILE exception after sending many messages.
> It appears that when the client connects, in class TTransport, the
> remainingMessageSize_ is set to getMaxMessageSize() which, by default, is
> DEFAULT_MAX_MESSAGE_SIZE and is defined to be 100*1024*1024 in
> TConfiguration.h.
> The remainingMessageSize_ is decremented as messages are parsed, for example
> when parsing a field in the message that is of type binary I see the code
> calling readStringBody in TBinaryProtocol.tcc:455 which then calls
> this->trans_->consume(size) which goes to TBufferTransports.h:124 and calls
> countConsumedMessageBytes which finally decrements remainingMessageSize_.
> However, nothing ever resets remainingMessageSize_, so after it is
> decremented from 100*1024*1024 down to zero it fails with an END_OF_FILE
> exception.
> It seems that the remainingMessageSize_ should be reset either when a new
> message is received from the client or after a message is processed. However
> I'm not quite sure what the intended purpose of remainingMessageSize_ is.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5794) Uncompilable C# code in 0.20.0
[
https://issues.apache.org/jira/browse/THRIFT-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5794.
Fix Version/s: 0.21.0
0.20.0
Resolution: Fixed
* Fixed via PR [#2993|https://github.com/apache/thrift/pull/2993] for 0.20.0
* Fixed via PR [#2966|https://github.com/apache/thrift/pull/2966] for 0.21.0
Thanks to [Sven Roederer|https://github.com/SvenRoederer] for pointing this out
and providing the 0.20.0 patch.
> Uncompilable C# code in 0.20.0
> --
>
> Key: THRIFT-5794
> URL: https://issues.apache.org/jira/browse/THRIFT-5794
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Compiler
>Affects Versions: 0.20.0
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0, 0.20.0
>
>
> h2. Symptom
> {code}
> namespace * deepcopy_syntax
> struct CIELab
> {
> 1: double L;
> 2: double a;
> 3: double b;
> }
> {code}
> via
> {code}
> thrift -gen netstd test.thrift
> {code}
> leads to
> {code}
> public CIELab DeepCopy()
> {
> var tmp5 = new CIELab()// <- here the closing ";" is missing
> if(__isset.L)
> {
> tmp5.L = this.L;
> }
> ...
> {code}
> h2. Affected versions
> * 0.20.0 only
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (THRIFT-5794) Uncompilable C# code in 0.20.0
[
https://issues.apache.org/jira/browse/THRIFT-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17863946#comment-17863946
]
Jens Geyer edited comment on THRIFT-5794 at 7/8/24 9:33 PM:
* Fixed via PR [#2993|https://github.com/apache/thrift/pull/2993] for 0.20.0
(not released)
* Fixed via PR [#2966|https://github.com/apache/thrift/pull/2966] for 0.21.0
Thanks to [Sven Roederer|https://github.com/SvenRoederer] for pointing this out
and providing the 0.20.0 patch.
was (Author: jensg):
* Fixed via PR [#2993|https://github.com/apache/thrift/pull/2993] for 0.20.0
* Fixed via PR [#2966|https://github.com/apache/thrift/pull/2966] for 0.21.0
Thanks to [Sven Roederer|https://github.com/SvenRoederer] for pointing this out
and providing the 0.20.0 patch.
> Uncompilable C# code in 0.20.0
> --
>
> Key: THRIFT-5794
> URL: https://issues.apache.org/jira/browse/THRIFT-5794
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Compiler
>Affects Versions: 0.20.0
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0
>
>
> h2. Symptom
> {code}
> namespace * deepcopy_syntax
> struct CIELab
> {
> 1: double L;
> 2: double a;
> 3: double b;
> }
> {code}
> via
> {code}
> thrift -gen netstd test.thrift
> {code}
> leads to
> {code}
> public CIELab DeepCopy()
> {
> var tmp5 = new CIELab()// <- here the closing ";" is missing
> if(__isset.L)
> {
> tmp5.L = this.L;
> }
> ...
> {code}
> h2. Affected versions
> * 0.20.0 only
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5794) Uncompilable C# code in 0.20.0
[
https://issues.apache.org/jira/browse/THRIFT-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5794:
---
Fix Version/s: (was: 0.20.0)
> Uncompilable C# code in 0.20.0
> --
>
> Key: THRIFT-5794
> URL: https://issues.apache.org/jira/browse/THRIFT-5794
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Compiler
>Affects Versions: 0.20.0
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.21.0
>
>
> h2. Symptom
> {code}
> namespace * deepcopy_syntax
> struct CIELab
> {
> 1: double L;
> 2: double a;
> 3: double b;
> }
> {code}
> via
> {code}
> thrift -gen netstd test.thrift
> {code}
> leads to
> {code}
> public CIELab DeepCopy()
> {
> var tmp5 = new CIELab()// <- here the closing ";" is missing
> if(__isset.L)
> {
> tmp5.L = this.L;
> }
> ...
> {code}
> h2. Affected versions
> * 0.20.0 only
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (THRIFT-5794) Uncompilable C# code in 0.20.0
Jens Geyer created THRIFT-5794:
--
Summary: Uncompilable C# code in 0.20.0
Key: THRIFT-5794
URL: https://issues.apache.org/jira/browse/THRIFT-5794
Project: Thrift
Issue Type: Bug
Components: netstd - Compiler
Affects Versions: 0.20.0
Reporter: Jens Geyer
Assignee: Jens Geyer
h2. Symptom
{code}
namespace * deepcopy_syntax
struct CIELab
{
1: double L;
2: double a;
3: double b;
}
{code}
via
{code}
thrift -gen netstd test.thrift
{code}
leads to
{code}
public CIELab DeepCopy()
{
var tmp5 = new CIELab()// <- here the closing ";" is missing
if(__isset.L)
{
tmp5.L = this.L;
}
...
{code}
h2. Affected versions
* 0.20.0 only
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5777) timeout exception mismatched
[
https://issues.apache.org/jira/browse/THRIFT-5777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5777.
Assignee: xuyundong
Resolution: Fixed
> timeout exception mismatched
>
>
> Key: THRIFT-5777
> URL: https://issues.apache.org/jira/browse/THRIFT-5777
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
>Affects Versions: 0.18.1, 0.19.0, 0.20.0
>Reporter: xuyundong
>Assignee: xuyundong
>Priority: Major
> Fix For: 0.21.0
>
>
> h2. What error occurred?
> When the Python client times out while reading content from the server, the
> exception thrown is not "read timeout," but rather "unexpected exception."
> h2. Why did this error occur?
> h3. the socket.timeout error doesn't includes the errno parameter in its args
> attribute.
> I try to make a timeout error on my pc, it only contains the error string.
>
> {code:java}
> Python 3.11.1 (main, Jan 5 2023, 14:25:08) [GCC 11.3.0]
> Type 'copyright', 'credits' or 'license' for more information
> IPython 8.13.2 – An enhanced Interactive Python. Type '?' for help.In [1]:
> import socket
> ...: from urllib.request import urlopen
> ...:
> ...: url = 'http://httpbin.org/get'
> ...:
> ...: socket.setdefaulttimeout(0.01)
> ...: try:
> ...: urlopen(url)
> ...: except Exception as e:
> ...: err1 = e.reason
> ...:
> ...:In [2]: type(err1)
> Out[2]: TimeoutErrorIn [3]: err1.args
> Out[3]: ('timed out',)
> {code}
> And my system is ubuntu 22.04
> {code:java}
> ø> uname -a
> Linux Macmini 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct
> 9 15:34:04 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
> {code}
> *TSocket.read handle exception error*
> Because
> {code:java}
> socket.error.args == ('timed out',){code}
> , the condition
> {code:java}
> elif e.args[0] == errno.ETIMEDOUT{code}
>
> cannot be True, resulting in the throwing of the wrong exception
> {{{}TTransportException(message="unexpected exception", inner=e){}}}.
> h2. How to fix it
> I determine whether a timeout has occurred by checking if the exception is a
> socket.timeout, no longer relying on e.args.
> see details on PR: [https://github.com/apache/thrift/pull/2961]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (THRIFT-5654) LNK4042 and LNK2019 in go_validator_generator.cc
[ https://issues.apache.org/jira/browse/THRIFT-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5654. Fix Version/s: 0.21.0 Resolution: Fixed Thanks! > LNK4042 and LNK2019 in go_validator_generator.cc > > > Key: THRIFT-5654 > URL: https://issues.apache.org/jira/browse/THRIFT-5654 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler > Environment: Visual Studio 2022 >Reporter: Jens Geyer >Assignee: Eyüp Volkan >Priority: Critical > Fix For: 0.21.0 > > Attachments: > 0001-THRIFT-5654-LNK4042-and-LNK2019-in-go_validator_gene-1.patch > > > With VS2022 I get "warning LNK4042: object specified more than once; extras > ignored" in go_validator_generator.obj. > Also I had to comment out this to get rid of some fatal LNK2019: unresolved > external symbol: > //go_validator_generator(this).generate_struct_validator(f_types_, tstruct); > Extra info: > https://stackoverflow.com/questions/3695174/visual-studio-2010s-strange-warning-lnk4042 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (THRIFT-5654) LNK4042 and LNK2019 in go_validator_generator.cc
[ https://issues.apache.org/jira/browse/THRIFT-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer reassigned THRIFT-5654: -- Assignee: Eyüp Volkan > LNK4042 and LNK2019 in go_validator_generator.cc > > > Key: THRIFT-5654 > URL: https://issues.apache.org/jira/browse/THRIFT-5654 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler > Environment: Visual Studio 2022 >Reporter: Jens Geyer >Assignee: Eyüp Volkan >Priority: Critical > Attachments: > 0001-THRIFT-5654-LNK4042-and-LNK2019-in-go_validator_gene-1.patch > > > With VS2022 I get "warning LNK4042: object specified more than once; extras > ignored" in go_validator_generator.obj. > Also I had to comment out this to get rid of some fatal LNK2019: unresolved > external symbol: > //go_validator_generator(this).generate_struct_validator(f_types_, tstruct); > Extra info: > https://stackoverflow.com/questions/3695174/visual-studio-2010s-strange-warning-lnk4042 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5654) LNK4042 and LNK2019 in go_validator_generator.cc
[ https://issues.apache.org/jira/browse/THRIFT-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5654: --- Attachment: (was: 0001-THRIFT-5654-LNK4042-and-LNK2019-in-go_validator_gene.patch) > LNK4042 and LNK2019 in go_validator_generator.cc > > > Key: THRIFT-5654 > URL: https://issues.apache.org/jira/browse/THRIFT-5654 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler > Environment: Visual Studio 2022 >Reporter: Jens Geyer >Priority: Critical > Attachments: > 0001-THRIFT-5654-LNK4042-and-LNK2019-in-go_validator_gene-1.patch > > > With VS2022 I get "warning LNK4042: object specified more than once; extras > ignored" in go_validator_generator.obj. > Also I had to comment out this to get rid of some fatal LNK2019: unresolved > external symbol: > //go_validator_generator(this).generate_struct_validator(f_types_, tstruct); > Extra info: > https://stackoverflow.com/questions/3695174/visual-studio-2010s-strange-warning-lnk4042 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5654) LNK4042 and LNK2019 in go_validator_generator.cc
[ https://issues.apache.org/jira/browse/THRIFT-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5654: --- Attachment: 0001-THRIFT-5654-LNK4042-and-LNK2019-in-go_validator_gene-1.patch > LNK4042 and LNK2019 in go_validator_generator.cc > > > Key: THRIFT-5654 > URL: https://issues.apache.org/jira/browse/THRIFT-5654 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler > Environment: Visual Studio 2022 >Reporter: Jens Geyer >Priority: Critical > Attachments: > 0001-THRIFT-5654-LNK4042-and-LNK2019-in-go_validator_gene-1.patch > > > With VS2022 I get "warning LNK4042: object specified more than once; extras > ignored" in go_validator_generator.obj. > Also I had to comment out this to get rid of some fatal LNK2019: unresolved > external symbol: > //go_validator_generator(this).generate_struct_validator(f_types_, tstruct); > Extra info: > https://stackoverflow.com/questions/3695174/visual-studio-2010s-strange-warning-lnk4042 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5654) LNK4042 and LNK2019 in go_validator_generator.cc
[ https://issues.apache.org/jira/browse/THRIFT-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5654: --- Attachment: 0001-THRIFT-5654-LNK4042-and-LNK2019-in-go_validator_gene.patch > LNK4042 and LNK2019 in go_validator_generator.cc > > > Key: THRIFT-5654 > URL: https://issues.apache.org/jira/browse/THRIFT-5654 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler > Environment: Visual Studio 2022 >Reporter: Jens Geyer >Priority: Critical > Attachments: > 0001-THRIFT-5654-LNK4042-and-LNK2019-in-go_validator_gene.patch > > > With VS2022 I get "warning LNK4042: object specified more than once; extras > ignored" in go_validator_generator.obj. > Also I had to comment out this to get rid of some fatal LNK2019: unresolved > external symbol: > //go_validator_generator(this).generate_struct_validator(f_types_, tstruct); > Extra info: > https://stackoverflow.com/questions/3695174/visual-studio-2010s-strange-warning-lnk4042 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (THRIFT-5776) Cpp cross test fail
[
https://issues.apache.org/jira/browse/THRIFT-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856846#comment-17856846
]
Jens Geyer commented on THRIFT-5776:
Nitpick: *resolve* is fine, we usually *close* when we do the release.
> Cpp cross test fail
> ---
>
> Key: THRIFT-5776
> URL: https://issues.apache.org/jira/browse/THRIFT-5776
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Reporter: Volodymyr Panivko
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When running cross test in docker I'm getting an error
> {code:java}
> ibs/ThriftTest_extras.o
> Benchmark.cpp: In function 'int main()':
> Benchmark.cpp:69:7: error: 'class thrift::test::debug::OneOfEach' has no
> member named 'rfc4122_uuid'
> 69 | ooe.rfc4122_uuid = "{5e2ab188-1726-4e75-a04f-1ed9a6a89c4c}";
> | ^~~~
> make[5]: *** [Makefile:1408: Benchmark.o] Error 1
> {code}
> if i comment 69 line in Benchmark.cpp this error doe not appear but i'm
> getting a new one THRIFT-5775
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (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 resolved THRIFT-5773. Fix Version/s: 0.21.0 Assignee: Carel Resolution: Fixed Thanks! > UUID wrapper for C++ > > > Key: THRIFT-5773 > URL: https://issues.apache.org/jira/browse/THRIFT-5773 > Project: Thrift > Issue Type: New Feature >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] [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=17853577#comment-17853577 ] Jens Geyer commented on THRIFT-5773: Not sure what "consider" means ... if it gets merged it is in the release. I'm not primarily a cpp guy myself. > UUID wrapper for C++ > > > Key: THRIFT-5773 > URL: https://issues.apache.org/jira/browse/THRIFT-5773 > Project: Thrift > Issue Type: New Feature >Reporter: Carel >Priority: Major > Time Spent: 50m > 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] [Commented] (THRIFT-5791) Inconsistent behavior: Go does not use default values
[ https://issues.apache.org/jira/browse/THRIFT-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851787#comment-17851787 ] Jens Geyer commented on THRIFT-5791: Who is that "we" you are talking about? > Inconsistent behavior: Go does not use default values > - > > Key: THRIFT-5791 > URL: https://issues.apache.org/jira/browse/THRIFT-5791 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler, Go - Library >Affects Versions: 0.19.0, 0.20.0 >Reporter: Team_RPCtester >Priority: Major > Attachments: image-2024-06-02-20-15-37-106.png, > image-2024-06-02-20-15-55-606.png, image-2024-06-02-20-16-08-144.png, > temp_thrift.zip > > > Hi, > We are software engineering researchers working on automated program analysis > techniques to improve the reliability of RPC frameworks. > > We discover a bug illustrated by the following example (The attached script > can help you reproduce the issue). > When using a .thrift file to define a struct, if one of the fields is > optional and has a default i8 value (e.g., 73), there is an inconsistent > behavior in implementations across different languages. Specifically: > # In the Go implementation, if the field is not explicitly defined or > assigned a value, the transmitted value is 0. > # In the Python and Node.js implementations, if the field is not explicitly > defined or assigned a value, the transmitted value is the default value of 73. > This inconsistency indicates that there might be an issue with the Go > implementation. > In our setting, we use Go, Node.js, and Python 3 as the server side, and use > Go, Node.js, and Python 3, as the client side. The thrift file we use is > shown in the flowing picture: > !image-2024-06-02-20-15-37-106.png! > When calling Method_3, the message passed is an instance of StructClass_0, > where f_4 is not set. The f_4 is automatically defined as 0, while in Python > 3 and Node.js, f_4 is 73. > The result is shown as bellow: > !image-2024-06-02-20-15-55-606.png! > go-py3_json_buffered-ip_client.log > !image-2024-06-02-20-16-08-144.png! > go-go_json_buffered-ip_client.log > The attachments provided are essential for reproducing the issue. By > following the commands outlined in the accompanying readme.md, you will be > able to replicate the problem accurately. > > *This is our first submission. If you have any preferred methods, please feel > free to let us know. Thank you.* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (THRIFT-5785) TTransportException.h includes 'boost/numeric/conversion/cast.hpp' without target depending on Boost
[
https://issues.apache.org/jira/browse/THRIFT-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850161#comment-17850161
]
Jens Geyer edited comment on THRIFT-5785 at 5/28/24 8:02 PM:
-
Would it be possible for you to provide a pull request and/or patch?
was (Author: jensg):
Would it be possible to provide a pull request and/or patch?
> TTransportException.h includes 'boost/numeric/conversion/cast.hpp' without
> target depending on Boost
>
>
> Key: THRIFT-5785
> URL: https://issues.apache.org/jira/browse/THRIFT-5785
> Project: Thrift
> Issue Type: Bug
>Affects Versions: 0.20.0
> Environment: * macOS 14 (Sonoma)
> * Host is x86_64, cross-compiling universal binaries for x86_64+aarch64
> * CMake 3.29, dependencies managed through conventional use of find_package()
> * AppleClang 15.0.0.15000100
> * Compiling with -std=gnu++20
> * Boost 1.81 (from MacPorts)
> * Apache Thrift 0.20 (from MacPorts, recently upgraded)
>Reporter: Petr Mánek
>Priority: Major
>
> Hello, ever since upgrading from version 0.19 to 0.20, I am seeing a new
> error when compiling my Thrift-based software:
> {code:java}
> In file included from /redacted/RemoteControl.cpp:7:
> In file included from /redacted/RemoteControl.h:10:
> In file included from
> /opt/local/lib/../include/thrift/TDispatchProcessor.h:22:
> In file included from /opt/local/lib/../include/thrift/TProcessor.h:24:
> In file included from
> /opt/local/lib/../include/thrift/protocol/TProtocol.h:46:
> In file included from
> /opt/local/lib/../include/thrift/transport/TTransport.h:25:
> /opt/local/lib/../include/thrift/transport/TTransportException.h:23:10: fatal
> error: 'boost/numeric/conversion/cast.hpp' file not found
> #include {code}
> I have confirmed that 'cast.hpp' is correctly installed in my system, but for
> some reason CMake does not add its include path to compiler invocation, so
> the file is not seen during compilation. Furthermore, based on synthesized
> compiler flags it seems that Thrift's CMake package does not declare public
> dependency on boost::numeric, but nonetheless includes it in public headers.
> This may be related to THRIFT-5660.
> For now I mitigate this issue by making my CMake target explicitly depend on
> Apache Thrift as well as boost::numeric. However, since I do not directly use
> Boost whereas Thrift does, I should not have to do that. Instead, it seems
> much more cleaner to me if Thrift publicly depended on boost::numeric or
> removed the offending #include directive from its public headers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (THRIFT-5785) TTransportException.h includes 'boost/numeric/conversion/cast.hpp' without target depending on Boost
[
https://issues.apache.org/jira/browse/THRIFT-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850161#comment-17850161
]
Jens Geyer commented on THRIFT-5785:
Would it be possible to provide a pull request and/or patch?
> TTransportException.h includes 'boost/numeric/conversion/cast.hpp' without
> target depending on Boost
>
>
> Key: THRIFT-5785
> URL: https://issues.apache.org/jira/browse/THRIFT-5785
> Project: Thrift
> Issue Type: Bug
>Affects Versions: 0.20.0
> Environment: * macOS 14 (Sonoma)
> * Host is x86_64, cross-compiling universal binaries for x86_64+aarch64
> * CMake 3.29, dependencies managed through conventional use of find_package()
> * AppleClang 15.0.0.15000100
> * Compiling with -std=gnu++20
> * Boost 1.81 (from MacPorts)
> * Apache Thrift 0.20 (from MacPorts, recently upgraded)
>Reporter: Petr Mánek
>Priority: Major
>
> Hello, ever since upgrading from version 0.19 to 0.20, I am seeing a new
> error when compiling my Thrift-based software:
> {code:java}
> In file included from /redacted/RemoteControl.cpp:7:
> In file included from /redacted/RemoteControl.h:10:
> In file included from
> /opt/local/lib/../include/thrift/TDispatchProcessor.h:22:
> In file included from /opt/local/lib/../include/thrift/TProcessor.h:24:
> In file included from
> /opt/local/lib/../include/thrift/protocol/TProtocol.h:46:
> In file included from
> /opt/local/lib/../include/thrift/transport/TTransport.h:25:
> /opt/local/lib/../include/thrift/transport/TTransportException.h:23:10: fatal
> error: 'boost/numeric/conversion/cast.hpp' file not found
> #include {code}
> I have confirmed that 'cast.hpp' is correctly installed in my system, but for
> some reason CMake does not add its include path to compiler invocation, so
> the file is not seen during compilation. Furthermore, based on synthesized
> compiler flags it seems that Thrift's CMake package does not declare public
> dependency on boost::numeric, but nonetheless includes it in public headers.
> This may be related to THRIFT-5660.
> For now I mitigate this issue by making my CMake target explicitly depend on
> Apache Thrift as well as boost::numeric. However, since I do not directly use
> Boost whereas Thrift does, I should not have to do that. Instead, it seems
> much more cleaner to me if Thrift publicly depended on boost::numeric or
> removed the offending #include directive from its public headers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (THRIFT-5788) Refactor and streamline hash set implementation
[ https://issues.apache.org/jira/browse/THRIFT-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5788: --- Attachment: 0002-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch > Refactor and streamline hash set implementation > --- > > Key: THRIFT-5788 > URL: https://issues.apache.org/jira/browse/THRIFT-5788 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Labels: breaking > Fix For: 0.21.0 > > Attachments: > 0001-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch, > 0002-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch > > > Compared to list and map, the set implementation in TThriftHashSet > has a few quirks, both w/regard to the inconsistent public interface as well > as the overly complicated internal implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-5789) Refactor test suite client implementation
[ https://issues.apache.org/jira/browse/THRIFT-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5789. Fix Version/s: 0.21.0 Resolution: Fixed > Refactor test suite client implementation > - > > Key: THRIFT-5789 > URL: https://issues.apache.org/jira/browse/THRIFT-5789 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Compiler >Reporter: Jens Geyer >Priority: Major > Fix For: 0.21.0 > > Attachments: > 0002-THRIFT-5789-Refactor-test-suite-client-implementatio.patch > > > The Delphi test suite client implementation deserves some long overdue > refactoring. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-5788) Refactor and streamline hash set implementation
[ https://issues.apache.org/jira/browse/THRIFT-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5788. Fix Version/s: 0.21.0 Resolution: Fixed > Refactor and streamline hash set implementation > --- > > Key: THRIFT-5788 > URL: https://issues.apache.org/jira/browse/THRIFT-5788 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Labels: breaking > Fix For: 0.21.0 > > Attachments: > 0001-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch > > > Compared to list and map, the set implementation in TThriftHashSet > has a few quirks, both w/regard to the inconsistent public interface as well > as the overly complicated internal implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5788) Refactor and streamline hash set implementation
[ https://issues.apache.org/jira/browse/THRIFT-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5788: --- Attachment: 0001-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch > Refactor and streamline hash set implementation > --- > > Key: THRIFT-5788 > URL: https://issues.apache.org/jira/browse/THRIFT-5788 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Labels: breaking > Attachments: > 0001-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch > > > Compared to list and map, the set implementation in TThriftHashSet > has a few quirks, both w/regard to the inconsistent public interface as well > as the overly complicated internal implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5789) Refactor test suite client implementation
[ https://issues.apache.org/jira/browse/THRIFT-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5789: --- Attachment: 0002-THRIFT-5789-Refactor-test-suite-client-implementatio.patch > Refactor test suite client implementation > - > > Key: THRIFT-5789 > URL: https://issues.apache.org/jira/browse/THRIFT-5789 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Compiler >Reporter: Jens Geyer >Priority: Major > Attachments: > 0002-THRIFT-5789-Refactor-test-suite-client-implementatio.patch > > > The Delphi test suite client implementation deserves some long overdue > refactoring. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (THRIFT-5788) Refactor and streamline hash set implementation
[ https://issues.apache.org/jira/browse/THRIFT-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849405#comment-17849405 ] Jens Geyer commented on THRIFT-5788: Potentially breaking changes: * IsReadOnly never became TRUE, was not fully implemented at all and inconsistent with other/usual containers => completely removed * CopyTo() is error prone and also inconsistent with other/usual containers => completely removed > Refactor and streamline hash set implementation > --- > > Key: THRIFT-5788 > URL: https://issues.apache.org/jira/browse/THRIFT-5788 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Labels: breaking > Attachments: > 0001-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch > > > Compared to list and map, the set implementation in TThriftHashSet > has a few quirks, both w/regard to the inconsistent public interface as well > as the overly complicated internal implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5788) Refactor and streamline hash set implementation
[ https://issues.apache.org/jira/browse/THRIFT-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5788: --- Attachment: (was: 0001-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch) > Refactor and streamline hash set implementation > --- > > Key: THRIFT-5788 > URL: https://issues.apache.org/jira/browse/THRIFT-5788 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Labels: breaking > Attachments: > 0001-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch > > > Compared to list and map, the set implementation in TThriftHashSet > has a few quirks, both w/regard to the inconsistent public interface as well > as the overly complicated internal implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5788) Refactor and streamline hash set implementation
[ https://issues.apache.org/jira/browse/THRIFT-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5788: --- Attachment: 0001-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch > Refactor and streamline hash set implementation > --- > > Key: THRIFT-5788 > URL: https://issues.apache.org/jira/browse/THRIFT-5788 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Attachments: > 0001-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch > > > Compared to list and map, the set implementation in TThriftHashSet > has a few quirks, both w/regard to the inconsistent public interface as well > as the overly complicated internal implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5788) Refactor and streamline hash set implementation
[ https://issues.apache.org/jira/browse/THRIFT-5788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5788: --- Labels: breaking (was: ) > Refactor and streamline hash set implementation > --- > > Key: THRIFT-5788 > URL: https://issues.apache.org/jira/browse/THRIFT-5788 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Library >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Labels: breaking > Attachments: > 0001-THRIFT-5788-Refactor-and-streamline-hash-set-impleme.patch > > > Compared to list and map, the set implementation in TThriftHashSet > has a few quirks, both w/regard to the inconsistent public interface as well > as the overly complicated internal implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5789) Refactor test suite client implementation
[ https://issues.apache.org/jira/browse/THRIFT-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5789: --- Description: The Delphi test suite client implementation deserves some long overdue refactoring. (was: The test suite client implementation deserves some long overdue refactoring.) > Refactor test suite client implementation > - > > Key: THRIFT-5789 > URL: https://issues.apache.org/jira/browse/THRIFT-5789 > Project: Thrift > Issue Type: Improvement > Components: Delphi - Compiler >Reporter: Jens Geyer >Priority: Major > > The Delphi test suite client implementation deserves some long overdue > refactoring. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5789) Refactor test suite client implementation
Jens Geyer created THRIFT-5789: -- Summary: Refactor test suite client implementation Key: THRIFT-5789 URL: https://issues.apache.org/jira/browse/THRIFT-5789 Project: Thrift Issue Type: Improvement Components: Delphi - Compiler Reporter: Jens Geyer The test suite client implementation deserves some long overdue refactoring. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (THRIFT-5788) Refactor and streamline hash set implementation
Jens Geyer created THRIFT-5788: -- Summary: Refactor and streamline hash set implementation Key: THRIFT-5788 URL: https://issues.apache.org/jira/browse/THRIFT-5788 Project: Thrift Issue Type: Improvement Components: Delphi - Library Reporter: Jens Geyer Assignee: Jens Geyer Compared to list and map, the set implementation in TThriftHashSet has a few quirks, both w/regard to the inconsistent public interface as well as the overly complicated internal implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (THRIFT-5787) .NET ApacheThrift client v20.0 breaks compatibility in TBinaryProtocol.Factory constructor
[ https://issues.apache.org/jira/browse/THRIFT-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5787. Fix Version/s: 0.21.0 Resolution: Fixed Thanks! > .NET ApacheThrift client v20.0 breaks compatibility in > TBinaryProtocol.Factory constructor > -- > > Key: THRIFT-5787 > URL: https://issues.apache.org/jira/browse/THRIFT-5787 > Project: Thrift > Issue Type: Bug > Components: netstd - Library >Affects Versions: 0.20.0 >Reporter: Steven Mitcham >Assignee: Steven Mitcham >Priority: Minor > Fix For: 0.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > A switch to using default parameters in the factory function has created a > binary incompatibilty that crashses clients migrating from versions <= v19.0. > Even though it is source compatible, updating the nuget package inline as a > depedency will cause a missing method exception because the factory now has > two parameters. > > [thrift/lib/netstd/Thrift/Protocol/TBinaryProtocol.cs at master - > apache/thrift > (github.com)|https://github.com/apache/thrift/blob/master/lib/netstd/Thrift/Protocol/TBinaryProtocol.cs#L478] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (THRIFT-5787) .NET ApacheThrift client v20.0 breaks compatibility in TBinaryProtocol.Factory constructor
[ https://issues.apache.org/jira/browse/THRIFT-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer reassigned THRIFT-5787: -- Assignee: Steven Mitcham > .NET ApacheThrift client v20.0 breaks compatibility in > TBinaryProtocol.Factory constructor > -- > > Key: THRIFT-5787 > URL: https://issues.apache.org/jira/browse/THRIFT-5787 > Project: Thrift > Issue Type: Bug > Components: netstd - Library >Affects Versions: 0.20.0 >Reporter: Steven Mitcham >Assignee: Steven Mitcham >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > A switch to using default parameters in the factory function has created a > binary incompatibilty that crashses clients migrating from versions <= v19.0. > Even though it is source compatible, updating the nuget package inline as a > depedency will cause a missing method exception because the factory now has > two parameters. > > [thrift/lib/netstd/Thrift/Protocol/TBinaryProtocol.cs at master - > apache/thrift > (github.com)|https://github.com/apache/thrift/blob/master/lib/netstd/Thrift/Protocol/TBinaryProtocol.cs#L478] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5781) implement full deprecation support
[ https://issues.apache.org/jira/browse/THRIFT-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5781: --- Attachment: 0001-THRIFT-5781-implement-full-deprecation-support-fix-u.patch > implement full deprecation support > -- > > Key: THRIFT-5781 > URL: https://issues.apache.org/jira/browse/THRIFT-5781 > Project: Thrift > Issue Type: Improvement > Components: netstd - Compiler >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Minor > Fix For: 0.21.0 > > Attachments: > 0001-THRIFT-5781-implement-full-deprecation-support-fix-u.patch, > deprecated.thrift > > Time Spent: 20m > Remaining Estimate: 0h > > Currently netstd only checks service methods for deprecation markers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (THRIFT-5782) implement full deprecation support
[ https://issues.apache.org/jira/browse/THRIFT-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-5782: --- Attachment: 0001-THRIFT-5782-implement-full-deprecation-support.patch > implement full deprecation support > -- > > Key: THRIFT-5782 > URL: https://issues.apache.org/jira/browse/THRIFT-5782 > Project: Thrift > Issue Type: Sub-task > Components: Delphi - Compiler >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Minor > Fix For: 0.21.0 > > Attachments: 0001-THRIFT-5782-implement-full-deprecation-support.patch > > Time Spent: 20m > Remaining Estimate: 0h > > same as THRIFT-5781 for delphi (at least as much as possible :() -- This message was sent by Atlassian Jira (v8.20.10#820010)
