[jira] [Commented] (THRIFT-4423) migrate php library to psr-4
[ https://issues.apache.org/jira/browse/THRIFT-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321706#comment-16321706 ] ASF GitHub Bot commented on THRIFT-4423: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1445 I'll watch for a passing build, and then merge tomorrow if it's good. > migrate php library to psr-4 > > > Key: THRIFT-4423 > URL: https://issues.apache.org/jira/browse/THRIFT-4423 > Project: Thrift > Issue Type: Improvement > Components: PHP - Library >Affects Versions: 0.11.0 >Reporter: Robert Lu > > The latest autoload standard is [http://www.php-fig.org/psr/psr-4/]. > So, I migrate thrift to PSR-4. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1445: THRIFT-4423 migrate to psr-4
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1445 I'll watch for a passing build, and then merge tomorrow if it's good. ---
Planning to close all 2014 and 2015 pull requests
Tomorrow I plan on adding a comment to each of these pull requests and closing them by submitting an empty commit with github directives into the trunk. We're going to start getting more aggressive with maintaining the pull request backlog. Things cannot sit for 3 or 4 years. For items submitted in 2016 we're going to ask authors to refresh and get them passing, or we are going to close them out over the next couple months. We need to get the open PR list down to 10 or less. - Jim
[jira] [Resolved] (THRIFT-4399) plugin.thrift t_const_value is not used as a union in C++ code -- fix this
[ https://issues.apache.org/jira/browse/THRIFT-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4399. Resolution: Fixed Fix Version/s: 0.12.0 Committed - thanks! > plugin.thrift t_const_value is not used as a union in C++ code -- fix this > -- > > Key: THRIFT-4399 > URL: https://issues.apache.org/jira/browse/THRIFT-4399 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Affects Versions: 0.10.0 > Environment: Ubuntu 16.04 amd64 >Reporter: Chet Murthy >Assignee: James E. King, III >Priority: Minor > Fix For: 0.12.0 > > > plugin.thrift defines t_const_value as a union. But in plugin_output.cc and > plugin.cc, the converters clearly either (a) SET NEITHER of identifier_val & > enum_val, or (b) SET BOTH. But these are two different fields in the union. > So clearly, the type t_const_value isn't being treated as a union. > I think we need to fix Thrift's treatment of unions, but independently, the > plugin should use Thrift's type system in a correct manner. This is > easy-to-fix, but since the current plugin relies on a bug, the fix will be a > breaking change. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4399) plugin.thrift t_const_value is not used as a union in C++ code -- fix this
[ https://issues.apache.org/jira/browse/THRIFT-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321698#comment-16321698 ] ASF GitHub Bot commented on THRIFT-4399: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1435 > plugin.thrift t_const_value is not used as a union in C++ code -- fix this > -- > > Key: THRIFT-4399 > URL: https://issues.apache.org/jira/browse/THRIFT-4399 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Affects Versions: 0.10.0 > Environment: Ubuntu 16.04 amd64 >Reporter: Chet Murthy >Assignee: James E. King, III >Priority: Minor > Fix For: 0.12.0 > > > plugin.thrift defines t_const_value as a union. But in plugin_output.cc and > plugin.cc, the converters clearly either (a) SET NEITHER of identifier_val & > enum_val, or (b) SET BOTH. But these are two different fields in the union. > So clearly, the type t_const_value isn't being treated as a union. > I think we need to fix Thrift's treatment of unions, but independently, the > plugin should use Thrift's type system in a correct manner. This is > easy-to-fix, but since the current plugin relies on a bug, the fix will be a > breaking change. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift pull request #1435: THRIFT-4399 plugin.thrift t_const_value is not us...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1435 ---
[jira] [Assigned] (THRIFT-4399) plugin.thrift t_const_value is not used as a union in C++ code -- fix this
[ https://issues.apache.org/jira/browse/THRIFT-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-4399: -- Assignee: James E. King, III > plugin.thrift t_const_value is not used as a union in C++ code -- fix this > -- > > Key: THRIFT-4399 > URL: https://issues.apache.org/jira/browse/THRIFT-4399 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Affects Versions: 0.10.0 > Environment: Ubuntu 16.04 amd64 >Reporter: Chet Murthy >Assignee: James E. King, III >Priority: Minor > > plugin.thrift defines t_const_value as a union. But in plugin_output.cc and > plugin.cc, the converters clearly either (a) SET NEITHER of identifier_val & > enum_val, or (b) SET BOTH. But these are two different fields in the union. > So clearly, the type t_const_value isn't being treated as a union. > I think we need to fix Thrift's treatment of unions, but independently, the > plugin should use Thrift's type system in a correct manner. This is > easy-to-fix, but since the current plugin relies on a bug, the fix will be a > breaking change. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (THRIFT-4393) repeated runs of compiler produce different binary output at plugin interface
[ https://issues.apache.org/jira/browse/THRIFT-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4393. Resolution: Fixed Fix Version/s: 0.12.0 Committed - thanks! > repeated runs of compiler produce different binary output at plugin interface > - > > Key: THRIFT-4393 > URL: https://issues.apache.org/jira/browse/THRIFT-4393 > Project: Thrift > Issue Type: Improvement > Components: Compiler (General) >Affects Versions: 0.10.0 > Environment: Ubuntu 16.04, Linux amd64, but generally applicable >Reporter: Chet Murthy >Assignee: James E. King, III >Priority: Trivial > Fix For: 0.12.0 > > > TL;DR the plugin interface produces serialized thrift objects containing > integers derived from addresses; this results in repeated runs producing > differing output, and that's unpleasant. This is easy to test and easy to > fix. > Longer: The plugin interface is really nice, and I'd like to use it for more > things. One problem with it, is that from run-to-run, the data given to the > plugin can and does change, b/c there are "ids" (e.g. "t_type_id") that are > derived from pointer-addresses inside the compiler. It'd be nice to replace > those with generated integers starting at a fixed base. In short, instead of > random integers scattered thru the plugin, we'd get (say) numbers starting at > 100 and consecutively increasing. Each different kind of ID would start > at that same base, and the assignment would be based on how the "converter" > from internal types to thrift types walked the data-structure. Which should > be deterministic. So that would give a determinsitic output to the plugin. > This is *easy* to unit-test: just use /bin/cat as a plugin and compare > subsequent runs. > I'll write a unit-test and then a patch. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift pull request #1419: Thrift 4393 plugin renumber for stable output acr...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1419 ---
[jira] [Assigned] (THRIFT-4393) repeated runs of compiler produce different binary output at plugin interface
[ https://issues.apache.org/jira/browse/THRIFT-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-4393: -- Assignee: James E. King, III > repeated runs of compiler produce different binary output at plugin interface > - > > Key: THRIFT-4393 > URL: https://issues.apache.org/jira/browse/THRIFT-4393 > Project: Thrift > Issue Type: Improvement > Components: Compiler (General) >Affects Versions: 0.10.0 > Environment: Ubuntu 16.04, Linux amd64, but generally applicable >Reporter: Chet Murthy >Assignee: James E. King, III >Priority: Trivial > > TL;DR the plugin interface produces serialized thrift objects containing > integers derived from addresses; this results in repeated runs producing > differing output, and that's unpleasant. This is easy to test and easy to > fix. > Longer: The plugin interface is really nice, and I'd like to use it for more > things. One problem with it, is that from run-to-run, the data given to the > plugin can and does change, b/c there are "ids" (e.g. "t_type_id") that are > derived from pointer-addresses inside the compiler. It'd be nice to replace > those with generated integers starting at a fixed base. In short, instead of > random integers scattered thru the plugin, we'd get (say) numbers starting at > 100 and consecutively increasing. Each different kind of ID would start > at that same base, and the assignment would be based on how the "converter" > from internal types to thrift types walked the data-structure. Which should > be deterministic. So that would give a determinsitic output to the plugin. > This is *easy* to unit-test: just use /bin/cat as a plugin and compare > subsequent runs. > I'll write a unit-test and then a patch. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift pull request #1418: Thrift 3877 http server buffering bug oneway
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1418 ---
[GitHub] thrift issue #1418: Thrift 3877 http server buffering bug oneway
Github user chetmurthy commented on the issue: https://github.com/apache/thrift/pull/1418 This patch only flxes cpp-cpp (http) failures. B/c the deeper issue is that the Thrift cpp stack (both client & server) is nonstandard. I think I mentioned that I could improve this a bit, by having the client not wait for the reply from the server, but the server would eventually deliver it anyway. The client would keep track of of how many replies it had ignored, and when it came time to actually want to see a reply, it woud skip past the requisite # of ignored replies. Also (of course), you'd want to only ignore replies up to some limit -- or you could deadlock. Not very hard to do, actually. And this would also fix cpp(client)-http-(server) tests. BUT it would NOT fix (client)-http(server) tests, b/c (from what I remember of my little stroll thru code) (almost?) all the other languages' HTTP stacks assume an RPC model for how applications will use the client HTTP stack. So they're written with "send request, immediately turn around and wait for response" as the model. Hope this helps. ---
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16321585#comment-16321585 ] ASF GitHub Bot commented on THRIFT-3877: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1418 I'm not certain this resolves THRIFT-3877 entirely - your take? > 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 > > 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 (v6.4.14#64029)
[GitHub] thrift issue #1418: Thrift 3877 http server buffering bug oneway
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1418 I'm not certain this resolves THRIFT-3877 entirely - your take? ---
[GitHub] thrift issue #1418: Thrift 3877 http server buffering bug oneway
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1418 Pulling this into a sandbox to see if it fixes any of the `cpp*http` known test failures. ---
[jira] [Commented] (THRIFT-4448) Golang: do something with context.Context
[
https://issues.apache.org/jira/browse/THRIFT-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321581#comment-16321581
]
ASF GitHub Bot commented on THRIFT-4448:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1459
Ugh, so it turns out Ubuntu Xenial comes with go 1.6 which is pretty much
the version we use on all of our CI builds for testing (like cross test).
For further details on the issue see:
https://github.com/golang/mock/pull/118
Now I have to think some more about it. :|
> Golang: do something with context.Context
> -
>
> Key: THRIFT-4448
> URL: https://issues.apache.org/jira/browse/THRIFT-4448
> Project: Thrift
> Issue Type: Task
> Components: Go - Library
>Affects Versions: 0.11.0
>Reporter: John Boiles
>
> PR Here: https://github.com/apache/thrift/pull/1459
> This patch wires through {{context.Context}} such that it can be used in in
> {{http.Request}}'s {{WithContext}} method. This allows Thrift HTTP requests
> to canceled or timed out via the context.
> This patch breaks support for go<1.7 so it's not ready to ship, but I'm
> hoping to get some direction on this. When does Thrift expect to drop support
> of go1.7? It looks like the current solution is to duplicate files that need
> to use {{golang.org/x/net/context}} and add a {{// +build !go1.7}} but
> duplication seems unsustainable as the {{context}} package is imported more
> places.
> Go 1.7 was released 15 August 2016. Given Golang has had significant
> performance improvements in most dot releases, I suspect most production
> services stay reasonably up to date. Here at Periscope/Twitter we're on
> go1.9.1, and we're a fairly large organization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1459: THRIFT-4448: Golang: do something with context.Context
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1459 Ugh, so it turns out Ubuntu Xenial comes with go 1.6 which is pretty much the version we use on all of our CI builds for testing (like cross test). For further details on the issue see: https://github.com/golang/mock/pull/118 Now I have to think some more about it. :| ---
[jira] [Resolved] (THRIFT-4443) node.js json_protocol throws error in skip function
[
https://issues.apache.org/jira/browse/THRIFT-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-4443.
Resolution: Fixed
Committed - thanks!
> node.js json_protocol throws error in skip function
> ---
>
> Key: THRIFT-4443
> URL: https://issues.apache.org/jira/browse/THRIFT-4443
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.11.0
>Reporter: Kerri Devine
>Assignee: James E. King, III
> Labels: easyfix, patch
> Fix For: 0.12.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> The skip function is unsupported in the node.js implementation of the
> json_protocol. Interestingly, the compact_protocol implements the skip
> function, as does the JavaScript version.
> {code:javascript}
> TJSONProtocol.prototype.skip = function(type) {
> throw new Error('skip not supported yet');
> };
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift pull request #1460: THRIFT-4443: Implement skip function in json_prot...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1460 ---
[jira] [Commented] (THRIFT-4443) node.js json_protocol throws error in skip function
[
https://issues.apache.org/jira/browse/THRIFT-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321578#comment-16321578
]
ASF GitHub Bot commented on THRIFT-4443:
Github user asfgit closed the pull request at:
https://github.com/apache/thrift/pull/1460
> node.js json_protocol throws error in skip function
> ---
>
> Key: THRIFT-4443
> URL: https://issues.apache.org/jira/browse/THRIFT-4443
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.11.0
>Reporter: Kerri Devine
>Assignee: James E. King, III
> Labels: easyfix, patch
> Fix For: 0.12.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> The skip function is unsupported in the node.js implementation of the
> json_protocol. Interestingly, the compact_protocol implements the skip
> function, as does the JavaScript version.
> {code:javascript}
> TJSONProtocol.prototype.skip = function(type) {
> throw new Error('skip not supported yet');
> };
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (THRIFT-4443) node.js json_protocol throws error in skip function
[
https://issues.apache.org/jira/browse/THRIFT-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III reassigned THRIFT-4443:
--
Assignee: James E. King, III
> node.js json_protocol throws error in skip function
> ---
>
> Key: THRIFT-4443
> URL: https://issues.apache.org/jira/browse/THRIFT-4443
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.11.0
>Reporter: Kerri Devine
>Assignee: James E. King, III
> Labels: easyfix, patch
> Fix For: 0.12.0
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> The skip function is unsupported in the node.js implementation of the
> json_protocol. Interestingly, the compact_protocol implements the skip
> function, as does the JavaScript version.
> {code:javascript}
> TJSONProtocol.prototype.skip = function(type) {
> throw new Error('skip not supported yet');
> };
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-4447) Golang: Panic on p.c.Call when using deprecated initializers
[
https://issues.apache.org/jira/browse/THRIFT-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321571#comment-16321571
]
ASF GitHub Bot commented on THRIFT-4447:
Github user asfgit closed the pull request at:
https://github.com/apache/thrift/pull/1461
> Golang: Panic on p.c.Call when using deprecated initializers
>
>
> Key: THRIFT-4447
> URL: https://issues.apache.org/jira/browse/THRIFT-4447
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.11.0
>Reporter: John Boiles
>Assignee: James E. King, III
> Fix For: 0.12.0
>
>
> Latest thrift:master can cause panics when using deprecated
> `New*ClientFactory` and `New*ClientProtocol` functions. This happens because
> both the Client and the BaseClient have an instance of a {{thrift.TClient}}.
> The deprecated methods initialize the BaseClient's TClient, but other methods
> use the Client's {{TClient}}.
> For example, current thrift master generates structs like this
> {code}
> type MyServiceClient struct {
> c thrift.TClient
> *MyServiceBaseClient
> }
> type MyServiceBaseClient struct {
> c thrift.TClient
> }
> {code}
> And also a method like this:
> {code}
> func NewMyServiceClientFactory(t thrift.TTransport, f
> thrift.TProtocolFactory) *MyServiceClient {
> return &MyServiceClient{MyServiceBaseClient:
> NewMyServiceBaseClientFactory(t, f)}
> }
> {code}
> If that method is used, later calls to service methods will panic, since
> {{p.c}} is nil (the actual client was stored in {{p.BaseMyServiceClient.c}}).
> {code}
> func (p *MyServiceClient) DoStuff(ctx context.Context, request
> *DoStuffRequest) (r *DoStuffResponse, err error) {
> var _args139 DoStuffArgs
> _args139.Request = request
> var _result140 DoStuffResult
> if err = p.c.Call(ctx, "do_stuff", &_args139, &_result140); err != nil
> { // PANIC
> ...
> {code}
> In progress fix here :https://github.com/apache/thrift/pull/1461. The fix in
> this PR merely sets both instances of {{TClient}} (which is what happens in
> the non-deprecated {{New*Client}} function).
> This patch currently fails {{make -k check}} however, since
> {{src/tutorial/tutorial.go}} tries to access a different package's version of
> the BaseClient.
> {code}
> src/tutorial/tutorial.go:477:33: bc.c undefined (cannot refer to unexported
> field or method c)
> {code}
> The fix for that test could possibly be to expose the BaseClient's instance
> of {{c}} (by making it a capital and thus exported {{C}}), or adding an
> accessor method {{C()}} or {{Client()}}.
> Possibly a better fix would be to either remove these deprecated methods, or
> figure out which {{TClient}} is the correct one to set.
> I'm not sure which is preferred, so I'm hoping to get some feedback/input
> here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift pull request #1461: THRIFT-4447: Golang: Fix panic on p.c.Call when u...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1461 ---
[jira] [Resolved] (THRIFT-4447) Golang: Panic on p.c.Call when using deprecated initializers
[
https://issues.apache.org/jira/browse/THRIFT-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-4447.
Resolution: Fixed
Fix Version/s: 0.12.0
Committed - thanks!
> Golang: Panic on p.c.Call when using deprecated initializers
>
>
> Key: THRIFT-4447
> URL: https://issues.apache.org/jira/browse/THRIFT-4447
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.11.0
>Reporter: John Boiles
>Assignee: James E. King, III
> Fix For: 0.12.0
>
>
> Latest thrift:master can cause panics when using deprecated
> `New*ClientFactory` and `New*ClientProtocol` functions. This happens because
> both the Client and the BaseClient have an instance of a {{thrift.TClient}}.
> The deprecated methods initialize the BaseClient's TClient, but other methods
> use the Client's {{TClient}}.
> For example, current thrift master generates structs like this
> {code}
> type MyServiceClient struct {
> c thrift.TClient
> *MyServiceBaseClient
> }
> type MyServiceBaseClient struct {
> c thrift.TClient
> }
> {code}
> And also a method like this:
> {code}
> func NewMyServiceClientFactory(t thrift.TTransport, f
> thrift.TProtocolFactory) *MyServiceClient {
> return &MyServiceClient{MyServiceBaseClient:
> NewMyServiceBaseClientFactory(t, f)}
> }
> {code}
> If that method is used, later calls to service methods will panic, since
> {{p.c}} is nil (the actual client was stored in {{p.BaseMyServiceClient.c}}).
> {code}
> func (p *MyServiceClient) DoStuff(ctx context.Context, request
> *DoStuffRequest) (r *DoStuffResponse, err error) {
> var _args139 DoStuffArgs
> _args139.Request = request
> var _result140 DoStuffResult
> if err = p.c.Call(ctx, "do_stuff", &_args139, &_result140); err != nil
> { // PANIC
> ...
> {code}
> In progress fix here :https://github.com/apache/thrift/pull/1461. The fix in
> this PR merely sets both instances of {{TClient}} (which is what happens in
> the non-deprecated {{New*Client}} function).
> This patch currently fails {{make -k check}} however, since
> {{src/tutorial/tutorial.go}} tries to access a different package's version of
> the BaseClient.
> {code}
> src/tutorial/tutorial.go:477:33: bc.c undefined (cannot refer to unexported
> field or method c)
> {code}
> The fix for that test could possibly be to expose the BaseClient's instance
> of {{c}} (by making it a capital and thus exported {{C}}), or adding an
> accessor method {{C()}} or {{Client()}}.
> Possibly a better fix would be to either remove these deprecated methods, or
> figure out which {{TClient}} is the correct one to set.
> I'm not sure which is preferred, so I'm hoping to get some feedback/input
> here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-4446) JSONProtocol Base64 Encoding Trims Padding
[ https://issues.apache.org/jira/browse/THRIFT-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321565#comment-16321565 ] ASF GitHub Bot commented on THRIFT-4446: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1463 > JSONProtocol Base64 Encoding Trims Padding > -- > > Key: THRIFT-4446 > URL: https://issues.apache.org/jira/browse/THRIFT-4446 > Project: Thrift > Issue Type: Bug > Components: .NETCore - Library, C# - Library >Affects Versions: 0.11.0 >Reporter: Allen >Assignee: James E. King, III > Fix For: 0.12.0 > > > In the C# and .NET Core libraries, the JSONProtocol's Binary Encoding to > Base64 trims padding from the user provided byte arrays before encoding into > Base64. This behavior is incorrect, as the user provided data should be > encoded exactly as provided. Otherwise, data may be lost. > Fixed by no longer trimming padding on encode. Padding must still be trimmed > on decode, in accordance with the Base64 specification. > For example: > * Before this patch, encoding the byte array [0x01, 0x3d, 0x3d] yields [0x01] > upon decode. This is incorrect, as I should decode the exact data that I > encoded. > * After this patch, it yields [0x01, 0x3d, 0x3d], as expected. > I have submitted a pull request > [here|https://github.com/apache/thrift/pull/1463] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (THRIFT-4447) Golang: Panic on p.c.Call when using deprecated initializers
[
https://issues.apache.org/jira/browse/THRIFT-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III reassigned THRIFT-4447:
--
Assignee: James E. King, III
> Golang: Panic on p.c.Call when using deprecated initializers
>
>
> Key: THRIFT-4447
> URL: https://issues.apache.org/jira/browse/THRIFT-4447
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.11.0
>Reporter: John Boiles
>Assignee: James E. King, III
>
> Latest thrift:master can cause panics when using deprecated
> `New*ClientFactory` and `New*ClientProtocol` functions. This happens because
> both the Client and the BaseClient have an instance of a {{thrift.TClient}}.
> The deprecated methods initialize the BaseClient's TClient, but other methods
> use the Client's {{TClient}}.
> For example, current thrift master generates structs like this
> {code}
> type MyServiceClient struct {
> c thrift.TClient
> *MyServiceBaseClient
> }
> type MyServiceBaseClient struct {
> c thrift.TClient
> }
> {code}
> And also a method like this:
> {code}
> func NewMyServiceClientFactory(t thrift.TTransport, f
> thrift.TProtocolFactory) *MyServiceClient {
> return &MyServiceClient{MyServiceBaseClient:
> NewMyServiceBaseClientFactory(t, f)}
> }
> {code}
> If that method is used, later calls to service methods will panic, since
> {{p.c}} is nil (the actual client was stored in {{p.BaseMyServiceClient.c}}).
> {code}
> func (p *MyServiceClient) DoStuff(ctx context.Context, request
> *DoStuffRequest) (r *DoStuffResponse, err error) {
> var _args139 DoStuffArgs
> _args139.Request = request
> var _result140 DoStuffResult
> if err = p.c.Call(ctx, "do_stuff", &_args139, &_result140); err != nil
> { // PANIC
> ...
> {code}
> In progress fix here :https://github.com/apache/thrift/pull/1461. The fix in
> this PR merely sets both instances of {{TClient}} (which is what happens in
> the non-deprecated {{New*Client}} function).
> This patch currently fails {{make -k check}} however, since
> {{src/tutorial/tutorial.go}} tries to access a different package's version of
> the BaseClient.
> {code}
> src/tutorial/tutorial.go:477:33: bc.c undefined (cannot refer to unexported
> field or method c)
> {code}
> The fix for that test could possibly be to expose the BaseClient's instance
> of {{c}} (by making it a capital and thus exported {{C}}), or adding an
> accessor method {{C()}} or {{Client()}}.
> Possibly a better fix would be to either remove these deprecated methods, or
> figure out which {{TClient}} is the correct one to set.
> I'm not sure which is preferred, so I'm hoping to get some feedback/input
> here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (THRIFT-4446) JSONProtocol Base64 Encoding Trims Padding
[ https://issues.apache.org/jira/browse/THRIFT-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4446. Resolution: Fixed Fix Version/s: 0.12.0 Committed - thanks! > JSONProtocol Base64 Encoding Trims Padding > -- > > Key: THRIFT-4446 > URL: https://issues.apache.org/jira/browse/THRIFT-4446 > Project: Thrift > Issue Type: Bug > Components: .NETCore - Library, C# - Library >Affects Versions: 0.11.0 >Reporter: Allen >Assignee: James E. King, III > Fix For: 0.12.0 > > > In the C# and .NET Core libraries, the JSONProtocol's Binary Encoding to > Base64 trims padding from the user provided byte arrays before encoding into > Base64. This behavior is incorrect, as the user provided data should be > encoded exactly as provided. Otherwise, data may be lost. > Fixed by no longer trimming padding on encode. Padding must still be trimmed > on decode, in accordance with the Base64 specification. > For example: > * Before this patch, encoding the byte array [0x01, 0x3d, 0x3d] yields [0x01] > upon decode. This is incorrect, as I should decode the exact data that I > encoded. > * After this patch, it yields [0x01, 0x3d, 0x3d], as expected. > I have submitted a pull request > [here|https://github.com/apache/thrift/pull/1463] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift pull request #1463: THRIFT-4446: JSONProtocol Base64 Encoding: Do not...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1463 ---
[jira] [Assigned] (THRIFT-4446) JSONProtocol Base64 Encoding Trims Padding
[ https://issues.apache.org/jira/browse/THRIFT-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-4446: -- Assignee: James E. King, III > JSONProtocol Base64 Encoding Trims Padding > -- > > Key: THRIFT-4446 > URL: https://issues.apache.org/jira/browse/THRIFT-4446 > Project: Thrift > Issue Type: Bug > Components: .NETCore - Library, C# - Library >Affects Versions: 0.11.0 >Reporter: Allen >Assignee: James E. King, III > > In the C# and .NET Core libraries, the JSONProtocol's Binary Encoding to > Base64 trims padding from the user provided byte arrays before encoding into > Base64. This behavior is incorrect, as the user provided data should be > encoded exactly as provided. Otherwise, data may be lost. > Fixed by no longer trimming padding on encode. Padding must still be trimmed > on decode, in accordance with the Base64 specification. > For example: > * Before this patch, encoding the byte array [0x01, 0x3d, 0x3d] yields [0x01] > upon decode. This is incorrect, as I should decode the exact data that I > encoded. > * After this patch, it yields [0x01, 0x3d, 0x3d], as expected. > I have submitted a pull request > [here|https://github.com/apache/thrift/pull/1463] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (THRIFT-4450) Add seek support to TCompactInputProtocol in Rust
[
https://issues.apache.org/jira/browse/THRIFT-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-4450.
Resolution: Fixed
Committed - thanks!
> Add seek support to TCompactInputProtocol in Rust
> -
>
> Key: THRIFT-4450
> URL: https://issues.apache.org/jira/browse/THRIFT-4450
> Project: Thrift
> Issue Type: Improvement
> Components: Ruby - Library
>Affects Versions: 0.11.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.12.0
>
>
> Per [~vchekan]:
> {quote}
> When Thrift is used in encoding which combine manual and Thrift
> serialization, such as Apache Parquet then it is required to be able to
> position within a file manually.
> https://github.com/apache/parquet-format#file-format
> As TCompactInputProtocol owns value of transport, it is not possible to
> access it outside of TCompactInputProtocol and perform seek operation.
> This patch implements Seek trait for transports which support it.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift pull request #1462: Add seek function to TCompactInputProtocol
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1462 ---
[jira] [Commented] (THRIFT-4450) Add seek support to TCompactInputProtocol in Rust
[
https://issues.apache.org/jira/browse/THRIFT-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321550#comment-16321550
]
ASF GitHub Bot commented on THRIFT-4450:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1462
I opened THRIFT-4450 in Apache Jira for this issue.
In the future please begin by opening a Jira ticket and then prepend the
ticket name to the title of your pull request so that they are connected. In
addition squashing future commits is helpful to committers.
https://thrift.apache.org/docs/HowToContribute
> Add seek support to TCompactInputProtocol in Rust
> -
>
> Key: THRIFT-4450
> URL: https://issues.apache.org/jira/browse/THRIFT-4450
> Project: Thrift
> Issue Type: Improvement
> Components: Ruby - Library
>Affects Versions: 0.11.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.12.0
>
>
> Per [~vchekan]:
> {quote}
> When Thrift is used in encoding which combine manual and Thrift
> serialization, such as Apache Parquet then it is required to be able to
> position within a file manually.
> https://github.com/apache/parquet-format#file-format
> As TCompactInputProtocol owns value of transport, it is not possible to
> access it outside of TCompactInputProtocol and perform seek operation.
> This patch implements Seek trait for transports which support it.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1462: Add seek function to TCompactInputProtocol
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1462 I opened THRIFT-4450 in Apache Jira for this issue. In the future please begin by opening a Jira ticket and then prepend the ticket name to the title of your pull request so that they are connected. In addition squashing future commits is helpful to committers. https://thrift.apache.org/docs/HowToContribute ---
[jira] [Created] (THRIFT-4450) Add seek support to TCompactInputProtocol in Rust
James E. King, III created THRIFT-4450:
--
Summary: Add seek support to TCompactInputProtocol in Rust
Key: THRIFT-4450
URL: https://issues.apache.org/jira/browse/THRIFT-4450
Project: Thrift
Issue Type: Improvement
Components: Ruby - Library
Affects Versions: 0.11.0
Reporter: James E. King, III
Assignee: James E. King, III
Priority: Minor
Fix For: 0.12.0
Per [~vchekan]:
{quote}
When Thrift is used in encoding which combine manual and Thrift serialization,
such as Apache Parquet then it is required to be able to position within a file
manually.
https://github.com/apache/parquet-format#file-format
As TCompactInputProtocol owns value of transport, it is not possible to access
it outside of TCompactInputProtocol and perform seek operation.
This patch implements Seek trait for transports which support it.
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-4448) Golang: do something with context.Context
[
https://issues.apache.org/jira/browse/THRIFT-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321531#comment-16321531
]
ASF GitHub Bot commented on THRIFT-4448:
Github user johnboiles commented on the issue:
https://github.com/apache/thrift/pull/1459
Sounds good want me to take a stab at dropping 1.6 support?
> Golang: do something with context.Context
> -
>
> Key: THRIFT-4448
> URL: https://issues.apache.org/jira/browse/THRIFT-4448
> Project: Thrift
> Issue Type: Task
> Components: Go - Library
>Affects Versions: 0.11.0
>Reporter: John Boiles
>
> PR Here: https://github.com/apache/thrift/pull/1459
> This patch wires through {{context.Context}} such that it can be used in in
> {{http.Request}}'s {{WithContext}} method. This allows Thrift HTTP requests
> to canceled or timed out via the context.
> This patch breaks support for go<1.7 so it's not ready to ship, but I'm
> hoping to get some direction on this. When does Thrift expect to drop support
> of go1.7? It looks like the current solution is to duplicate files that need
> to use {{golang.org/x/net/context}} and add a {{// +build !go1.7}} but
> duplication seems unsustainable as the {{context}} package is imported more
> places.
> Go 1.7 was released 15 August 2016. Given Golang has had significant
> performance improvements in most dot releases, I suspect most production
> services stay reasonably up to date. Here at Periscope/Twitter we're on
> go1.9.1, and we're a fairly large organization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1459: THRIFT-4448: Golang: do something with context.Context
Github user johnboiles commented on the issue: https://github.com/apache/thrift/pull/1459 Sounds good want me to take a stab at dropping 1.6 support? ---
[jira] [Commented] (THRIFT-4413) Publish a Maven artifact for Thrift v0.11
[ https://issues.apache.org/jira/browse/THRIFT-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321509#comment-16321509 ] Buğra Gedik commented on THRIFT-4413: - Thanks for keeping this alive. [~jfarrell]: Could we help with any of the problems that are preventing the publishing of artifacts? It would be good to create documentation on how the artifacts are published (both Java and Python, and potentially other languages that have similar artifacts, such as JS and PHP) so that more people can help with this? > Publish a Maven artifact for Thrift v0.11 > - > > Key: THRIFT-4413 > URL: https://issues.apache.org/jira/browse/THRIFT-4413 > Project: Thrift > Issue Type: Task > Components: Java - Library >Affects Versions: 0.11.0 >Reporter: Buğra Gedik >Assignee: Jake Farrell > Fix For: 0.11.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4449) C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if TNamedPipeServerTransport.Close is called too quickly
[
https://issues.apache.org/jira/browse/THRIFT-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
boxcppguy updated THRIFT-4449:
--
Description:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into stream.BeginWaitForConnection is never executed and evt.Set will
never get called. We saw this in 0.9.3 but it's suspected to be in 0.11.0 as
well.
{noformat}
// in server wrapper class MyServer
lock (this.serverLock)
{
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
}
{noformat}
{noformat}
// server wrapper class MyServer
public void Dispose()
{
this.Dispose(true);
}
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
was:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into stream.BeginWaitForConnection is never executed and evt.Set will
never get called. We saw this in 0.9.3 but it's suspected to be in 0.11.0 as
well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
public void Dispose()
{
this.Dispose(true);
}
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
> C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if
> TNamedPipeServerTransport.Close is called too quickly
> -
>
> Key: THRIFT-4449
> URL: https://issues.apache.org/jira/browse/THRIFT-4449
> Project: Thrift
> Issue Type: Bug
> Components: C# - Library
>Affects Versions: 0.9.3
> Environment: Windows 10.0.16299 64bit
>Reporter: boxcppguy
>
> What we observed is, when using the C# implementation
> TNamedPipeServerTransport along with TSimpleServer, if you call
> TSimpleServer.Stop too quickly after TSimpleServer.Serve, the call to
> evt.WaitOne in TNamedPipeServerTransport.AcceptImpl will block indefinitely
> because the lambda passed into stream.BeginWaitForConnection is never
> executed and evt.Set will never get called. We saw this in 0.9.3 but it's
> suspected to be in 0.11.0 as well.
> {noformat}
> // in server wrapper class MyServer
> lock (this.serverLock)
> {
> this.serverThread = new Thread(() =>
> {
> var processor = new MyProcessor();
> var transport = new TNamedPipeServerTransport("MyPipeName");
> var svr = new TSimpleServer(processor, transport);
> lock (this.serverLock)
> {
> this.server =
[jira] [Updated] (THRIFT-4449) C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if TNamedPipeServerTransport.Close is called too quickly
[
https://issues.apache.org/jira/browse/THRIFT-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
boxcppguy updated THRIFT-4449:
--
Description:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into stream.BeginWaitForConnection is never executed and evt.Set will
never get called. We saw this in 0.9.3 but it's suspected to be in 0.11.0 as
well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
public void Dispose()
{
this.Dispose(true);
}
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
was:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into stream.BeginWaitForConnection is never executed and evt.Set will
never get called. We saw this in 0.9.3 but it's suspected to be in 0.11.0 as
well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
> C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if
> TNamedPipeServerTransport.Close is called too quickly
> -
>
> Key: THRIFT-4449
> URL: https://issues.apache.org/jira/browse/THRIFT-4449
> Project: Thrift
> Issue Type: Bug
> Components: C# - Library
>Affects Versions: 0.9.3
> Environment: Windows 10.0.16299 64bit
>Reporter: boxcppguy
>
> What we observed is, when using the C# implementation
> TNamedPipeServerTransport along with TSimpleServer, if you call
> TSimpleServer.Stop too quickly after TSimpleServer.Serve, the call to
> evt.WaitOne in TNamedPipeServerTransport.AcceptImpl will block indefinitely
> because the lambda passed into stream.BeginWaitForConnection is never
> executed and evt.Set will never get called. We saw this in 0.9.3 but it's
> suspected to be in 0.11.0 as well.
> {noformat}
> // in server wrapper class MyServer
> this.serverThread = new Thread(() =>
> {
> var processor = new MyProcessor();
> var transport = new TNamedPipeServerTransport("MyPipeName");
> var svr = new TSimpleServer(processor, transport);
> lock (this.serverLock)
> {
> this.server = svr;
> }
> svr.Serve(); // This sometimes will not return
> })
> {
> IsBackground = true
> };
> this.serverThread.Start();
> {noformat}
> {noformat}
> // server wrapper class MyServer
>
[jira] [Updated] (THRIFT-4449) C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if TNamedPipeServerTransport.Close is called too quickly
[
https://issues.apache.org/jira/browse/THRIFT-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
boxcppguy updated THRIFT-4449:
--
Description:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into BeginWaitForConnection is never executed and evt.Set() will never
get called. We saw this in 0.9.3 but it's suspected to be in 0.11.0 as well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
was:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into BeginWaitForConnection is never executed. We saw this in 0.9.3 but
it's suspected to be in 0.11.0 as well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
> C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if
> TNamedPipeServerTransport.Close is called too quickly
> -
>
> Key: THRIFT-4449
> URL: https://issues.apache.org/jira/browse/THRIFT-4449
> Project: Thrift
> Issue Type: Bug
> Components: C# - Library
>Affects Versions: 0.9.3
> Environment: Windows 10.0.16299 64bit
>Reporter: boxcppguy
>
> What we observed is, when using the C# implementation
> TNamedPipeServerTransport along with TSimpleServer, if you call
> TSimpleServer.Stop too quickly after TSimpleServer.Serve, the call to
> evt.WaitOne in TNamedPipeServerTransport.AcceptImpl will block indefinitely
> because the lambda passed into BeginWaitForConnection is never executed and
> evt.Set() will never get called. We saw this in 0.9.3 but it's suspected to
> be in 0.11.0 as well.
> {noformat}
> // in server wrapper class MyServer
> this.serverThread = new Thread(() =>
> {
> var processor = new MyProcessor();
> var transport = new TNamedPipeServerTransport("MyPipeName");
> var svr = new TSimpleServer(processor, transport);
> lock (this.serverLock)
> {
> this.server = svr;
> }
> svr.Serve(); // This sometimes will not return
> })
> {
> IsBackground = true
> };
> this.serverThread.Start();
> {noformat}
> {noformat}
> // server wrapper class MyServer
> protected virtual void Dispose(bool disposing)
> {
> lock (this.serverLock)
> {
> try
>
[jira] [Updated] (THRIFT-4449) C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if TNamedPipeServerTransport.Close is called too quickly
[
https://issues.apache.org/jira/browse/THRIFT-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
boxcppguy updated THRIFT-4449:
--
Description:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into BeginWaitForConnection is never executed and evt.Set will never get
called. We saw this in 0.9.3 but it's suspected to be in 0.11.0 as well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
was:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into BeginWaitForConnection is never executed and evt.Set() will never
get called. We saw this in 0.9.3 but it's suspected to be in 0.11.0 as well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
> C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if
> TNamedPipeServerTransport.Close is called too quickly
> -
>
> Key: THRIFT-4449
> URL: https://issues.apache.org/jira/browse/THRIFT-4449
> Project: Thrift
> Issue Type: Bug
> Components: C# - Library
>Affects Versions: 0.9.3
> Environment: Windows 10.0.16299 64bit
>Reporter: boxcppguy
>
> What we observed is, when using the C# implementation
> TNamedPipeServerTransport along with TSimpleServer, if you call
> TSimpleServer.Stop too quickly after TSimpleServer.Serve, the call to
> evt.WaitOne in TNamedPipeServerTransport.AcceptImpl will block indefinitely
> because the lambda passed into BeginWaitForConnection is never executed and
> evt.Set will never get called. We saw this in 0.9.3 but it's suspected to be
> in 0.11.0 as well.
> {noformat}
> // in server wrapper class MyServer
> this.serverThread = new Thread(() =>
> {
> var processor = new MyProcessor();
> var transport = new TNamedPipeServerTransport("MyPipeName");
> var svr = new TSimpleServer(processor, transport);
> lock (this.serverLock)
> {
> this.server = svr;
> }
> svr.Serve(); // This sometimes will not return
> })
> {
> IsBackground = true
> };
> this.serverThread.Start();
> {noformat}
> {noformat}
> // server wrapper class MyServer
> protected virtual void Dispose(bool disposing)
> {
> lock (this.serv
[jira] [Updated] (THRIFT-4449) C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if TNamedPipeServerTransport.Close is called too quickly
[
https://issues.apache.org/jira/browse/THRIFT-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
boxcppguy updated THRIFT-4449:
--
Description:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into stream.BeginWaitForConnection is never executed and evt.Set will
never get called. We saw this in 0.9.3 but it's suspected to be in 0.11.0 as
well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
was:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into BeginWaitForConnection is never executed and evt.Set will never get
called. We saw this in 0.9.3 but it's suspected to be in 0.11.0 as well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
> C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if
> TNamedPipeServerTransport.Close is called too quickly
> -
>
> Key: THRIFT-4449
> URL: https://issues.apache.org/jira/browse/THRIFT-4449
> Project: Thrift
> Issue Type: Bug
> Components: C# - Library
>Affects Versions: 0.9.3
> Environment: Windows 10.0.16299 64bit
>Reporter: boxcppguy
>
> What we observed is, when using the C# implementation
> TNamedPipeServerTransport along with TSimpleServer, if you call
> TSimpleServer.Stop too quickly after TSimpleServer.Serve, the call to
> evt.WaitOne in TNamedPipeServerTransport.AcceptImpl will block indefinitely
> because the lambda passed into stream.BeginWaitForConnection is never
> executed and evt.Set will never get called. We saw this in 0.9.3 but it's
> suspected to be in 0.11.0 as well.
> {noformat}
> // in server wrapper class MyServer
> this.serverThread = new Thread(() =>
> {
> var processor = new MyProcessor();
> var transport = new TNamedPipeServerTransport("MyPipeName");
> var svr = new TSimpleServer(processor, transport);
> lock (this.serverLock)
> {
> this.server = svr;
> }
> svr.Serve(); // This sometimes will not return
> })
> {
> IsBackground = true
> };
> this.serverThread.Start();
> {noformat}
> {noformat}
> // server wrapper class MyServer
> protected virtual void Dispose(bool disposing)
> {
> lo
[jira] [Updated] (THRIFT-4449) C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if TNamedPipeServerTransport.Close is called too quickly
[
https://issues.apache.org/jira/browse/THRIFT-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
boxcppguy updated THRIFT-4449:
--
Description:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into BeginWaitForConnection is never executed. We saw this in 0.9.3 but
it's suspected to be in 0.11.0 as well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve();
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join();
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
was:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into BeginWaitForConnection is never executed. We saw this in 0.9.3 but
it's suspected to be in 0.11.0 as well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransportEx("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve();
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join();
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
> C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if
> TNamedPipeServerTransport.Close is called too quickly
> -
>
> Key: THRIFT-4449
> URL: https://issues.apache.org/jira/browse/THRIFT-4449
> Project: Thrift
> Issue Type: Bug
> Components: C# - Library
>Affects Versions: 0.9.3
> Environment: Windows 10.0.16299 64bit
>Reporter: boxcppguy
>
> What we observed is, when using the C# implementation
> TNamedPipeServerTransport along with TSimpleServer, if you call
> TSimpleServer.Stop too quickly after TSimpleServer.Serve, the call to
> evt.WaitOne in TNamedPipeServerTransport.AcceptImpl will block indefinitely
> because the lambda passed into BeginWaitForConnection is never executed. We
> saw this in 0.9.3 but it's suspected to be in 0.11.0 as well.
> {noformat}
> // in server wrapper class MyServer
> this.serverThread = new Thread(() =>
> {
> var processor = new MyProcessor();
> var transport = new TNamedPipeServerTransport("MyPipeName");
> var svr = new TSimpleServer(processor, transport);
> lock (this.serverLock)
> {
> this.server = svr;
> }
> svr.Serve();
> })
> {
> IsBackground = true
> };
> this.serverThread.Start();
> {noformat}
> {noformat}
> // server wrapper class MyServer
> protected virtual void Dispose(bool disposing)
> {
> lock (this.serverLock)
> {
> try
> {
> if (this.server != null)
> {
> this.server.Stop();
> }
> if (this.serverThread != null)
> {
> this.serverThread.Join();
> }
> }
> finally
> {
> thi
[jira] [Updated] (THRIFT-4449) C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if TNamedPipeServerTransport.Close is called too quickly
[
https://issues.apache.org/jira/browse/THRIFT-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
boxcppguy updated THRIFT-4449:
--
Description:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into BeginWaitForConnection is never executed. We saw this in 0.9.3 but
it's suspected to be in 0.11.0 as well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve(); // This sometimes will not return
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join(); // This will wait indefinitely
waiting for Serve to complete
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
was:
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into BeginWaitForConnection is never executed. We saw this in 0.9.3 but
it's suspected to be in 0.11.0 as well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransport("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve();
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join();
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
> C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if
> TNamedPipeServerTransport.Close is called too quickly
> -
>
> Key: THRIFT-4449
> URL: https://issues.apache.org/jira/browse/THRIFT-4449
> Project: Thrift
> Issue Type: Bug
> Components: C# - Library
>Affects Versions: 0.9.3
> Environment: Windows 10.0.16299 64bit
>Reporter: boxcppguy
>
> What we observed is, when using the C# implementation
> TNamedPipeServerTransport along with TSimpleServer, if you call
> TSimpleServer.Stop too quickly after TSimpleServer.Serve, the call to
> evt.WaitOne in TNamedPipeServerTransport.AcceptImpl will block indefinitely
> because the lambda passed into BeginWaitForConnection is never executed. We
> saw this in 0.9.3 but it's suspected to be in 0.11.0 as well.
> {noformat}
> // in server wrapper class MyServer
> this.serverThread = new Thread(() =>
> {
> var processor = new MyProcessor();
> var transport = new TNamedPipeServerTransport("MyPipeName");
> var svr = new TSimpleServer(processor, transport);
> lock (this.serverLock)
> {
> this.server = svr;
> }
> svr.Serve(); // This sometimes will not return
> })
> {
> IsBackground = true
> };
> this.serverThread.Start();
> {noformat}
> {noformat}
> // server wrapper class MyServer
> protected virtual void Dispose(bool disposing)
> {
> lock (this.serverLock)
> {
> try
> {
> if (this.server != null)
> {
> this.server.Stop();
> }
> if (this.serverThread != null)
>
[jira] [Created] (THRIFT-4449) C# - TNamedPipeServerTransport.AcceptImpl can block indefinitely if TNamedPipeServerTransport.Close is called too quickly
boxcppguy created THRIFT-4449:
-
Summary: C# - TNamedPipeServerTransport.AcceptImpl can block
indefinitely if TNamedPipeServerTransport.Close is called too quickly
Key: THRIFT-4449
URL: https://issues.apache.org/jira/browse/THRIFT-4449
Project: Thrift
Issue Type: Bug
Components: C# - Library
Affects Versions: 0.9.3
Environment: Windows 10.0.16299 64bit
Reporter: boxcppguy
What we observed is, when using the C# implementation TNamedPipeServerTransport
along with TSimpleServer, if you call TSimpleServer.Stop too quickly after
TSimpleServer.Serve, the call to evt.WaitOne in
TNamedPipeServerTransport.AcceptImpl will block indefinitely because the lambda
passed into BeginWaitForConnection is never executed. We saw this in 0.9.3 but
it's suspected to be in 0.11.0 as well.
{noformat}
// in server wrapper class MyServer
this.serverThread = new Thread(() =>
{
var processor = new MyProcessor();
var transport = new TNamedPipeServerTransportEx("MyPipeName");
var svr = new TSimpleServer(processor, transport);
lock (this.serverLock)
{
this.server = svr;
}
svr.Serve();
})
{
IsBackground = true
};
this.serverThread.Start();
{noformat}
{noformat}
// server wrapper class MyServer
protected virtual void Dispose(bool disposing)
{
lock (this.serverLock)
{
try
{
if (this.server != null)
{
this.server.Stop();
}
if (this.serverThread != null)
{
this.serverThread.Join();
}
}
finally
{
this.server = null;
this.serverThread = null;
}
}
}
{noformat}
{noformat}
// test code
for (int i = 0; i < 100; ++i)
{
using (var server = new MyServer())
{
server.Start();
}
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-4447) Golang: Panic on p.c.Call when using deprecated initializers
[
https://issues.apache.org/jira/browse/THRIFT-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321459#comment-16321459
]
ASF GitHub Bot commented on THRIFT-4447:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1461
The reasoning for this is that Apache maintains its own master repository;
so pull requests here have to be pulled into the master by a committer, and
then the github mirror updates. If the commit message contains a "This closes"
or "This fixes" line item then it closes the github issue or pull request when
that occurs. I'll merge this tonight - thanks.
> Golang: Panic on p.c.Call when using deprecated initializers
>
>
> Key: THRIFT-4447
> URL: https://issues.apache.org/jira/browse/THRIFT-4447
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.11.0
>Reporter: John Boiles
>
> Latest thrift:master can cause panics when using deprecated
> `New*ClientFactory` and `New*ClientProtocol` functions. This happens because
> both the Client and the BaseClient have an instance of a {{thrift.TClient}}.
> The deprecated methods initialize the BaseClient's TClient, but other methods
> use the Client's {{TClient}}.
> For example, current thrift master generates structs like this
> {code}
> type MyServiceClient struct {
> c thrift.TClient
> *MyServiceBaseClient
> }
> type MyServiceBaseClient struct {
> c thrift.TClient
> }
> {code}
> And also a method like this:
> {code}
> func NewMyServiceClientFactory(t thrift.TTransport, f
> thrift.TProtocolFactory) *MyServiceClient {
> return &MyServiceClient{MyServiceBaseClient:
> NewMyServiceBaseClientFactory(t, f)}
> }
> {code}
> If that method is used, later calls to service methods will panic, since
> {{p.c}} is nil (the actual client was stored in {{p.BaseMyServiceClient.c}}).
> {code}
> func (p *MyServiceClient) DoStuff(ctx context.Context, request
> *DoStuffRequest) (r *DoStuffResponse, err error) {
> var _args139 DoStuffArgs
> _args139.Request = request
> var _result140 DoStuffResult
> if err = p.c.Call(ctx, "do_stuff", &_args139, &_result140); err != nil
> { // PANIC
> ...
> {code}
> In progress fix here :https://github.com/apache/thrift/pull/1461. The fix in
> this PR merely sets both instances of {{TClient}} (which is what happens in
> the non-deprecated {{New*Client}} function).
> This patch currently fails {{make -k check}} however, since
> {{src/tutorial/tutorial.go}} tries to access a different package's version of
> the BaseClient.
> {code}
> src/tutorial/tutorial.go:477:33: bc.c undefined (cannot refer to unexported
> field or method c)
> {code}
> The fix for that test could possibly be to expose the BaseClient's instance
> of {{c}} (by making it a capital and thus exported {{C}}), or adding an
> accessor method {{C()}} or {{Client()}}.
> Possibly a better fix would be to either remove these deprecated methods, or
> figure out which {{TClient}} is the correct one to set.
> I'm not sure which is preferred, so I'm hoping to get some feedback/input
> here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1461: THRIFT-4447: Golang: Fix panic on p.c.Call when using de...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1461 The reasoning for this is that Apache maintains its own master repository; so pull requests here have to be pulled into the master by a committer, and then the github mirror updates. If the commit message contains a "This closes" or "This fixes" line item then it closes the github issue or pull request when that occurs. I'll merge this tonight - thanks. ---
[jira] [Comment Edited] (THRIFT-4413) Publish a Maven artifact for Thrift v0.11
[ https://issues.apache.org/jira/browse/THRIFT-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321449#comment-16321449 ] James E. King, III edited comment on THRIFT-4413 at 1/11/18 12:30 AM: -- I have a slack communication from [~jfarrell] around working on this from late Dec. I don't know the status though. He said that the versions of stuff we're using were not working for publication. Is our version of ant too old? I don't know, as I don't normally work in the Java environment, especially around packaging. was (Author: jking3): I have a slack communication from [~jfarrell] around working on this. I don't know the status though. He said that the versions of stuff we're using were not working for publication. Is our version of ant too old? I don't know, as I don't normally work in the Java environment, especially around packaging. > Publish a Maven artifact for Thrift v0.11 > - > > Key: THRIFT-4413 > URL: https://issues.apache.org/jira/browse/THRIFT-4413 > Project: Thrift > Issue Type: Task > Components: Java - Library >Affects Versions: 0.11.0 >Reporter: Buğra Gedik >Assignee: Jake Farrell > Fix For: 0.11.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4413) Publish a Maven artifact for Thrift v0.11
[ https://issues.apache.org/jira/browse/THRIFT-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321449#comment-16321449 ] James E. King, III commented on THRIFT-4413: I have a slack communication from [~jfarrell] around working on this. I don't know the status though. He said that the versions of stuff we're using were not working for publication. Is our version of ant too old? I don't know, as I don't normally work in the Java environment, especially around packaging. > Publish a Maven artifact for Thrift v0.11 > - > > Key: THRIFT-4413 > URL: https://issues.apache.org/jira/browse/THRIFT-4413 > Project: Thrift > Issue Type: Task > Components: Java - Library >Affects Versions: 0.11.0 >Reporter: Buğra Gedik >Assignee: Jake Farrell > Fix For: 0.11.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4448) Golang: do something with context.Context
[
https://issues.apache.org/jira/browse/THRIFT-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321447#comment-16321447
]
ASF GitHub Bot commented on THRIFT-4448:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1459
At this point we should consider dropping go 1.6. Other go projects have
moved on and we can too. I had a discussion with someone about whether it
makes sense to support older go versions, and they said back to 1.7 makes
sense, but 1.6 to 1.7 was a breaking change. Separately, we might dump the
trusty CI build environment. Not sure about that yet.
> Golang: do something with context.Context
> -
>
> Key: THRIFT-4448
> URL: https://issues.apache.org/jira/browse/THRIFT-4448
> Project: Thrift
> Issue Type: Task
> Components: Go - Library
>Affects Versions: 0.11.0
>Reporter: John Boiles
>
> PR Here: https://github.com/apache/thrift/pull/1459
> This patch wires through {{context.Context}} such that it can be used in in
> {{http.Request}}'s {{WithContext}} method. This allows Thrift HTTP requests
> to canceled or timed out via the context.
> This patch breaks support for go<1.7 so it's not ready to ship, but I'm
> hoping to get some direction on this. When does Thrift expect to drop support
> of go1.7? It looks like the current solution is to duplicate files that need
> to use {{golang.org/x/net/context}} and add a {{// +build !go1.7}} but
> duplication seems unsustainable as the {{context}} package is imported more
> places.
> Go 1.7 was released 15 August 2016. Given Golang has had significant
> performance improvements in most dot releases, I suspect most production
> services stay reasonably up to date. Here at Periscope/Twitter we're on
> go1.9.1, and we're a fairly large organization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1459: THRIFT-4448: Golang: do something with context.Context
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1459 At this point we should consider dropping go 1.6. Other go projects have moved on and we can too. I had a discussion with someone about whether it makes sense to support older go versions, and they said back to 1.7 makes sense, but 1.6 to 1.7 was a breaking change. Separately, we might dump the trusty CI build environment. Not sure about that yet. ---
[jira] [Commented] (THRIFT-4390) Rust binary protocol and buffered transport cannot handle writes above 4096 bytes
[
https://issues.apache.org/jira/browse/THRIFT-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321444#comment-16321444
]
ASF GitHub Bot commented on THRIFT-4390:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1458
Sure - I like progress. :)
> Rust binary protocol and buffered transport cannot handle writes above 4096
> bytes
> -
>
> Key: THRIFT-4390
> URL: https://issues.apache.org/jira/browse/THRIFT-4390
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Affects Versions: 0.10.0
> Environment: docker image ubuntu-artful
>Reporter: James E. King, III
>Assignee: Allen George
>Priority: Critical
>
> While working on improving test coverage and fixing busted cross tests I
> reworked the cpp test client to send binary in at size 0, 1, 2, 4, 6, 16,
> ..., 131072 and after 4096 the rust server gave up.
> {noformat}
> 12, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126,
> 127, 128])
> WARN:thrift::server::threaded: processor completed with error: TransportError
> { kind: Unknown, message: "failed to write whole buffer" }
> Server process is successfully killed.
> {noformat}
> @gadLinux this may be the root cause of some of the issues you were seeing
> with the interop against c_glib recently. It is the root cause of some (if
> not all of) the rs-csharp test failures.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1458: THRIFT-4390: Fix bug where binary/buffered messages > 4K...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1458 Sure - I like progress. :) ---
[jira] [Commented] (THRIFT-4295) Refresh the Docker image file suite for Ubuntu, Debian, and CentOS
[
https://issues.apache.org/jira/browse/THRIFT-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321438#comment-16321438
]
ASF GitHub Bot commented on THRIFT-4295:
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1340#discussion_r160835825
--- Diff: lib/php/lib/Thrift/Transport/TSocket.php ---
@@ -242,8 +242,10 @@ public function open()
throw new TException($error);
}
-$socket = socket_import_stream($this->handle_);
-socket_set_option($socket, SOL_TCP, TCP_NODELAY, 1);
+if (function_exists('socket_import_stream') &&
function_exists('socket_set_option')) {
--- End diff --
I'd like to know a little more. If the functions don't exist they cannot
be called. Is the problem that function_exists is returning the wrong result?
> Refresh the Docker image file suite for Ubuntu, Debian, and CentOS
> --
>
> Key: THRIFT-4295
> URL: https://issues.apache.org/jira/browse/THRIFT-4295
> Project: Thrift
> Issue Type: Improvement
> Components: Build Process
>Affects Versions: 0.11.0
> Environment: docker, travis
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Critical
> Labels: centos, debian, docker, travis-ci, ubuntu
> Fix For: 0.11.0
>
>
> The docker build images are in need of some much needed updating to avoid CI
> build issues.
> centos is getting updates for cmake, gcc, go, and others as well as working
> around the epel issue with nodejs and http_parser
> debian is being updated from jessie (8) to stretch (9.1)
> ubuntu is being updated from 14.04 to 16.04
> The previous images will still be available:
> centos6 will remain untouched, however the last remaining build job
> validating python 2.6 is going to be removed
> debian8 will be there for jessie, however we will not build packages from it
> any more
> ubuntu1404 will be there for trusty, however we will not build using it any
> more
> So far here's what's on the ubuntu 16.04 xenial docker image:
> {noformat}
> C++ (C++11 default) gcc-5.4.0, clang-3.8
> C# mono 5.2.0.215
> c_glib 2.0
> d 2.075.1
> dart1.24.2
> erlang 18.3
> go 1.6.2
> haskell 7.10.3
> haxe3.2.1
> java1.8.0_131
> lua 5.3
> nodejs 8.4.0
> perl5.22.1
> php 7.0.22
> python 2.7.12, 3.5.2
> ruby2.3.1p112
> rust1.15.1
> Intentionally leaving this out, for now (it wasn't in the trusty docker image
> either):
> dotnet 2.0.0
> Not in any images:
> cocoa
> smalltalk
> swift
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift pull request #1340: THRIFT-4295: reworked docker images to resolve bu...
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1340#discussion_r160835825
--- Diff: lib/php/lib/Thrift/Transport/TSocket.php ---
@@ -242,8 +242,10 @@ public function open()
throw new TException($error);
}
-$socket = socket_import_stream($this->handle_);
-socket_set_option($socket, SOL_TCP, TCP_NODELAY, 1);
+if (function_exists('socket_import_stream') &&
function_exists('socket_set_option')) {
--- End diff --
I'd like to know a little more. If the functions don't exist they cannot
be called. Is the problem that function_exists is returning the wrong result?
---
[jira] [Commented] (THRIFT-4447) Golang: Panic on p.c.Call when using deprecated initializers
[
https://issues.apache.org/jira/browse/THRIFT-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321166#comment-16321166
]
ASF GitHub Bot commented on THRIFT-4447:
Github user johnboiles commented on the issue:
https://github.com/apache/thrift/pull/1461
> For Thrift, PRs are not merged, just closed. You'll see a commit with you
as the author but someone else as the committer, like these.
Ah got it, good to know thanks!
> Golang: Panic on p.c.Call when using deprecated initializers
>
>
> Key: THRIFT-4447
> URL: https://issues.apache.org/jira/browse/THRIFT-4447
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.11.0
>Reporter: John Boiles
>
> Latest thrift:master can cause panics when using deprecated
> `New*ClientFactory` and `New*ClientProtocol` functions. This happens because
> both the Client and the BaseClient have an instance of a {{thrift.TClient}}.
> The deprecated methods initialize the BaseClient's TClient, but other methods
> use the Client's {{TClient}}.
> For example, current thrift master generates structs like this
> {code}
> type MyServiceClient struct {
> c thrift.TClient
> *MyServiceBaseClient
> }
> type MyServiceBaseClient struct {
> c thrift.TClient
> }
> {code}
> And also a method like this:
> {code}
> func NewMyServiceClientFactory(t thrift.TTransport, f
> thrift.TProtocolFactory) *MyServiceClient {
> return &MyServiceClient{MyServiceBaseClient:
> NewMyServiceBaseClientFactory(t, f)}
> }
> {code}
> If that method is used, later calls to service methods will panic, since
> {{p.c}} is nil (the actual client was stored in {{p.BaseMyServiceClient.c}}).
> {code}
> func (p *MyServiceClient) DoStuff(ctx context.Context, request
> *DoStuffRequest) (r *DoStuffResponse, err error) {
> var _args139 DoStuffArgs
> _args139.Request = request
> var _result140 DoStuffResult
> if err = p.c.Call(ctx, "do_stuff", &_args139, &_result140); err != nil
> { // PANIC
> ...
> {code}
> In progress fix here :https://github.com/apache/thrift/pull/1461. The fix in
> this PR merely sets both instances of {{TClient}} (which is what happens in
> the non-deprecated {{New*Client}} function).
> This patch currently fails {{make -k check}} however, since
> {{src/tutorial/tutorial.go}} tries to access a different package's version of
> the BaseClient.
> {code}
> src/tutorial/tutorial.go:477:33: bc.c undefined (cannot refer to unexported
> field or method c)
> {code}
> The fix for that test could possibly be to expose the BaseClient's instance
> of {{c}} (by making it a capital and thus exported {{C}}), or adding an
> accessor method {{C()}} or {{Client()}}.
> Possibly a better fix would be to either remove these deprecated methods, or
> figure out which {{TClient}} is the correct one to set.
> I'm not sure which is preferred, so I'm hoping to get some feedback/input
> here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1461: THRIFT-4447: Golang: Fix panic on p.c.Call when using de...
Github user johnboiles commented on the issue: https://github.com/apache/thrift/pull/1461 > For Thrift, PRs are not merged, just closed. You'll see a commit with you as the author but someone else as the committer, like these. Ah got it, good to know thanks! ---
[jira] [Commented] (THRIFT-4447) Golang: Panic on p.c.Call when using deprecated initializers
[
https://issues.apache.org/jira/browse/THRIFT-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321096#comment-16321096
]
ASF GitHub Bot commented on THRIFT-4447:
Github user dcelasun commented on the issue:
https://github.com/apache/thrift/pull/1461
> GitHub can now automatically squash commits in PRs at merge time
For Thrift, PRs are not merged, just closed. You'll see a commit with you
as the author but someone else as the committer, like
[these](https://github.com/apache/thrift/commits/master).
> Golang: Panic on p.c.Call when using deprecated initializers
>
>
> Key: THRIFT-4447
> URL: https://issues.apache.org/jira/browse/THRIFT-4447
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.11.0
>Reporter: John Boiles
>
> Latest thrift:master can cause panics when using deprecated
> `New*ClientFactory` and `New*ClientProtocol` functions. This happens because
> both the Client and the BaseClient have an instance of a {{thrift.TClient}}.
> The deprecated methods initialize the BaseClient's TClient, but other methods
> use the Client's {{TClient}}.
> For example, current thrift master generates structs like this
> {code}
> type MyServiceClient struct {
> c thrift.TClient
> *MyServiceBaseClient
> }
> type MyServiceBaseClient struct {
> c thrift.TClient
> }
> {code}
> And also a method like this:
> {code}
> func NewMyServiceClientFactory(t thrift.TTransport, f
> thrift.TProtocolFactory) *MyServiceClient {
> return &MyServiceClient{MyServiceBaseClient:
> NewMyServiceBaseClientFactory(t, f)}
> }
> {code}
> If that method is used, later calls to service methods will panic, since
> {{p.c}} is nil (the actual client was stored in {{p.BaseMyServiceClient.c}}).
> {code}
> func (p *MyServiceClient) DoStuff(ctx context.Context, request
> *DoStuffRequest) (r *DoStuffResponse, err error) {
> var _args139 DoStuffArgs
> _args139.Request = request
> var _result140 DoStuffResult
> if err = p.c.Call(ctx, "do_stuff", &_args139, &_result140); err != nil
> { // PANIC
> ...
> {code}
> In progress fix here :https://github.com/apache/thrift/pull/1461. The fix in
> this PR merely sets both instances of {{TClient}} (which is what happens in
> the non-deprecated {{New*Client}} function).
> This patch currently fails {{make -k check}} however, since
> {{src/tutorial/tutorial.go}} tries to access a different package's version of
> the BaseClient.
> {code}
> src/tutorial/tutorial.go:477:33: bc.c undefined (cannot refer to unexported
> field or method c)
> {code}
> The fix for that test could possibly be to expose the BaseClient's instance
> of {{c}} (by making it a capital and thus exported {{C}}), or adding an
> accessor method {{C()}} or {{Client()}}.
> Possibly a better fix would be to either remove these deprecated methods, or
> figure out which {{TClient}} is the correct one to set.
> I'm not sure which is preferred, so I'm hoping to get some feedback/input
> here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1461: THRIFT-4447: Golang: Fix panic on p.c.Call when using de...
Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1461 > GitHub can now automatically squash commits in PRs at merge time For Thrift, PRs are not merged, just closed. You'll see a commit with you as the author but someone else as the committer, like [these](https://github.com/apache/thrift/commits/master). ---
[jira] [Commented] (THRIFT-4447) Golang: Panic on p.c.Call when using deprecated initializers
[
https://issues.apache.org/jira/browse/THRIFT-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321089#comment-16321089
]
ASF GitHub Bot commented on THRIFT-4447:
Github user johnboiles commented on the issue:
https://github.com/apache/thrift/pull/1461
Travis was green so i've squashed it!
FYI for the future: GitHub can now automatically squash commits in PRs at
merge time. If that feature is enabled for the repo it shouldn't be necessary
for committers to squash their branch prior to merging, since everything can be
squashed via the GitHub UI:
> Golang: Panic on p.c.Call when using deprecated initializers
>
>
> Key: THRIFT-4447
> URL: https://issues.apache.org/jira/browse/THRIFT-4447
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.11.0
>Reporter: John Boiles
>
> Latest thrift:master can cause panics when using deprecated
> `New*ClientFactory` and `New*ClientProtocol` functions. This happens because
> both the Client and the BaseClient have an instance of a {{thrift.TClient}}.
> The deprecated methods initialize the BaseClient's TClient, but other methods
> use the Client's {{TClient}}.
> For example, current thrift master generates structs like this
> {code}
> type MyServiceClient struct {
> c thrift.TClient
> *MyServiceBaseClient
> }
> type MyServiceBaseClient struct {
> c thrift.TClient
> }
> {code}
> And also a method like this:
> {code}
> func NewMyServiceClientFactory(t thrift.TTransport, f
> thrift.TProtocolFactory) *MyServiceClient {
> return &MyServiceClient{MyServiceBaseClient:
> NewMyServiceBaseClientFactory(t, f)}
> }
> {code}
> If that method is used, later calls to service methods will panic, since
> {{p.c}} is nil (the actual client was stored in {{p.BaseMyServiceClient.c}}).
> {code}
> func (p *MyServiceClient) DoStuff(ctx context.Context, request
> *DoStuffRequest) (r *DoStuffResponse, err error) {
> var _args139 DoStuffArgs
> _args139.Request = request
> var _result140 DoStuffResult
> if err = p.c.Call(ctx, "do_stuff", &_args139, &_result140); err != nil
> { // PANIC
> ...
> {code}
> In progress fix here :https://github.com/apache/thrift/pull/1461. The fix in
> this PR merely sets both instances of {{TClient}} (which is what happens in
> the non-deprecated {{New*Client}} function).
> This patch currently fails {{make -k check}} however, since
> {{src/tutorial/tutorial.go}} tries to access a different package's version of
> the BaseClient.
> {code}
> src/tutorial/tutorial.go:477:33: bc.c undefined (cannot refer to unexported
> field or method c)
> {code}
> The fix for that test could possibly be to expose the BaseClient's instance
> of {{c}} (by making it a capital and thus exported {{C}}), or adding an
> accessor method {{C()}} or {{Client()}}.
> Possibly a better fix would be to either remove these deprecated methods, or
> figure out which {{TClient}} is the correct one to set.
> I'm not sure which is preferred, so I'm hoping to get some feedback/input
> here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1461: THRIFT-4447: Golang: Fix panic on p.c.Call when using de...
Github user johnboiles commented on the issue: https://github.com/apache/thrift/pull/1461 Travis was green so i've squashed it! FYI for the future: GitHub can now automatically squash commits in PRs at merge time. If that feature is enabled for the repo it shouldn't be necessary for committers to squash their branch prior to merging, since everything can be squashed via the GitHub UI:  ---
[jira] [Commented] (THRIFT-4447) Golang: Panic on p.c.Call when using deprecated initializers
[
https://issues.apache.org/jira/browse/THRIFT-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16320807#comment-16320807
]
ASF GitHub Bot commented on THRIFT-4447:
Github user dcelasun commented on the issue:
https://github.com/apache/thrift/pull/1461
Happy to help. Once Travis is all green, please squash your commits so
it'll be easier to merge.
> Golang: Panic on p.c.Call when using deprecated initializers
>
>
> Key: THRIFT-4447
> URL: https://issues.apache.org/jira/browse/THRIFT-4447
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.11.0
>Reporter: John Boiles
>
> Latest thrift:master can cause panics when using deprecated
> `New*ClientFactory` and `New*ClientProtocol` functions. This happens because
> both the Client and the BaseClient have an instance of a {{thrift.TClient}}.
> The deprecated methods initialize the BaseClient's TClient, but other methods
> use the Client's {{TClient}}.
> For example, current thrift master generates structs like this
> {code}
> type MyServiceClient struct {
> c thrift.TClient
> *MyServiceBaseClient
> }
> type MyServiceBaseClient struct {
> c thrift.TClient
> }
> {code}
> And also a method like this:
> {code}
> func NewMyServiceClientFactory(t thrift.TTransport, f
> thrift.TProtocolFactory) *MyServiceClient {
> return &MyServiceClient{MyServiceBaseClient:
> NewMyServiceBaseClientFactory(t, f)}
> }
> {code}
> If that method is used, later calls to service methods will panic, since
> {{p.c}} is nil (the actual client was stored in {{p.BaseMyServiceClient.c}}).
> {code}
> func (p *MyServiceClient) DoStuff(ctx context.Context, request
> *DoStuffRequest) (r *DoStuffResponse, err error) {
> var _args139 DoStuffArgs
> _args139.Request = request
> var _result140 DoStuffResult
> if err = p.c.Call(ctx, "do_stuff", &_args139, &_result140); err != nil
> { // PANIC
> ...
> {code}
> In progress fix here :https://github.com/apache/thrift/pull/1461. The fix in
> this PR merely sets both instances of {{TClient}} (which is what happens in
> the non-deprecated {{New*Client}} function).
> This patch currently fails {{make -k check}} however, since
> {{src/tutorial/tutorial.go}} tries to access a different package's version of
> the BaseClient.
> {code}
> src/tutorial/tutorial.go:477:33: bc.c undefined (cannot refer to unexported
> field or method c)
> {code}
> The fix for that test could possibly be to expose the BaseClient's instance
> of {{c}} (by making it a capital and thus exported {{C}}), or adding an
> accessor method {{C()}} or {{Client()}}.
> Possibly a better fix would be to either remove these deprecated methods, or
> figure out which {{TClient}} is the correct one to set.
> I'm not sure which is preferred, so I'm hoping to get some feedback/input
> here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1461: THRIFT-4447: Golang: Fix panic on p.c.Call when using de...
Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1461 Happy to help. Once Travis is all green, please squash your commits so it'll be easier to merge. ---
[jira] [Commented] (THRIFT-4447) Golang: Panic on p.c.Call when using deprecated initializers
[
https://issues.apache.org/jira/browse/THRIFT-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16320722#comment-16320722
]
ASF GitHub Bot commented on THRIFT-4447:
Github user johnboiles commented on the issue:
https://github.com/apache/thrift/pull/1461
Done ^. Thanks again for all your direction Dcelasun
> Golang: Panic on p.c.Call when using deprecated initializers
>
>
> Key: THRIFT-4447
> URL: https://issues.apache.org/jira/browse/THRIFT-4447
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.11.0
>Reporter: John Boiles
>
> Latest thrift:master can cause panics when using deprecated
> `New*ClientFactory` and `New*ClientProtocol` functions. This happens because
> both the Client and the BaseClient have an instance of a {{thrift.TClient}}.
> The deprecated methods initialize the BaseClient's TClient, but other methods
> use the Client's {{TClient}}.
> For example, current thrift master generates structs like this
> {code}
> type MyServiceClient struct {
> c thrift.TClient
> *MyServiceBaseClient
> }
> type MyServiceBaseClient struct {
> c thrift.TClient
> }
> {code}
> And also a method like this:
> {code}
> func NewMyServiceClientFactory(t thrift.TTransport, f
> thrift.TProtocolFactory) *MyServiceClient {
> return &MyServiceClient{MyServiceBaseClient:
> NewMyServiceBaseClientFactory(t, f)}
> }
> {code}
> If that method is used, later calls to service methods will panic, since
> {{p.c}} is nil (the actual client was stored in {{p.BaseMyServiceClient.c}}).
> {code}
> func (p *MyServiceClient) DoStuff(ctx context.Context, request
> *DoStuffRequest) (r *DoStuffResponse, err error) {
> var _args139 DoStuffArgs
> _args139.Request = request
> var _result140 DoStuffResult
> if err = p.c.Call(ctx, "do_stuff", &_args139, &_result140); err != nil
> { // PANIC
> ...
> {code}
> In progress fix here :https://github.com/apache/thrift/pull/1461. The fix in
> this PR merely sets both instances of {{TClient}} (which is what happens in
> the non-deprecated {{New*Client}} function).
> This patch currently fails {{make -k check}} however, since
> {{src/tutorial/tutorial.go}} tries to access a different package's version of
> the BaseClient.
> {code}
> src/tutorial/tutorial.go:477:33: bc.c undefined (cannot refer to unexported
> field or method c)
> {code}
> The fix for that test could possibly be to expose the BaseClient's instance
> of {{c}} (by making it a capital and thus exported {{C}}), or adding an
> accessor method {{C()}} or {{Client()}}.
> Possibly a better fix would be to either remove these deprecated methods, or
> figure out which {{TClient}} is the correct one to set.
> I'm not sure which is preferred, so I'm hoping to get some feedback/input
> here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1461: THRIFT-4447: Golang: Fix panic on p.c.Call when using de...
Github user johnboiles commented on the issue: https://github.com/apache/thrift/pull/1461 Done ^. Thanks again for all your direction Dcelasun ---
[jira] [Commented] (THRIFT-4434) Update .NET Core components, add tests for .Net Core library and .Net Core compiler, fix bugs and build process
[ https://issues.apache.org/jira/browse/THRIFT-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16320434#comment-16320434 ] Volodymyr Gotra commented on THRIFT-4434: - Hey It seem it works well now (checked logs) - almost all errors fixed, also integration with other languages is perfect (except CSharp - I think we can merge some changes into CSharp language later to fix compatibility and found bugs - maybe some functionality is missing in CSharp implementation). Please help to merge as quick as possible this pull request (to avoid problems with merges). Also it will be a great idea to be able to apply some compiler flags for different builds (because of C++ compilers related problems - with one compiler we can build it easily, but another one can throw errors on usual usage of C++ language instructions). Also, can be great to share with people scripts to build and instruction how to reuse environments for building to avoid usage a AppVeyor/TravisCI a lot of times and make pull requests faster to merge (I think this can be great help for community and will help to process pull requests faster for you). Additional idea - to reuse CMake fully for all solution - it seems that CMake is going to be de facto standard to reuse it with many compilers (also it easier to modify and customize for different compilers to solution very stable and flexible). According to news, LLVM(Clang) moved to CMake. Thanks for help > Update .NET Core components, add tests for .Net Core library and .Net Core > compiler, fix bugs and build process > --- > > Key: THRIFT-4434 > URL: https://issues.apache.org/jira/browse/THRIFT-4434 > Project: Thrift > Issue Type: Improvement > Components: .NETCore - Compiler, .NETCore - Library, Build Process > Environment: Windows, Linux, MacOS >Reporter: Volodymyr Gotra >Assignee: Volodymyr Gotra >Priority: Critical > > This pull request should: > - highly improve the current version of .Net Core library and .Net Core > compiler and quality of code > - improve and simplify build process > - improve documentation related to .Net Core library and compiler > - fix found bugs (some of bugs can be clarified like major - they are related > to porting of protocols from Java version and can be present in C# library) > - add important unit tests for .Net Core library and .Net Core compiler > - add possibility to easy add unit tests for compiler for other languages -- This message was sent by Atlassian JIRA (v6.4.14#64029)
