[GitHub] thrift issue #1341: THRIFT-4307: Make ssl-open timeout effective in golang c...
Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1341 LGTM, but Travis build didn't run correctly due to a Docker issue, please close & reopen this to trigger a rebuild. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4307) Make ssl-open timeout effective in golang client
[
https://issues.apache.org/jira/browse/THRIFT-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152254#comment-16152254
]
ASF GitHub Bot commented on THRIFT-4307:
Github user dcelasun commented on the issue:
https://github.com/apache/thrift/pull/1341
LGTM, but Travis build didn't run correctly due to a Docker issue, please
close & reopen this to trigger a rebuild.
> Make ssl-open timeout effective in golang client
>
>
> Key: THRIFT-4307
> URL: https://issues.apache.org/jira/browse/THRIFT-4307
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: tudyzhb
> Fix For: 0.10.0, 0.11.0
>
>
> {code:go}
> package rpc
> import (
> "git.apache.org/thrift.git/lib/go/thrift"
> "crypto/tls"
> "time"
> )
> func open() {
> var (
> addr = "192.168.1.100:4000"
> timeout = time.Second * 10
> transportFactory = thrift.NewTTransportFactory()
> transportthrift.TTransport
> err error
> )
> // timeout work in normal socket
> if transport, err = thrift.NewTSocketTimeout(addr, timeout); err != nil
> {
> return
> }
> // timeout not work in SSL Socket
> if transport, err = thrift.NewTSSLSocketTimeout(addr, &tls.Config{
> InsecureSkipVerify: true,
> }, timeout); err != nil {
> return
> }
> transport = transportFactory.GetTransport(transport)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1340: THRIFT-4295: reworked docker images to resolve build iss...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1340 Travis CI build failure was environmental (unable to download a module from the dart module service). Otherwise this is good to go. ---
[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=16152832#comment-16152832
]
ASF GitHub Bot commented on THRIFT-4295:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1340
Travis CI build failure was environmental (unable to download a module from
the dart module service). Otherwise this is good to go.
> 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
>
> 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)
[jira] [Updated] (THRIFT-4303) D 2.075 deprecation warnings
[
https://issues.apache.org/jira/browse/THRIFT-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-4303:
---
Environment: docker:ubuntu-xenial (was: docker:ubuntu1604)
> D 2.075 deprecation warnings
>
>
> Key: THRIFT-4303
> URL: https://issues.apache.org/jira/browse/THRIFT-4303
> Project: Thrift
> Issue Type: Bug
> Components: D - Library
>Affects Versions: 0.10.0
> Environment: docker:ubuntu-xenial
>Reporter: James E. King, III
>Priority: Minor
>
> In the ubuntu 16.04 image dmd is version 2.075 and the following warnings are
> being presented when building "make check":
> {noformat}
> ../../lib/d/src/thrift/transport/socket.d(83): Deprecation: Implicit string
> concatenation is deprecated, use "DMD bug? \u2013 Why would contracts work
> for interfaces, but not " ~ "for abstract methods? " instead
> ../../lib/d/src/thrift/transport/socket.d(84): Deprecation: Implicit string
> concatenation is deprecated, use "for abstract methods? " ~ "(Error: function
> [\u2026] in and out contracts require function body" instead
> src/thrift/protocol/json.d(29): Deprecation: function std.utf.toUTF8 is
> deprecated - To be removed November 2017. Please use std.utf.encode instead.
> src/thrift/transport/http.d(334): Deprecation: Implicit string concatenation
> is deprecated, use "Accept: application/x-thrift\x0d\x0a" ~ "User-Agent:
> Thrift/" instead
> {noformat}
> I cleaned all but the UTF8 one up in this PR:
> https://github.com/apache/thrift/pull/1340/files
> There were a couple others in "make check" inside lib/d so best check for
> anything else as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (THRIFT-4303) D 2.075 deprecation warnings
[
https://issues.apache.org/jira/browse/THRIFT-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-4303:
---
Description:
In the ubuntu 16.04 image dmd is version 2.075 and the following warnings are
being presented when building "make check":
{noformat}
../../lib/d/src/thrift/transport/socket.d(83): Deprecation: Implicit string
concatenation is deprecated, use "DMD bug? \u2013 Why would contracts work for
interfaces, but not " ~ "for abstract methods? " instead
../../lib/d/src/thrift/transport/socket.d(84): Deprecation: Implicit string
concatenation is deprecated, use "for abstract methods? " ~ "(Error: function
[\u2026] in and out contracts require function body" instead
src/thrift/protocol/json.d(29): Deprecation: function std.utf.toUTF8 is
deprecated - To be removed November 2017. Please use std.utf.encode instead.
src/thrift/transport/http.d(334): Deprecation: Implicit string concatenation is
deprecated, use "Accept: application/x-thrift\x0d\x0a" ~ "User-Agent: Thrift/"
instead
{noformat}
I cleaned all but the UTF8 one up in this PR:
https://github.com/apache/thrift/pull/1340/files
There were a couple others in "make check" inside lib/d so best check for
anything else as well.
was:
In the ubuntu 16.04 image dmd is version 2.075 and the following warnings are
being presented when building "make check":
{noformat}
../../lib/d/src/thrift/transport/socket.d(83): Deprecation: Implicit string
concatenation is deprecated, use "DMD bug? \u2013 Why would contracts work for
interfaces, but not " ~ "for abstract methods? " instead
../../lib/d/src/thrift/transport/socket.d(84): Deprecation: Implicit string
concatenation is deprecated, use "for abstract methods? " ~ "(Error: function
[\u2026] in and out contracts require function body" instead
src/thrift/protocol/json.d(29): Deprecation: function std.utf.toUTF8 is
deprecated - To be removed November 2017. Please use std.utf.encode instead.
src/thrift/transport/http.d(334): Deprecation: Implicit string concatenation is
deprecated, use "Accept: application/x-thrift\x0d\x0a" ~ "User-Agent: Thrift/"
instead
{noformat}
> D 2.075 deprecation warnings
>
>
> Key: THRIFT-4303
> URL: https://issues.apache.org/jira/browse/THRIFT-4303
> Project: Thrift
> Issue Type: Bug
> Components: D - Library
>Affects Versions: 0.10.0
> Environment: docker:ubuntu1604
>Reporter: James E. King, III
>Priority: Minor
>
> In the ubuntu 16.04 image dmd is version 2.075 and the following warnings are
> being presented when building "make check":
> {noformat}
> ../../lib/d/src/thrift/transport/socket.d(83): Deprecation: Implicit string
> concatenation is deprecated, use "DMD bug? \u2013 Why would contracts work
> for interfaces, but not " ~ "for abstract methods? " instead
> ../../lib/d/src/thrift/transport/socket.d(84): Deprecation: Implicit string
> concatenation is deprecated, use "for abstract methods? " ~ "(Error: function
> [\u2026] in and out contracts require function body" instead
> src/thrift/protocol/json.d(29): Deprecation: function std.utf.toUTF8 is
> deprecated - To be removed November 2017. Please use std.utf.encode instead.
> src/thrift/transport/http.d(334): Deprecation: Implicit string concatenation
> is deprecated, use "Accept: application/x-thrift\x0d\x0a" ~ "User-Agent:
> Thrift/" instead
> {noformat}
> I cleaned all but the UTF8 one up in this PR:
> https://github.com/apache/thrift/pull/1340/files
> There were a couple others in "make check" inside lib/d so best check for
> anything else as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (THRIFT-4308) D language docker images need demios for libevent and openssl fixed
James E. King, III created THRIFT-4308: -- Summary: D language docker images need demios for libevent and openssl fixed Key: THRIFT-4308 URL: https://issues.apache.org/jira/browse/THRIFT-4308 Project: Thrift Issue Type: Bug Components: Build Process, D - Library Affects Versions: 0.11.0 Environment: docker:ubuntu-xenial Reporter: James E. King, III I had to disable the deimos hooks for libevent and openssl because they were causing build failures. For openssl the deimos library only supports up to 1.0.1, and ubuntu-xenial has 1.0.2; for libevent I was unable to get some of the "make check" tests to link, citing unreferenced methods that were actually in the libevent.so file that ld resolved to, so I don't know what's going on there. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-3932) C++ ThreadManager has a rare termination race
[
https://issues.apache.org/jira/browse/THRIFT-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152958#comment-16152958
]
Buğra Gedik commented on THRIFT-3932:
-
Hi [~jking3]. Do you know if there are any release plans that would contain
this fix? Is there a publicly available resource that talks about release
plans? Thanks!
> C++ ThreadManager has a rare termination race
> -
>
> Key: THRIFT-3932
> URL: https://issues.apache.org/jira/browse/THRIFT-3932
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Reporter: Buğra Gedik
>Assignee: James E. King, III
> Fix For: 0.10.0
>
> Attachments: thrift-patch
>
> Time Spent: 17h
> Remaining Estimate: 0h
>
> {{ThreadManger::join}} calls {{stopImpl(true)}}, which in turn calls
> {{removeWorker(workerCount_);}}. The latter waits until {{while (workerCount_
> != workerMaxCount_)}}. Within the {{run}} method of the workers, the last
> thread that detects {{workerCount_ == workerMaxCount_}} notifies
> {{removeWorker}}. The {{run}} method has the following additional code that
> is executed at the very end:
> {code}
> {
> Synchronized s(manager_->workerMonitor_);
> manager_->deadWorkers_.insert(this->thread());
> if (notifyManager) {
> manager_->workerMonitor_.notify();
> }
> }
> {code}
> This is an independent synchronized block. Now assume 2 threads. One of them
> has {{notifyManager=true}} as it detected the {{workerCount_ ==
> workerMaxCount_}} condition earlier. It is possible that this thread gets to
> execute the above code block first, {{ThreadManager}}'s {{removeWorker}}
> method unblocks, and eventually {{ThreadManager}}'s {{join}} returns and the
> object is destructed. When the other thread reaches the synchronized block
> above, it will crash, as the manager is not around anymore.
> Besides, {{ThreadManager}} never joins its threads.
> Attached is a patch.
> {panel:title=Resolution
> Details|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> A fair number of things were improved with this pull request:
> # There are three monitors used for signaling; two of them use the same mutex
> and then the workerMonitor is using its own. I made all three use the same
> mutex.
> # I replaced all calls to Synchronize with Guard on the mutex_ so it is a bit
> clearer that there is one lock protecting everything.
> # The worker run loop expires tasks as it encounters them. Now we only call
> removeExpiredTasks if there's no room during add.
> # I found that when worker threads are removed they are not joined; if a
> thread is not detached we now join those threads.
> # I added better documentation and simplified the Worker::run() a little so
> it is easier to understand, but the logic is the same. idle_ was not used and
> removed.
> # I found that remove(Task) simply wasn't implemented at all! so I added code
> for that and tests.
> # Release mode tests of thread manager would not fail on error because they
> use assert() to verify results! If we only do release builds in CI, these
> tests may have been silently failing for a long time.
> # ThreadManager::join() is unnecessary, as stop() will join worker threads
> (as will removeWorker) depending on the ThreadFactory's detached disposition.
> # Cleaned up some technical debt from the TServerFramework refactoring:
> # Cleaned up some things in the different platform thread factories. Some
> abstractions were unnecessary.
> # Reduced overall time on concurrency test to about 30 seconds on my dev
> system while increasing the reliability and improving test coverage
> significantly. I ran it 100 times in a loop.
> # Added tests for most of the ThreadManager APIs.
> # Tested with posix, std, and boost threads on linux.
> # Tested on Windows.
> # Fixed a math error in time calculation that was present on Windows (with
> VS2010) which made expiring tasks impossible (unit test proved the issue and
> the fix).
> # Re-enable unit tests in the appveyor build that are no longer unstable.
> {panel}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1341: THRIFT-4307: Make ssl-open timeout effective in golang c...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1341 Actually if I merge my docker PR it'll clean that up, let me do that and then you can rebase your changes on master to get a better build. ---
[jira] [Commented] (THRIFT-4307) Make ssl-open timeout effective in golang client
[
https://issues.apache.org/jira/browse/THRIFT-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153004#comment-16153004
]
ASF GitHub Bot commented on THRIFT-4307:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1341
Actually if I merge my docker PR it'll clean that up, let me do that and
then you can rebase your changes on master to get a better build.
> Make ssl-open timeout effective in golang client
>
>
> Key: THRIFT-4307
> URL: https://issues.apache.org/jira/browse/THRIFT-4307
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: tudyzhb
> Fix For: 0.10.0, 0.11.0
>
>
> {code:go}
> package rpc
> import (
> "git.apache.org/thrift.git/lib/go/thrift"
> "crypto/tls"
> "time"
> )
> func open() {
> var (
> addr = "192.168.1.100:4000"
> timeout = time.Second * 10
> transportFactory = thrift.NewTTransportFactory()
> transportthrift.TTransport
> err error
> )
> // timeout work in normal socket
> if transport, err = thrift.NewTSocketTimeout(addr, timeout); err != nil
> {
> return
> }
> // timeout not work in SSL Socket
> if transport, err = thrift.NewTSSLSocketTimeout(addr, &tls.Config{
> InsecureSkipVerify: true,
> }, timeout); err != nil {
> return
> }
> transport = transportFactory.GetTransport(transport)
> }
> {code}
--
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 asfgit closed the pull request at: https://github.com/apache/thrift/pull/1340 ---
[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=16153006#comment-16153006
]
ASF GitHub Bot commented on THRIFT-4295:
Github user asfgit closed the pull request at:
https://github.com/apache/thrift/pull/1340
> 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)
[jira] [Resolved] (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:all-tabpanel
]
James E. King, III resolved THRIFT-4295.
Resolution: Fixed
Fix Version/s: 0.11.0
> 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 issue #1341: THRIFT-4307: Make ssl-open timeout effective in golang c...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1341 @tudyzhb if you do rebase on the current master you'll get the fixes from THRIFT-4295 which I just committed and then force push to kick a new build with your change in it. ---
[jira] [Commented] (THRIFT-4307) Make ssl-open timeout effective in golang client
[
https://issues.apache.org/jira/browse/THRIFT-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153009#comment-16153009
]
ASF GitHub Bot commented on THRIFT-4307:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1341
@tudyzhb if you do rebase on the current master you'll get the fixes from
THRIFT-4295 which I just committed and then force push to kick a new build with
your change in it.
> Make ssl-open timeout effective in golang client
>
>
> Key: THRIFT-4307
> URL: https://issues.apache.org/jira/browse/THRIFT-4307
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.10.0, 0.11.0
>Reporter: tudyzhb
> Fix For: 0.10.0, 0.11.0
>
>
> {code:go}
> package rpc
> import (
> "git.apache.org/thrift.git/lib/go/thrift"
> "crypto/tls"
> "time"
> )
> func open() {
> var (
> addr = "192.168.1.100:4000"
> timeout = time.Second * 10
> transportFactory = thrift.NewTTransportFactory()
> transportthrift.TTransport
> err error
> )
> // timeout work in normal socket
> if transport, err = thrift.NewTSocketTimeout(addr, timeout); err != nil
> {
> return
> }
> // timeout not work in SSL Socket
> if transport, err = thrift.NewTSSLSocketTimeout(addr, &tls.Config{
> InsecureSkipVerify: true,
> }, timeout); err != nil {
> return
> }
> transport = transportFactory.GetTransport(transport)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1339: Python print() function
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1339 I'm not certain I see what the purpose of this set of changes is (then again, I don't use python much). Perhaps if you open a Jira ticket and explain the reasoning for these changes it would help. ---
[GitHub] thrift issue #1337: THRIFT-4292: Implement TimerManager::remove()
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1337 Try rebasing on the current master to get a cleaner CI build, and force push to kick a new one here. ---
[jira] [Commented] (THRIFT-4292) TimerManager::remove() is not implemented
[ https://issues.apache.org/jira/browse/THRIFT-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153013#comment-16153013 ] ASF GitHub Bot commented on THRIFT-4292: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1337 Try rebasing on the current master to get a cleaner CI build, and force push to kick a new one here. > TimerManager::remove() is not implemented > - > > Key: THRIFT-4292 > URL: https://issues.apache.org/jira/browse/THRIFT-4292 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Reporter: Francois Ferrand > > The function is currently not implemented. > This is not critical for Thrift, since it is not used there, but prevents > using it in thrift-based code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1336: configure.ac, Makefile.am: introduce THRIFT variable to ...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1336 Wouldn't we want the value in configure.ac to percolate through? Why override it in every Makefile.am? ---
[GitHub] thrift pull request #1308: THRIFT-4247: Fix compilation with OpenSSL 1.1
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1308 ---
[jira] [Resolved] (THRIFT-4247) Compile fails with openssl 1.1
[ https://issues.apache.org/jira/browse/THRIFT-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4247. Resolution: Fixed Assignee: James E. King, III Fix Version/s: 0.11.0 > Compile fails with openssl 1.1 > -- > > Key: THRIFT-4247 > URL: https://issues.apache.org/jira/browse/THRIFT-4247 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Josip Sokcevic >Assignee: James E. King, III > Fix For: 0.11.0 > > Attachments: 0001-THRIFT-4247-Fix-compilation-with-OpenSSL-1.1.patch > > > Many structures in OpenSSL 1.1 are made opaque. Moreover, name field has been > removed with OpenSSL commit 359aa38fbeecd920a60c739c64cda06fe295684f -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4247) Compile fails with openssl 1.1
[ https://issues.apache.org/jira/browse/THRIFT-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153016#comment-16153016 ] ASF GitHub Bot commented on THRIFT-4247: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1308 > Compile fails with openssl 1.1 > -- > > Key: THRIFT-4247 > URL: https://issues.apache.org/jira/browse/THRIFT-4247 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Josip Sokcevic >Assignee: James E. King, III > Fix For: 0.11.0 > > Attachments: 0001-THRIFT-4247-Fix-compilation-with-OpenSSL-1.1.patch > > > Many structures in OpenSSL 1.1 are made opaque. Moreover, name field has been > removed with OpenSSL commit 359aa38fbeecd920a60c739c64cda06fe295684f -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1324: THRIFT-4275
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1324 @sunnypig just a reminder one thing was missed and needs to be updated - see my last comment, at the very least updating the command registration so the option appears in compiler help is mandatory - also recommend you rebase on master to get a clean build from CI. ---
[jira] [Commented] (THRIFT-4275) Add support for zope.interface only, apart from twisted support.
[ https://issues.apache.org/jira/browse/THRIFT-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153018#comment-16153018 ] ASF GitHub Bot commented on THRIFT-4275: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1324 @sunnypig just a reminder one thing was missed and needs to be updated - see my last comment, at the very least updating the command registration so the option appears in compiler help is mandatory - also recommend you rebase on master to get a clean build from CI. > Add support for zope.interface only, apart from twisted support. > > > Key: THRIFT-4275 > URL: https://issues.apache.org/jira/browse/THRIFT-4275 > Project: Thrift > Issue Type: Wish > Components: Python - Compiler >Reporter: Charlie Zhang >Priority: Trivial > Labels: features > > Since twisted depends on zope.interface, each interface we defined in thrift > file will be generated as a class derived from zope.interface if py:twisted > option is enabled. This is great because we can treat implementations of > these interfaces as components which can be registered in zope.component. > However, sometimes we just only want to benefit from Component Object Model > programming which is provided by the combination of zope.interface, > zope.component and even zope.configuration, but not the deferred mechanism > in twisted. So, besides option py:twisted, shall we add an extra option > py:zope.interface ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift pull request #1332: fix error flex command
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1332 ---
[jira] [Created] (THRIFT-4309) All Python files should be compatible with Python 3
cclauss created THRIFT-4309: --- Summary: All Python files should be compatible with Python 3 Key: THRIFT-4309 URL: https://issues.apache.org/jira/browse/THRIFT-4309 Project: Thrift Issue Type: Improvement Components: Python - Compiler, Python - Library Reporter: cclauss Priority: Minor Python 3 is now 8 years old and is the current and future of the language. Examples and other Python files in this project should be compatible with Python 3 and where possible also with Python 2. https://docs.python.org/3/howto/pyporting.html is one of many guides on the topic. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (THRIFT-4310) All builds have failed for the past 24 days
cclauss created THRIFT-4310: --- Summary: All builds have failed for the past 24 days Key: THRIFT-4310 URL: https://issues.apache.org/jira/browse/THRIFT-4310 Project: Thrift Issue Type: Improvement Reporter: cclauss It is difficult to make improvements when the build process is in an unstable state. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4310) All builds have failed for the past 24 days
[ https://issues.apache.org/jira/browse/THRIFT-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] cclauss updated THRIFT-4310: Description: It is difficult to make improvements when the build process is in an unstable state. https://travis-ci.org/apache/thrift/pull_requests was:It is difficult to make improvements when the build process is in an unstable state. > All builds have failed for the past 24 days > --- > > Key: THRIFT-4310 > URL: https://issues.apache.org/jira/browse/THRIFT-4310 > Project: Thrift > Issue Type: Improvement >Reporter: cclauss > > It is difficult to make improvements when the build process is in an unstable > state. > https://travis-ci.org/apache/thrift/pull_requests -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-3932) C++ ThreadManager has a rare termination race
[
https://issues.apache.org/jira/browse/THRIFT-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153036#comment-16153036
]
James E. King, III commented on THRIFT-3932:
This was fixed and released into thrift-0.10.0.
> C++ ThreadManager has a rare termination race
> -
>
> Key: THRIFT-3932
> URL: https://issues.apache.org/jira/browse/THRIFT-3932
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Reporter: Buğra Gedik
>Assignee: James E. King, III
> Fix For: 0.10.0
>
> Attachments: thrift-patch
>
> Time Spent: 17h
> Remaining Estimate: 0h
>
> {{ThreadManger::join}} calls {{stopImpl(true)}}, which in turn calls
> {{removeWorker(workerCount_);}}. The latter waits until {{while (workerCount_
> != workerMaxCount_)}}. Within the {{run}} method of the workers, the last
> thread that detects {{workerCount_ == workerMaxCount_}} notifies
> {{removeWorker}}. The {{run}} method has the following additional code that
> is executed at the very end:
> {code}
> {
> Synchronized s(manager_->workerMonitor_);
> manager_->deadWorkers_.insert(this->thread());
> if (notifyManager) {
> manager_->workerMonitor_.notify();
> }
> }
> {code}
> This is an independent synchronized block. Now assume 2 threads. One of them
> has {{notifyManager=true}} as it detected the {{workerCount_ ==
> workerMaxCount_}} condition earlier. It is possible that this thread gets to
> execute the above code block first, {{ThreadManager}}'s {{removeWorker}}
> method unblocks, and eventually {{ThreadManager}}'s {{join}} returns and the
> object is destructed. When the other thread reaches the synchronized block
> above, it will crash, as the manager is not around anymore.
> Besides, {{ThreadManager}} never joins its threads.
> Attached is a patch.
> {panel:title=Resolution
> Details|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> A fair number of things were improved with this pull request:
> # There are three monitors used for signaling; two of them use the same mutex
> and then the workerMonitor is using its own. I made all three use the same
> mutex.
> # I replaced all calls to Synchronize with Guard on the mutex_ so it is a bit
> clearer that there is one lock protecting everything.
> # The worker run loop expires tasks as it encounters them. Now we only call
> removeExpiredTasks if there's no room during add.
> # I found that when worker threads are removed they are not joined; if a
> thread is not detached we now join those threads.
> # I added better documentation and simplified the Worker::run() a little so
> it is easier to understand, but the logic is the same. idle_ was not used and
> removed.
> # I found that remove(Task) simply wasn't implemented at all! so I added code
> for that and tests.
> # Release mode tests of thread manager would not fail on error because they
> use assert() to verify results! If we only do release builds in CI, these
> tests may have been silently failing for a long time.
> # ThreadManager::join() is unnecessary, as stop() will join worker threads
> (as will removeWorker) depending on the ThreadFactory's detached disposition.
> # Cleaned up some technical debt from the TServerFramework refactoring:
> # Cleaned up some things in the different platform thread factories. Some
> abstractions were unnecessary.
> # Reduced overall time on concurrency test to about 30 seconds on my dev
> system while increasing the reliability and improving test coverage
> significantly. I ran it 100 times in a loop.
> # Added tests for most of the ThreadManager APIs.
> # Tested with posix, std, and boost threads on linux.
> # Tested on Windows.
> # Fixed a math error in time calculation that was present on Windows (with
> VS2010) which made expiring tasks impossible (unit test proved the issue and
> the fix).
> # Re-enable unit tests in the appveyor build that are no longer unstable.
> {panel}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-3932) C++ ThreadManager has a rare termination race
[
https://issues.apache.org/jira/browse/THRIFT-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153037#comment-16153037
]
Buğra Gedik commented on THRIFT-3932:
-
Sorry, I commented on the wrong Jira item. I meant to comment on
https://issues.apache.org/jira/browse/THRIFT-3891.
> C++ ThreadManager has a rare termination race
> -
>
> Key: THRIFT-3932
> URL: https://issues.apache.org/jira/browse/THRIFT-3932
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Reporter: Buğra Gedik
>Assignee: James E. King, III
> Fix For: 0.10.0
>
> Attachments: thrift-patch
>
> Time Spent: 17h
> Remaining Estimate: 0h
>
> {{ThreadManger::join}} calls {{stopImpl(true)}}, which in turn calls
> {{removeWorker(workerCount_);}}. The latter waits until {{while (workerCount_
> != workerMaxCount_)}}. Within the {{run}} method of the workers, the last
> thread that detects {{workerCount_ == workerMaxCount_}} notifies
> {{removeWorker}}. The {{run}} method has the following additional code that
> is executed at the very end:
> {code}
> {
> Synchronized s(manager_->workerMonitor_);
> manager_->deadWorkers_.insert(this->thread());
> if (notifyManager) {
> manager_->workerMonitor_.notify();
> }
> }
> {code}
> This is an independent synchronized block. Now assume 2 threads. One of them
> has {{notifyManager=true}} as it detected the {{workerCount_ ==
> workerMaxCount_}} condition earlier. It is possible that this thread gets to
> execute the above code block first, {{ThreadManager}}'s {{removeWorker}}
> method unblocks, and eventually {{ThreadManager}}'s {{join}} returns and the
> object is destructed. When the other thread reaches the synchronized block
> above, it will crash, as the manager is not around anymore.
> Besides, {{ThreadManager}} never joins its threads.
> Attached is a patch.
> {panel:title=Resolution
> Details|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> A fair number of things were improved with this pull request:
> # There are three monitors used for signaling; two of them use the same mutex
> and then the workerMonitor is using its own. I made all three use the same
> mutex.
> # I replaced all calls to Synchronize with Guard on the mutex_ so it is a bit
> clearer that there is one lock protecting everything.
> # The worker run loop expires tasks as it encounters them. Now we only call
> removeExpiredTasks if there's no room during add.
> # I found that when worker threads are removed they are not joined; if a
> thread is not detached we now join those threads.
> # I added better documentation and simplified the Worker::run() a little so
> it is easier to understand, but the logic is the same. idle_ was not used and
> removed.
> # I found that remove(Task) simply wasn't implemented at all! so I added code
> for that and tests.
> # Release mode tests of thread manager would not fail on error because they
> use assert() to verify results! If we only do release builds in CI, these
> tests may have been silently failing for a long time.
> # ThreadManager::join() is unnecessary, as stop() will join worker threads
> (as will removeWorker) depending on the ThreadFactory's detached disposition.
> # Cleaned up some technical debt from the TServerFramework refactoring:
> # Cleaned up some things in the different platform thread factories. Some
> abstractions were unnecessary.
> # Reduced overall time on concurrency test to about 30 seconds on my dev
> system while increasing the reliability and improving test coverage
> significantly. I ran it 100 times in a loop.
> # Added tests for most of the ThreadManager APIs.
> # Tested with posix, std, and boost threads on linux.
> # Tested on Windows.
> # Fixed a math error in time calculation that was present on Windows (with
> VS2010) which made expiring tasks impossible (unit test proved the issue and
> the fix).
> # Re-enable unit tests in the appveyor build that are no longer unstable.
> {panel}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-3932) C++ ThreadManager has a rare termination race
[
https://issues.apache.org/jira/browse/THRIFT-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153061#comment-16153061
]
James E. King, III commented on THRIFT-3932:
Recommend you send your request to the release mailing list. We seem to be on
one release per year right now, and we do need to make that better.
https://thrift.apache.org/mailing
> C++ ThreadManager has a rare termination race
> -
>
> Key: THRIFT-3932
> URL: https://issues.apache.org/jira/browse/THRIFT-3932
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Reporter: Buğra Gedik
>Assignee: James E. King, III
> Fix For: 0.10.0
>
> Attachments: thrift-patch
>
> Time Spent: 17h
> Remaining Estimate: 0h
>
> {{ThreadManger::join}} calls {{stopImpl(true)}}, which in turn calls
> {{removeWorker(workerCount_);}}. The latter waits until {{while (workerCount_
> != workerMaxCount_)}}. Within the {{run}} method of the workers, the last
> thread that detects {{workerCount_ == workerMaxCount_}} notifies
> {{removeWorker}}. The {{run}} method has the following additional code that
> is executed at the very end:
> {code}
> {
> Synchronized s(manager_->workerMonitor_);
> manager_->deadWorkers_.insert(this->thread());
> if (notifyManager) {
> manager_->workerMonitor_.notify();
> }
> }
> {code}
> This is an independent synchronized block. Now assume 2 threads. One of them
> has {{notifyManager=true}} as it detected the {{workerCount_ ==
> workerMaxCount_}} condition earlier. It is possible that this thread gets to
> execute the above code block first, {{ThreadManager}}'s {{removeWorker}}
> method unblocks, and eventually {{ThreadManager}}'s {{join}} returns and the
> object is destructed. When the other thread reaches the synchronized block
> above, it will crash, as the manager is not around anymore.
> Besides, {{ThreadManager}} never joins its threads.
> Attached is a patch.
> {panel:title=Resolution
> Details|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> A fair number of things were improved with this pull request:
> # There are three monitors used for signaling; two of them use the same mutex
> and then the workerMonitor is using its own. I made all three use the same
> mutex.
> # I replaced all calls to Synchronize with Guard on the mutex_ so it is a bit
> clearer that there is one lock protecting everything.
> # The worker run loop expires tasks as it encounters them. Now we only call
> removeExpiredTasks if there's no room during add.
> # I found that when worker threads are removed they are not joined; if a
> thread is not detached we now join those threads.
> # I added better documentation and simplified the Worker::run() a little so
> it is easier to understand, but the logic is the same. idle_ was not used and
> removed.
> # I found that remove(Task) simply wasn't implemented at all! so I added code
> for that and tests.
> # Release mode tests of thread manager would not fail on error because they
> use assert() to verify results! If we only do release builds in CI, these
> tests may have been silently failing for a long time.
> # ThreadManager::join() is unnecessary, as stop() will join worker threads
> (as will removeWorker) depending on the ThreadFactory's detached disposition.
> # Cleaned up some technical debt from the TServerFramework refactoring:
> # Cleaned up some things in the different platform thread factories. Some
> abstractions were unnecessary.
> # Reduced overall time on concurrency test to about 30 seconds on my dev
> system while increasing the reliability and improving test coverage
> significantly. I ran it 100 times in a loop.
> # Added tests for most of the ThreadManager APIs.
> # Tested with posix, std, and boost threads on linux.
> # Tested on Windows.
> # Fixed a math error in time calculation that was present on Windows (with
> VS2010) which made expiring tasks impossible (unit test proved the issue and
> the fix).
> # Re-enable unit tests in the appveyor build that are no longer unstable.
> {panel}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift issue #1322: THRIFT-4246 Multiplexed clients sequence id fix
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1322 Hmm, well I tried to rebase this on master and push it back into your branch so it would build again but I cannot - no permission. So, I'm running cross test in the xenial docker image locally and if it passes I will merge it into master. ---
[jira] [Commented] (THRIFT-4246) Sequence number mismatch on multiplexed clients
[
https://issues.apache.org/jira/browse/THRIFT-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153072#comment-16153072
]
ASF GitHub Bot commented on THRIFT-4246:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1322
Hmm, well I tried to rebase this on master and push it back into your
branch so it would build again but I cannot - no permission. So, I'm running
cross test in the xenial docker image locally and if it passes I will merge it
into master.
> Sequence number mismatch on multiplexed clients
> ---
>
> Key: THRIFT-4246
> URL: https://issues.apache.org/jira/browse/THRIFT-4246
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.10.0
>Reporter: Victor Boivie
>Priority: Critical
> Attachments:
> 0001-THRIFT-4246-Multiplexed-clients-sequence-id-fix.patch
>
>
> When performing calls using a multiplexed client and when having multiple
> connections and clients, the wrong sequence numbers are used which will often
> result in responses not being able to be delivered to the client. This is
> because every connection will make the client class (not instance) use the
> latest created multiplexer class to generate sequence numbers. The following
> example shows the problem:
> {code:javascript}
> const thrift = require('thrift');
> const AlphaService = require('./gen-nodejs/AlphaService');
> const BetaService = require('./gen-nodejs/BetaService');
> let connection1 = thrift.createConnection('localhost', 9091, {
> transport: thrift.TFrameTransport,
> protocol: thrift.TCompactProtocol,
> });
> let multiplexer1 = new thrift.Multiplexer();
> let alpha1 = multiplexer1.createClient('alpha', AlphaService, connection1);
> let beta1 = multiplexer1.createClient('beta', BetaService, connection1);
> alpha1.echoAlpha("hello")
> let connection2 = thrift.createConnection('localhost', 9091, {
> transport: thrift.TFrameTransport,
> protocol: thrift.TCompactProtocol,
> });
> let multiplexer2 = new thrift.Multiplexer();
> let alpha2 = multiplexer2.createClient('alpha', AlphaService, connection2);
> let beta2 = multiplexer2.createClient('beta', BetaService, connection2);
> beta1.echoBeta("Hi")
> beta2.echoBeta("hello")
> console.log("alpha1 seqId", alpha1._seqid)
> console.log("beta1 seqId", beta1._seqid)
> console.log("beta2 seqId", beta2._seqid)
> console.log("multiplexer1 latest", multiplexer1.seqid)
> console.log("multiplexer2 latest", multiplexer2.seqid)
> console.log("connection1 mapping", connection1.seqId2Service)
> console.log("connection2 mapping", connection2.seqId2Service)
> {code}
> Result:
> {noformat}
> alpha1 seqId 1
> beta1 seqId 1
> beta2 seqId 2
> multiplexer1 latest 1
> multiplexer2 latest 2
> connection1 mapping { '1': 'beta' }
> connection2 mapping { '2': 'beta' }
> {noformat}
> Connection1 should have mapping 1 -> alpha, 2-> beta
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (THRIFT-4246) Sequence number mismatch on multiplexed clients
[
https://issues.apache.org/jira/browse/THRIFT-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III reassigned THRIFT-4246:
--
Assignee: James E. King, III
> Sequence number mismatch on multiplexed clients
> ---
>
> Key: THRIFT-4246
> URL: https://issues.apache.org/jira/browse/THRIFT-4246
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.10.0
>Reporter: Victor Boivie
>Assignee: James E. King, III
>Priority: Critical
> Attachments:
> 0001-THRIFT-4246-Multiplexed-clients-sequence-id-fix.patch
>
>
> When performing calls using a multiplexed client and when having multiple
> connections and clients, the wrong sequence numbers are used which will often
> result in responses not being able to be delivered to the client. This is
> because every connection will make the client class (not instance) use the
> latest created multiplexer class to generate sequence numbers. The following
> example shows the problem:
> {code:javascript}
> const thrift = require('thrift');
> const AlphaService = require('./gen-nodejs/AlphaService');
> const BetaService = require('./gen-nodejs/BetaService');
> let connection1 = thrift.createConnection('localhost', 9091, {
> transport: thrift.TFrameTransport,
> protocol: thrift.TCompactProtocol,
> });
> let multiplexer1 = new thrift.Multiplexer();
> let alpha1 = multiplexer1.createClient('alpha', AlphaService, connection1);
> let beta1 = multiplexer1.createClient('beta', BetaService, connection1);
> alpha1.echoAlpha("hello")
> let connection2 = thrift.createConnection('localhost', 9091, {
> transport: thrift.TFrameTransport,
> protocol: thrift.TCompactProtocol,
> });
> let multiplexer2 = new thrift.Multiplexer();
> let alpha2 = multiplexer2.createClient('alpha', AlphaService, connection2);
> let beta2 = multiplexer2.createClient('beta', BetaService, connection2);
> beta1.echoBeta("Hi")
> beta2.echoBeta("hello")
> console.log("alpha1 seqId", alpha1._seqid)
> console.log("beta1 seqId", beta1._seqid)
> console.log("beta2 seqId", beta2._seqid)
> console.log("multiplexer1 latest", multiplexer1.seqid)
> console.log("multiplexer2 latest", multiplexer2.seqid)
> console.log("connection1 mapping", connection1.seqId2Service)
> console.log("connection2 mapping", connection2.seqId2Service)
> {code}
> Result:
> {noformat}
> alpha1 seqId 1
> beta1 seqId 1
> beta2 seqId 2
> multiplexer1 latest 1
> multiplexer2 latest 2
> connection1 mapping { '1': 'beta' }
> connection2 mapping { '2': 'beta' }
> {noformat}
> Connection1 should have mapping 1 -> alpha, 2-> beta
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift pull request #1322: THRIFT-4246 Multiplexed clients sequence id fix
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1322 ---
[jira] [Commented] (THRIFT-4246) Sequence number mismatch on multiplexed clients
[
https://issues.apache.org/jira/browse/THRIFT-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153101#comment-16153101
]
ASF GitHub Bot commented on THRIFT-4246:
Github user asfgit closed the pull request at:
https://github.com/apache/thrift/pull/1322
> Sequence number mismatch on multiplexed clients
> ---
>
> Key: THRIFT-4246
> URL: https://issues.apache.org/jira/browse/THRIFT-4246
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.10.0
>Reporter: Victor Boivie
>Assignee: James E. King, III
>Priority: Critical
> Fix For: 0.11.0
>
> Attachments:
> 0001-THRIFT-4246-Multiplexed-clients-sequence-id-fix.patch
>
>
> When performing calls using a multiplexed client and when having multiple
> connections and clients, the wrong sequence numbers are used which will often
> result in responses not being able to be delivered to the client. This is
> because every connection will make the client class (not instance) use the
> latest created multiplexer class to generate sequence numbers. The following
> example shows the problem:
> {code:javascript}
> const thrift = require('thrift');
> const AlphaService = require('./gen-nodejs/AlphaService');
> const BetaService = require('./gen-nodejs/BetaService');
> let connection1 = thrift.createConnection('localhost', 9091, {
> transport: thrift.TFrameTransport,
> protocol: thrift.TCompactProtocol,
> });
> let multiplexer1 = new thrift.Multiplexer();
> let alpha1 = multiplexer1.createClient('alpha', AlphaService, connection1);
> let beta1 = multiplexer1.createClient('beta', BetaService, connection1);
> alpha1.echoAlpha("hello")
> let connection2 = thrift.createConnection('localhost', 9091, {
> transport: thrift.TFrameTransport,
> protocol: thrift.TCompactProtocol,
> });
> let multiplexer2 = new thrift.Multiplexer();
> let alpha2 = multiplexer2.createClient('alpha', AlphaService, connection2);
> let beta2 = multiplexer2.createClient('beta', BetaService, connection2);
> beta1.echoBeta("Hi")
> beta2.echoBeta("hello")
> console.log("alpha1 seqId", alpha1._seqid)
> console.log("beta1 seqId", beta1._seqid)
> console.log("beta2 seqId", beta2._seqid)
> console.log("multiplexer1 latest", multiplexer1.seqid)
> console.log("multiplexer2 latest", multiplexer2.seqid)
> console.log("connection1 mapping", connection1.seqId2Service)
> console.log("connection2 mapping", connection2.seqId2Service)
> {code}
> Result:
> {noformat}
> alpha1 seqId 1
> beta1 seqId 1
> beta2 seqId 2
> multiplexer1 latest 1
> multiplexer2 latest 2
> connection1 mapping { '1': 'beta' }
> connection2 mapping { '2': 'beta' }
> {noformat}
> Connection1 should have mapping 1 -> alpha, 2-> beta
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (THRIFT-4246) Sequence number mismatch on multiplexed clients
[
https://issues.apache.org/jira/browse/THRIFT-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-4246.
Resolution: Fixed
Fix Version/s: 0.11.0
> Sequence number mismatch on multiplexed clients
> ---
>
> Key: THRIFT-4246
> URL: https://issues.apache.org/jira/browse/THRIFT-4246
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.10.0
>Reporter: Victor Boivie
>Assignee: James E. King, III
>Priority: Critical
> Fix For: 0.11.0
>
> Attachments:
> 0001-THRIFT-4246-Multiplexed-clients-sequence-id-fix.patch
>
>
> When performing calls using a multiplexed client and when having multiple
> connections and clients, the wrong sequence numbers are used which will often
> result in responses not being able to be delivered to the client. This is
> because every connection will make the client class (not instance) use the
> latest created multiplexer class to generate sequence numbers. The following
> example shows the problem:
> {code:javascript}
> const thrift = require('thrift');
> const AlphaService = require('./gen-nodejs/AlphaService');
> const BetaService = require('./gen-nodejs/BetaService');
> let connection1 = thrift.createConnection('localhost', 9091, {
> transport: thrift.TFrameTransport,
> protocol: thrift.TCompactProtocol,
> });
> let multiplexer1 = new thrift.Multiplexer();
> let alpha1 = multiplexer1.createClient('alpha', AlphaService, connection1);
> let beta1 = multiplexer1.createClient('beta', BetaService, connection1);
> alpha1.echoAlpha("hello")
> let connection2 = thrift.createConnection('localhost', 9091, {
> transport: thrift.TFrameTransport,
> protocol: thrift.TCompactProtocol,
> });
> let multiplexer2 = new thrift.Multiplexer();
> let alpha2 = multiplexer2.createClient('alpha', AlphaService, connection2);
> let beta2 = multiplexer2.createClient('beta', BetaService, connection2);
> beta1.echoBeta("Hi")
> beta2.echoBeta("hello")
> console.log("alpha1 seqId", alpha1._seqid)
> console.log("beta1 seqId", beta1._seqid)
> console.log("beta2 seqId", beta2._seqid)
> console.log("multiplexer1 latest", multiplexer1.seqid)
> console.log("multiplexer2 latest", multiplexer2.seqid)
> console.log("connection1 mapping", connection1.seqId2Service)
> console.log("connection2 mapping", connection2.seqId2Service)
> {code}
> Result:
> {noformat}
> alpha1 seqId 1
> beta1 seqId 1
> beta2 seqId 2
> multiplexer1 latest 1
> multiplexer2 latest 2
> connection1 mapping { '1': 'beta' }
> connection2 mapping { '2': 'beta' }
> {noformat}
> Connection1 should have mapping 1 -> alpha, 2-> beta
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] thrift pull request #1335: Add default message for TApplicationException
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1335#discussion_r136895273
--- Diff: lib/go/thrift/application_exception.go ---
@@ -30,6 +30,17 @@ const (
PROTOCOL_ERROR = 7
)
+var defaultApplicationExceptionMessage = map[int32]string{
+ UNKNOWN_APPLICATION_EXCEPTION: "unknown application exception",
+ UNKNOWN_METHOD: "unknown method",
+ INVALID_MESSAGE_TYPE_EXCEPTION: "invalid message type",
+ WRONG_METHOD_NAME: "wrong method name",
+ BAD_SEQUENCE_ID:"bad sequnce ID",
--- End diff --
Typo in the string
---
[GitHub] thrift issue #1335: Add default message for TApplicationException
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1335 Would it perhaps make sense to change the const list into something that can simply be generated using stringer, and therefore it would always be automatic? https://godoc.org/golang.org/x/tools/cmd/stringer ---
[GitHub] thrift issue #1335: Add default message for TApplicationException
Github user damnever commented on the issue: https://github.com/apache/thrift/pull/1335 Type alias is not comparable, would it cause incompatibility problems? ---
