[GitHub] thrift issue #1191: THRIFT-3706 - Implement multiplexor.
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1191 Did you see that the test is working against Java? If you try a connection with and without multiplexed in one of the ends the connection doesn't work. The only way to see if the data is sent correctly is by using wireshark and see how the prefix is automatically added to the service. And processed in the server end. What do you need to merge? --- 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-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874182#comment-15874182 ] ASF GitHub Bot commented on THRIFT-3706: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1191 Did you see that the test is working against Java? If you try a connection with and without multiplexed in one of the ends the connection doesn't work. The only way to see if the data is sent correctly is by using wireshark and see how the prefix is automatically added to the service. And processed in the server end. What do you need to merge? > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1156: THRIFT-4011 Use slices for Thrift sets
Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1156 @Jens-G All tests green and rebased from master. --- 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-4011) Sets of Thrift structs generate Go code that can't be serialized to JSON
[
https://issues.apache.org/jira/browse/THRIFT-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874483#comment-15874483
]
ASF GitHub Bot commented on THRIFT-4011:
Github user dcelasun commented on the issue:
https://github.com/apache/thrift/pull/1156
@Jens-G All tests green and rebased from master.
> Sets of Thrift structs generate Go code that can't be serialized to JSON
>
>
> Key: THRIFT-4011
> URL: https://issues.apache.org/jira/browse/THRIFT-4011
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Reporter: Can Celasun
>
> Consider the following structs:
> {code}
> struct Foo {
> 1: optional string foo
> }
> struct Bar {
> 1: optional set foos
> }
> {code}
> This compiles into the following Go code:
> {code}
> type Bar struct {
> Foos map[*Foo]struct{} `thrift:"foos,1" db:"foos" json:"foos,omitempty"`
> }
> {code}
> Even though the generated code has tags for JSON support, Bar can't be
> serialized to JSON:
> {code}
> json: unsupported type: map[*Foo]struct {}
> {code}
> One solution would be to use slices, not maps, for Thrift sets. Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1198: THRIFT-4077: fix Appveyor warnings (VS2015) in Pl...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1198 --- 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. ---
[GitHub] thrift pull request #1162: THRIFT-3973: Provide some tools to make it easier...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1162 --- 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-3973) Remove MSVC C++ projects to improve maintainability; document building Thrift on Windows using CMake to generate project files
[ https://issues.apache.org/jira/browse/THRIFT-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874503#comment-15874503 ] ASF GitHub Bot commented on THRIFT-3973: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1162 > Remove MSVC C++ projects to improve maintainability; document building Thrift > on Windows using CMake to generate project files > -- > > Key: THRIFT-3973 > URL: https://issues.apache.org/jira/browse/THRIFT-3973 > Project: Thrift > Issue Type: Story > Components: C++ - Compiler, C++ - Library >Affects Versions: 0.10.0 > Environment: Windows >Reporter: James E. King, III >Assignee: James E. King, III > > A class of issues has popped up where the project files checked into the > project have become stale and/or the instructions for building on windows > need to be updated. > These issues are linked to this item. The purpose of this story is to > eliminate these issues by getting rid of the project files checked into the > project for windows (C++ specifically) and to update the web site > documentation on how to build the thrift libraries for windows (native, not > MinGW - those instructions will remain as-is). > Acceptance Criteria: > # Instructions for, and supporting tools (if any) are provided by the > project. This must include support for: > ## Compiler executable builds in debug and release form > ## Static library builds in debug and release form (due to DLL export issues, > windows builds do not support dynamic library generation today) > ## Support for optional library support like zlib, libevent, boost, std > (threads) > ## Support for MSVC 2010 or later > ## Support for CMake 3.6 or later > # MSVC project files for C++ are removed from the project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4077) AI_ADDRCONFIG redefined after recent change to PlatformSocket header
[
https://issues.apache.org/jira/browse/THRIFT-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874502#comment-15874502
]
ASF GitHub Bot commented on THRIFT-4077:
Github user asfgit closed the pull request at:
https://github.com/apache/thrift/pull/1198
> AI_ADDRCONFIG redefined after recent change to PlatformSocket header
>
>
> Key: THRIFT-4077
> URL: https://issues.apache.org/jira/browse/THRIFT-4077
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Appveyor CI
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.11.0
>
>
> {noformat}
> C:\Program Files (x86)\Windows Kits\8.1\Include\shared\ws2def.h(858): warning
> C4005: 'AI_ADDRCONFIG': macro redefinition (compiling source file
> C:\projects\thrift\lib\cpp\src\thrift\server\TThreadPoolServer.cpp)
> [C:\projects\thrift\cmake-build\lib\cpp\thrift_static.vcxproj]
> C:\projects\thrift\lib\cpp\src\thrift/transport/PlatformSocket.h(82): note:
> see previous definition of 'AI_ADDRCONFIG' (compiling source file
> C:\projects\thrift\lib\cpp\src\thrift\server\TThreadPoolServer.cpp)
> TPipe.cpp
> C:\Program Files (x86)\Windows Kits\8.1\Include\shared\ws2def.h(858): warning
> C4005: 'AI_ADDRCONFIG': macro redefinition (compiling source file
> C:\projects\thrift\lib\cpp\src\thrift\server\TThreadedServer.cpp)
> [C:\projects\thrift\cmake-build\lib\cpp\thrift_static.vcxproj]
> C:\projects\thrift\lib\cpp\src\thrift/transport/PlatformSocket.h(82): note:
> see previous definition of 'AI_ADDRCONFIG' (compiling source file
> C:\projects\thrift\lib\cpp\src\thrift\server\TThreadedServer.cpp)
> C:\Program Files (x86)\Windows Kits\8.1\Include\shared\ws2def.h(858): warning
> C4005: 'AI_ADDRCONFIG': macro redefinition (compiling source file
> C:\projects\thrift\lib\cpp\src\thrift\transport\TPipe.cpp)
> [C:\projects\thrift\cmake-build\lib\cpp\thrift_static.vcxproj]
> {noformat}
> from Appveyor CI build:
> https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/build/951
> It looks like we need to include the correct winsock header before we
> determine if AI_ADDRCONFIG needs to be defined.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (THRIFT-4077) AI_ADDRCONFIG redefined after recent change to PlatformSocket header
[
https://issues.apache.org/jira/browse/THRIFT-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-4077.
Resolution: Fixed
Fix Version/s: 0.11.0
> AI_ADDRCONFIG redefined after recent change to PlatformSocket header
>
>
> Key: THRIFT-4077
> URL: https://issues.apache.org/jira/browse/THRIFT-4077
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Appveyor CI
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.11.0
>
>
> {noformat}
> C:\Program Files (x86)\Windows Kits\8.1\Include\shared\ws2def.h(858): warning
> C4005: 'AI_ADDRCONFIG': macro redefinition (compiling source file
> C:\projects\thrift\lib\cpp\src\thrift\server\TThreadPoolServer.cpp)
> [C:\projects\thrift\cmake-build\lib\cpp\thrift_static.vcxproj]
> C:\projects\thrift\lib\cpp\src\thrift/transport/PlatformSocket.h(82): note:
> see previous definition of 'AI_ADDRCONFIG' (compiling source file
> C:\projects\thrift\lib\cpp\src\thrift\server\TThreadPoolServer.cpp)
> TPipe.cpp
> C:\Program Files (x86)\Windows Kits\8.1\Include\shared\ws2def.h(858): warning
> C4005: 'AI_ADDRCONFIG': macro redefinition (compiling source file
> C:\projects\thrift\lib\cpp\src\thrift\server\TThreadedServer.cpp)
> [C:\projects\thrift\cmake-build\lib\cpp\thrift_static.vcxproj]
> C:\projects\thrift\lib\cpp\src\thrift/transport/PlatformSocket.h(82): note:
> see previous definition of 'AI_ADDRCONFIG' (compiling source file
> C:\projects\thrift\lib\cpp\src\thrift\server\TThreadedServer.cpp)
> C:\Program Files (x86)\Windows Kits\8.1\Include\shared\ws2def.h(858): warning
> C4005: 'AI_ADDRCONFIG': macro redefinition (compiling source file
> C:\projects\thrift\lib\cpp\src\thrift\transport\TPipe.cpp)
> [C:\projects\thrift\cmake-build\lib\cpp\thrift_static.vcxproj]
> {noformat}
> from Appveyor CI build:
> https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/build/951
> It looks like we need to include the correct winsock header before we
> determine if AI_ADDRCONFIG needs to be defined.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1197: THRIFT-4084: Add a SSL/TLS negotiation check to crossfea...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1197 @nsuke this is ready for another review as all the code comments were addressed and we have a clean CI build. --- 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-4084) Improve SSL security in thrift by adding a make cross client that checks to make sure SSLv3 protocol cannot be negotiated
[ https://issues.apache.org/jira/browse/THRIFT-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874515#comment-15874515 ] ASF GitHub Bot commented on THRIFT-4084: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1197 @nsuke this is ready for another review as all the code comments were addressed and we have a clean CI build. > Improve SSL security in thrift by adding a make cross client that checks to > make sure SSLv3 protocol cannot be negotiated > - > > Key: THRIFT-4084 > URL: https://issues.apache.org/jira/browse/THRIFT-4084 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.10.0 > Environment: Ubuntu Dockerfile >Reporter: James E. King, III >Assignee: James E. King, III > Labels: cross-validation, security, ssl, tls > > Following code review discussions in THRIFT-3369, and seeing THRIFT-3165 in > the backlog, I want to add a make cross "language" which isn't a language at > all, but a test that checks to see if it is possible to negotiate at various > SSL/TLS protocol versions. This would be a client-only test, likely just a > bash script that leverages the openssl client and command line options to > connect to a test server and see if it handshakes and negotiates protocol > successfully. > Without THRIFT-3165 implemented, it will ensure: > * Can handshake using the universal SSLv23 context, however cannot negotiate > SSLv3 > * Can negotiate TLSv1.0, TLSv1.1, and TLSv1.2 > With THRIFT-3165 it needs to change to ensure: > * Can handshake using TLSv1.2 but not any other version > The solution I came up with was to add a new client called "secure" to make > crosstest. test_secure is a simple bash script that checks the appropriate > rules above (the ones without THRIFT-3165, since it is not done), and I added > "secure" to the list of cross test "languages" in the top level configure > script. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1197: THRIFT-4084: Add a SSL/TLS negotiation check to c...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1197 --- 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] [Resolved] (THRIFT-4084) Improve SSL security in thrift by adding a make cross client that checks to make sure SSLv3 protocol cannot be negotiated
[ https://issues.apache.org/jira/browse/THRIFT-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4084. Resolution: Fixed Fix Version/s: 0.11.0 > Improve SSL security in thrift by adding a make cross client that checks to > make sure SSLv3 protocol cannot be negotiated > - > > Key: THRIFT-4084 > URL: https://issues.apache.org/jira/browse/THRIFT-4084 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.10.0 > Environment: Ubuntu Dockerfile >Reporter: James E. King, III >Assignee: James E. King, III > Labels: cross-validation, security, ssl, tls > Fix For: 0.11.0 > > > Following code review discussions in THRIFT-3369, and seeing THRIFT-3165 in > the backlog, I want to add a make cross "language" which isn't a language at > all, but a test that checks to see if it is possible to negotiate at various > SSL/TLS protocol versions. This would be a client-only test, likely just a > bash script that leverages the openssl client and command line options to > connect to a test server and see if it handshakes and negotiates protocol > successfully. > Without THRIFT-3165 implemented, it will ensure: > * Can handshake using the universal SSLv23 context, however cannot negotiate > SSLv3 > * Can negotiate TLSv1.0, TLSv1.1, and TLSv1.2 > With THRIFT-3165 it needs to change to ensure: > * Can handshake using TLSv1.2 but not any other version > The solution I came up with was to add a new client called "secure" to make > crosstest. test_secure is a simple bash script that checks the appropriate > rules above (the ones without THRIFT-3165, since it is not done), and I added > "secure" to the list of cross test "languages" in the top level configure > script. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4084) Improve SSL security in thrift by adding a make cross client that checks to make sure SSLv3 protocol cannot be negotiated
[ https://issues.apache.org/jira/browse/THRIFT-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874552#comment-15874552 ] ASF GitHub Bot commented on THRIFT-4084: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1197 > Improve SSL security in thrift by adding a make cross client that checks to > make sure SSLv3 protocol cannot be negotiated > - > > Key: THRIFT-4084 > URL: https://issues.apache.org/jira/browse/THRIFT-4084 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.10.0 > Environment: Ubuntu Dockerfile >Reporter: James E. King, III >Assignee: James E. King, III > Labels: cross-validation, security, ssl, tls > Fix For: 0.11.0 > > > Following code review discussions in THRIFT-3369, and seeing THRIFT-3165 in > the backlog, I want to add a make cross "language" which isn't a language at > all, but a test that checks to see if it is possible to negotiate at various > SSL/TLS protocol versions. This would be a client-only test, likely just a > bash script that leverages the openssl client and command line options to > connect to a test server and see if it handshakes and negotiates protocol > successfully. > Without THRIFT-3165 implemented, it will ensure: > * Can handshake using the universal SSLv23 context, however cannot negotiate > SSLv3 > * Can negotiate TLSv1.0, TLSv1.1, and TLSv1.2 > With THRIFT-3165 it needs to change to ensure: > * Can handshake using TLSv1.2 but not any other version > The solution I came up with was to add a new client called "secure" to make > crosstest. test_secure is a simple bash script that checks the appropriate > rules above (the ones without THRIFT-3165, since it is not done), and I added > "secure" to the list of cross test "languages" in the top level configure > script. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (THRIFT-4084) Improve SSL security in thrift by adding a make cross client that checks to make sure SSLv3 protocol cannot be negotiated
[ https://issues.apache.org/jira/browse/THRIFT-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-4084: --- Description: Following code review discussions in THRIFT-3369, and seeing THRIFT-3165 in the backlog, I want to add a make cross "language" which isn't a language at all, but a test that checks to see if it is possible to negotiate at various SSL/TLS protocol versions. This would be a client-only test, likely just a bash script that leverages the openssl client and command line options to connect to a test server and see if it handshakes and negotiates protocol successfully. Without THRIFT-3165 implemented, it will ensure: * Can handshake using the universal SSLv23 context, however cannot negotiate SSLv3 * Can negotiate TLSv1.0, TLSv1.1, and TLSv1.2 With THRIFT-3165 it needs to change to ensure: * Can handshake using TLSv1.2 but not any other version The solution I came up with was to add a new client called "secure" to make crosstest. test_secure is a simple bash script that checks the appropriate rules above (the ones without THRIFT-3165, since it is not done), and I added "secure" to the list of cross test "languages" in the top level configure script. After code review, it was moved into crossfeature and split into two parts - one called "nosslv3" checks to make sure the server is not negotiating sslv3. The other called "tls" checks ot make sure the server will negotiate at least one of TLSv1.0, TLSv1.1 or TLSv1.2. was: Following code review discussions in THRIFT-3369, and seeing THRIFT-3165 in the backlog, I want to add a make cross "language" which isn't a language at all, but a test that checks to see if it is possible to negotiate at various SSL/TLS protocol versions. This would be a client-only test, likely just a bash script that leverages the openssl client and command line options to connect to a test server and see if it handshakes and negotiates protocol successfully. Without THRIFT-3165 implemented, it will ensure: * Can handshake using the universal SSLv23 context, however cannot negotiate SSLv3 * Can negotiate TLSv1.0, TLSv1.1, and TLSv1.2 With THRIFT-3165 it needs to change to ensure: * Can handshake using TLSv1.2 but not any other version The solution I came up with was to add a new client called "secure" to make crosstest. test_secure is a simple bash script that checks the appropriate rules above (the ones without THRIFT-3165, since it is not done), and I added "secure" to the list of cross test "languages" in the top level configure script. > Improve SSL security in thrift by adding a make cross client that checks to > make sure SSLv3 protocol cannot be negotiated > - > > Key: THRIFT-4084 > URL: https://issues.apache.org/jira/browse/THRIFT-4084 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.10.0 > Environment: Ubuntu Dockerfile >Reporter: James E. King, III >Assignee: James E. King, III > Labels: cross-validation, security, ssl, tls > Fix For: 0.11.0 > > > Following code review discussions in THRIFT-3369, and seeing THRIFT-3165 in > the backlog, I want to add a make cross "language" which isn't a language at > all, but a test that checks to see if it is possible to negotiate at various > SSL/TLS protocol versions. This would be a client-only test, likely just a > bash script that leverages the openssl client and command line options to > connect to a test server and see if it handshakes and negotiates protocol > successfully. > Without THRIFT-3165 implemented, it will ensure: > * Can handshake using the universal SSLv23 context, however cannot negotiate > SSLv3 > * Can negotiate TLSv1.0, TLSv1.1, and TLSv1.2 > With THRIFT-3165 it needs to change to ensure: > * Can handshake using TLSv1.2 but not any other version > The solution I came up with was to add a new client called "secure" to make > crosstest. test_secure is a simple bash script that checks the appropriate > rules above (the ones without THRIFT-3165, since it is not done), and I added > "secure" to the list of cross test "languages" in the top level configure > script. > After code review, it was moved into crossfeature and split into two parts - > one called "nosslv3" checks to make sure the server is not negotiating sslv3. > The other called "tls" checks ot make sure the server will negotiate at > least one of TLSv1.0, TLSv1.1 or TLSv1.2. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1196: THRIFT-3891 TNonblockingServer configured with more than...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1196 @nsuke this is ready for review again. --- 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-3891) TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()
[
https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874554#comment-15874554
]
ASF GitHub Bot commented on THRIFT-3891:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1196
@nsuke this is ready for review again.
> TNonblockingServer configured with more than one IO threads does not always
> return from serve() upon stop()
> ---
>
> Key: THRIFT-3891
> URL: https://issues.apache.org/jira/browse/THRIFT-3891
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Buğra Gedik
>Assignee: James E. King, III
>Priority: Minor
> Attachments: patch.diff
>
>
> Using {{TNonblockingServer}}, when the number of IO threads is > 1, there is
> race condition in which {{stop()}} does not properly unblock {{serve()}}.
> The problem manifests itself when {{stop()}} is called (obviously from a
> different thread) soon after {{serve()}}.
> The core issue is that, {{event_base_loopbreak()}} is called within the
> {{stop()}} sequence without checking whether the IO thread has actually
> entered its event loop. The documentation of {{event_base_loopbreak()}} says
> (http://www.wangafu.net/~nickm/libevent-book/Ref3_eventloop.html)
> {quote}
> Note also that event_base_loopexit(base,NULL) and event_base_loopbreak(base)
> act differently when no event loop is running: loopexit schedules the next
> instance of the event loop to stop right after the next round of callbacks
> are run (as if it had been invoked with EVLOOP_ONCE) whereas loopbreak only
> stops a currently running loop, and has no effect if the event loop isn’t
> running.
> {quote}
> Attached is a patch (against the released 0.9.3 version of the codebase).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1196: THRIFT-3891 TNonblockingServer configured with mo...
Github user bgedik commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1196#discussion_r102023002
--- Diff: lib/cpp/src/thrift/server/TNonblockingServer.cpp ---
@@ -1566,24 +1562,26 @@ void
TNonblockingIOThread::setCurrentThreadHighPriority(bool value) {
}
void TNonblockingIOThread::run() {
- if (eventBase_ == NULL)
+ if (eventBase_ == NULL) {
registerEvents();
-
- GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
-
+ }
if (useHighPriority_) {
setCurrentThreadHighPriority(true);
}
- // Run libevent engine, never returns, invokes calls to eventHandler
- event_base_loop(eventBase_, 0);
+ if (eventBase_ != NULL)
+ {
+GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
+// Run libevent engine, never returns, invokes calls to eventHandler
+event_base_loop(eventBase_, 0);
- if (useHighPriority_) {
-setCurrentThreadHighPriority(false);
- }
+if (useHighPriority_) {
+ setCurrentThreadHighPriority(false);
+}
- // cleans up our registered events
- cleanupEvents();
+// cleans up our registered events
+cleanupEvents();
+ }
GlobalOutput.printf("TNonblockingServer: IO thread #%d run() done!",
number_);
--- End diff --
Is there any way to control the outputting of these messages? When we run
with TNonblockingServer, we get these output. I couldn't find a way to mask
them.
---
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-3891) TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()
[
https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874559#comment-15874559
]
ASF GitHub Bot commented on THRIFT-3891:
Github user bgedik commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1196#discussion_r102023002
--- Diff: lib/cpp/src/thrift/server/TNonblockingServer.cpp ---
@@ -1566,24 +1562,26 @@ void
TNonblockingIOThread::setCurrentThreadHighPriority(bool value) {
}
void TNonblockingIOThread::run() {
- if (eventBase_ == NULL)
+ if (eventBase_ == NULL) {
registerEvents();
-
- GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
-
+ }
if (useHighPriority_) {
setCurrentThreadHighPriority(true);
}
- // Run libevent engine, never returns, invokes calls to eventHandler
- event_base_loop(eventBase_, 0);
+ if (eventBase_ != NULL)
+ {
+GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
+// Run libevent engine, never returns, invokes calls to eventHandler
+event_base_loop(eventBase_, 0);
- if (useHighPriority_) {
-setCurrentThreadHighPriority(false);
- }
+if (useHighPriority_) {
+ setCurrentThreadHighPriority(false);
+}
- // cleans up our registered events
- cleanupEvents();
+// cleans up our registered events
+cleanupEvents();
+ }
GlobalOutput.printf("TNonblockingServer: IO thread #%d run() done!",
number_);
--- End diff --
Is there any way to control the outputting of these messages? When we run
with TNonblockingServer, we get these output. I couldn't find a way to mask
them.
> TNonblockingServer configured with more than one IO threads does not always
> return from serve() upon stop()
> ---
>
> Key: THRIFT-3891
> URL: https://issues.apache.org/jira/browse/THRIFT-3891
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Buğra Gedik
>Assignee: James E. King, III
>Priority: Minor
> Attachments: patch.diff
>
>
> Using {{TNonblockingServer}}, when the number of IO threads is > 1, there is
> race condition in which {{stop()}} does not properly unblock {{serve()}}.
> The problem manifests itself when {{stop()}} is called (obviously from a
> different thread) soon after {{serve()}}.
> The core issue is that, {{event_base_loopbreak()}} is called within the
> {{stop()}} sequence without checking whether the IO thread has actually
> entered its event loop. The documentation of {{event_base_loopbreak()}} says
> (http://www.wangafu.net/~nickm/libevent-book/Ref3_eventloop.html)
> {quote}
> Note also that event_base_loopexit(base,NULL) and event_base_loopbreak(base)
> act differently when no event loop is running: loopexit schedules the next
> instance of the event loop to stop right after the next round of callbacks
> are run (as if it had been invoked with EVLOOP_ONCE) whereas loopbreak only
> stops a currently running loop, and has no effect if the event loop isn’t
> running.
> {quote}
> Attached is a patch (against the released 0.9.3 version of the codebase).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1196: THRIFT-3891 TNonblockingServer configured with mo...
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1196#discussion_r102025071
--- Diff: lib/cpp/src/thrift/server/TNonblockingServer.cpp ---
@@ -1566,24 +1562,26 @@ void
TNonblockingIOThread::setCurrentThreadHighPriority(bool value) {
}
void TNonblockingIOThread::run() {
- if (eventBase_ == NULL)
+ if (eventBase_ == NULL) {
registerEvents();
-
- GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
-
+ }
if (useHighPriority_) {
setCurrentThreadHighPriority(true);
}
- // Run libevent engine, never returns, invokes calls to eventHandler
- event_base_loop(eventBase_, 0);
+ if (eventBase_ != NULL)
+ {
+GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
+// Run libevent engine, never returns, invokes calls to eventHandler
+event_base_loop(eventBase_, 0);
- if (useHighPriority_) {
-setCurrentThreadHighPriority(false);
- }
+if (useHighPriority_) {
+ setCurrentThreadHighPriority(false);
+}
- // cleans up our registered events
- cleanupEvents();
+// cleans up our registered events
+cleanupEvents();
+ }
GlobalOutput.printf("TNonblockingServer: IO thread #%d run() done!",
number_);
--- End diff --
You can install your own GlobalOutput handler. The hooks should be in the
top level thrift header.
---
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-3891) TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()
[
https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874586#comment-15874586
]
ASF GitHub Bot commented on THRIFT-3891:
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1196#discussion_r102025071
--- Diff: lib/cpp/src/thrift/server/TNonblockingServer.cpp ---
@@ -1566,24 +1562,26 @@ void
TNonblockingIOThread::setCurrentThreadHighPriority(bool value) {
}
void TNonblockingIOThread::run() {
- if (eventBase_ == NULL)
+ if (eventBase_ == NULL) {
registerEvents();
-
- GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
-
+ }
if (useHighPriority_) {
setCurrentThreadHighPriority(true);
}
- // Run libevent engine, never returns, invokes calls to eventHandler
- event_base_loop(eventBase_, 0);
+ if (eventBase_ != NULL)
+ {
+GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
+// Run libevent engine, never returns, invokes calls to eventHandler
+event_base_loop(eventBase_, 0);
- if (useHighPriority_) {
-setCurrentThreadHighPriority(false);
- }
+if (useHighPriority_) {
+ setCurrentThreadHighPriority(false);
+}
- // cleans up our registered events
- cleanupEvents();
+// cleans up our registered events
+cleanupEvents();
+ }
GlobalOutput.printf("TNonblockingServer: IO thread #%d run() done!",
number_);
--- End diff --
You can install your own GlobalOutput handler. The hooks should be in the
top level thrift header.
> TNonblockingServer configured with more than one IO threads does not always
> return from serve() upon stop()
> ---
>
> Key: THRIFT-3891
> URL: https://issues.apache.org/jira/browse/THRIFT-3891
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Buğra Gedik
>Assignee: James E. King, III
>Priority: Minor
> Attachments: patch.diff
>
>
> Using {{TNonblockingServer}}, when the number of IO threads is > 1, there is
> race condition in which {{stop()}} does not properly unblock {{serve()}}.
> The problem manifests itself when {{stop()}} is called (obviously from a
> different thread) soon after {{serve()}}.
> The core issue is that, {{event_base_loopbreak()}} is called within the
> {{stop()}} sequence without checking whether the IO thread has actually
> entered its event loop. The documentation of {{event_base_loopbreak()}} says
> (http://www.wangafu.net/~nickm/libevent-book/Ref3_eventloop.html)
> {quote}
> Note also that event_base_loopexit(base,NULL) and event_base_loopbreak(base)
> act differently when no event loop is running: loopexit schedules the next
> instance of the event loop to stop right after the next round of callbacks
> are run (as if it had been invoked with EVLOOP_ONCE) whereas loopbreak only
> stops a currently running loop, and has no effect if the event loop isn’t
> running.
> {quote}
> Attached is a patch (against the released 0.9.3 version of the codebase).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1196: THRIFT-3891 TNonblockingServer configured with mo...
Github user bgedik commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1196#discussion_r102025490
--- Diff: lib/cpp/src/thrift/server/TNonblockingServer.cpp ---
@@ -1566,24 +1562,26 @@ void
TNonblockingIOThread::setCurrentThreadHighPriority(bool value) {
}
void TNonblockingIOThread::run() {
- if (eventBase_ == NULL)
+ if (eventBase_ == NULL) {
registerEvents();
-
- GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
-
+ }
if (useHighPriority_) {
setCurrentThreadHighPriority(true);
}
- // Run libevent engine, never returns, invokes calls to eventHandler
- event_base_loop(eventBase_, 0);
+ if (eventBase_ != NULL)
+ {
+GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
+// Run libevent engine, never returns, invokes calls to eventHandler
+event_base_loop(eventBase_, 0);
- if (useHighPriority_) {
-setCurrentThreadHighPriority(false);
- }
+if (useHighPriority_) {
+ setCurrentThreadHighPriority(false);
+}
- // cleans up our registered events
- cleanupEvents();
+// cleans up our registered events
+cleanupEvents();
+ }
GlobalOutput.printf("TNonblockingServer: IO thread #%d run() done!",
number_);
--- End diff --
Thanks, but for a message like {{"TNonblockingServer: IO thread #0 run()
done!"}} is there any kind of metadata that tells me if this is a info message
or a warning/error message. It seems to be being output without any information
attached to it. That makes it hard to filter the messages that we consider
unnecessary.
---
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-3891) TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()
[
https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874587#comment-15874587
]
ASF GitHub Bot commented on THRIFT-3891:
Github user bgedik commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1196#discussion_r102025490
--- Diff: lib/cpp/src/thrift/server/TNonblockingServer.cpp ---
@@ -1566,24 +1562,26 @@ void
TNonblockingIOThread::setCurrentThreadHighPriority(bool value) {
}
void TNonblockingIOThread::run() {
- if (eventBase_ == NULL)
+ if (eventBase_ == NULL) {
registerEvents();
-
- GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
-
+ }
if (useHighPriority_) {
setCurrentThreadHighPriority(true);
}
- // Run libevent engine, never returns, invokes calls to eventHandler
- event_base_loop(eventBase_, 0);
+ if (eventBase_ != NULL)
+ {
+GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
+// Run libevent engine, never returns, invokes calls to eventHandler
+event_base_loop(eventBase_, 0);
- if (useHighPriority_) {
-setCurrentThreadHighPriority(false);
- }
+if (useHighPriority_) {
+ setCurrentThreadHighPriority(false);
+}
- // cleans up our registered events
- cleanupEvents();
+// cleans up our registered events
+cleanupEvents();
+ }
GlobalOutput.printf("TNonblockingServer: IO thread #%d run() done!",
number_);
--- End diff --
Thanks, but for a message like {{"TNonblockingServer: IO thread #0 run()
done!"}} is there any kind of metadata that tells me if this is a info message
or a warning/error message. It seems to be being output without any information
attached to it. That makes it hard to filter the messages that we consider
unnecessary.
> TNonblockingServer configured with more than one IO threads does not always
> return from serve() upon stop()
> ---
>
> Key: THRIFT-3891
> URL: https://issues.apache.org/jira/browse/THRIFT-3891
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Buğra Gedik
>Assignee: James E. King, III
>Priority: Minor
> Attachments: patch.diff
>
>
> Using {{TNonblockingServer}}, when the number of IO threads is > 1, there is
> race condition in which {{stop()}} does not properly unblock {{serve()}}.
> The problem manifests itself when {{stop()}} is called (obviously from a
> different thread) soon after {{serve()}}.
> The core issue is that, {{event_base_loopbreak()}} is called within the
> {{stop()}} sequence without checking whether the IO thread has actually
> entered its event loop. The documentation of {{event_base_loopbreak()}} says
> (http://www.wangafu.net/~nickm/libevent-book/Ref3_eventloop.html)
> {quote}
> Note also that event_base_loopexit(base,NULL) and event_base_loopbreak(base)
> act differently when no event loop is running: loopexit schedules the next
> instance of the event loop to stop right after the next round of callbacks
> are run (as if it had been invoked with EVLOOP_ONCE) whereas loopbreak only
> stops a currently running loop, and has no effect if the event loop isn’t
> running.
> {quote}
> Attached is a patch (against the released 0.9.3 version of the codebase).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-3891) TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()
[
https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874588#comment-15874588
]
ASF GitHub Bot commented on THRIFT-3891:
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1196#discussion_r102025979
--- Diff: lib/cpp/src/thrift/server/TNonblockingServer.cpp ---
@@ -1566,24 +1562,26 @@ void
TNonblockingIOThread::setCurrentThreadHighPriority(bool value) {
}
void TNonblockingIOThread::run() {
- if (eventBase_ == NULL)
+ if (eventBase_ == NULL) {
registerEvents();
-
- GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
-
+ }
if (useHighPriority_) {
setCurrentThreadHighPriority(true);
}
- // Run libevent engine, never returns, invokes calls to eventHandler
- event_base_loop(eventBase_, 0);
+ if (eventBase_ != NULL)
+ {
+GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
+// Run libevent engine, never returns, invokes calls to eventHandler
+event_base_loop(eventBase_, 0);
- if (useHighPriority_) {
-setCurrentThreadHighPriority(false);
- }
+if (useHighPriority_) {
+ setCurrentThreadHighPriority(false);
+}
- // cleans up our registered events
- cleanupEvents();
+// cleans up our registered events
+cleanupEvents();
+ }
GlobalOutput.printf("TNonblockingServer: IO thread #%d run() done!",
number_);
--- End diff --
All of these messages were already in the implementation and they do not
appear to have any discrimination as to the severity. My assumption is they
are all meant for "printf style debugging".
> TNonblockingServer configured with more than one IO threads does not always
> return from serve() upon stop()
> ---
>
> Key: THRIFT-3891
> URL: https://issues.apache.org/jira/browse/THRIFT-3891
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Buğra Gedik
>Assignee: James E. King, III
>Priority: Minor
> Attachments: patch.diff
>
>
> Using {{TNonblockingServer}}, when the number of IO threads is > 1, there is
> race condition in which {{stop()}} does not properly unblock {{serve()}}.
> The problem manifests itself when {{stop()}} is called (obviously from a
> different thread) soon after {{serve()}}.
> The core issue is that, {{event_base_loopbreak()}} is called within the
> {{stop()}} sequence without checking whether the IO thread has actually
> entered its event loop. The documentation of {{event_base_loopbreak()}} says
> (http://www.wangafu.net/~nickm/libevent-book/Ref3_eventloop.html)
> {quote}
> Note also that event_base_loopexit(base,NULL) and event_base_loopbreak(base)
> act differently when no event loop is running: loopexit schedules the next
> instance of the event loop to stop right after the next round of callbacks
> are run (as if it had been invoked with EVLOOP_ONCE) whereas loopbreak only
> stops a currently running loop, and has no effect if the event loop isn’t
> running.
> {quote}
> Attached is a patch (against the released 0.9.3 version of the codebase).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1196: THRIFT-3891 TNonblockingServer configured with mo...
Github user jeking3 commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1196#discussion_r102025979
--- Diff: lib/cpp/src/thrift/server/TNonblockingServer.cpp ---
@@ -1566,24 +1562,26 @@ void
TNonblockingIOThread::setCurrentThreadHighPriority(bool value) {
}
void TNonblockingIOThread::run() {
- if (eventBase_ == NULL)
+ if (eventBase_ == NULL) {
registerEvents();
-
- GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
-
+ }
if (useHighPriority_) {
setCurrentThreadHighPriority(true);
}
- // Run libevent engine, never returns, invokes calls to eventHandler
- event_base_loop(eventBase_, 0);
+ if (eventBase_ != NULL)
+ {
+GlobalOutput.printf("TNonblockingServer: IO thread #%d entering
loop...", number_);
+// Run libevent engine, never returns, invokes calls to eventHandler
+event_base_loop(eventBase_, 0);
- if (useHighPriority_) {
-setCurrentThreadHighPriority(false);
- }
+if (useHighPriority_) {
+ setCurrentThreadHighPriority(false);
+}
- // cleans up our registered events
- cleanupEvents();
+// cleans up our registered events
+cleanupEvents();
+ }
GlobalOutput.printf("TNonblockingServer: IO thread #%d run() done!",
number_);
--- End diff --
All of these messages were already in the implementation and they do not
appear to have any discrimination as to the severity. My assumption is they
are all meant for "printf style debugging".
---
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.
---
[GitHub] thrift issue #1191: THRIFT-3706 - Implement multiplexor.
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1191 Discussing with folks who created crosstest what we should do. My preference is to have a single "multiplexed" protocol test that uses the binary protocol. That will be the most widely used combo, and layering multiplexed on top of any other protocol does not test any new functionality of multiplexed; but it might catch strange interactions that we could miss if we don't test all of them. I'm not fond of the explosion of the test matrix, doubling all the tests potentially. If you look in tests.json you will see protocols like "binary" and then "binary:accel", also "compact" and "compact:accelc". This naming format basically says that if crosstest is testing "binary" it will match "binary" and "binary:accel", however the test wll be run once with a --protocol of "binary" and once with a --protocol of "accel". I didn't want to add "binary:multi", "compact:multic", "json:multij", "header:multih" but that would be the logical extension of the pattern that already exists in crosstest. So I'm working on a copy of your branch right now to simplify down to "multiplexed" and then I want to see it run in the crosstest locally. Then once I hear back from some folks we can move forward if they are okay with the simplification. --- 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-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874601#comment-15874601 ] ASF GitHub Bot commented on THRIFT-3706: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1191 Discussing with folks who created crosstest what we should do. My preference is to have a single "multiplexed" protocol test that uses the binary protocol. That will be the most widely used combo, and layering multiplexed on top of any other protocol does not test any new functionality of multiplexed; but it might catch strange interactions that we could miss if we don't test all of them. I'm not fond of the explosion of the test matrix, doubling all the tests potentially. If you look in tests.json you will see protocols like "binary" and then "binary:accel", also "compact" and "compact:accelc". This naming format basically says that if crosstest is testing "binary" it will match "binary" and "binary:accel", however the test wll be run once with a --protocol of "binary" and once with a --protocol of "accel". I didn't want to add "binary:multi", "compact:multic", "json:multij", "header:multih" but that would be the logical extension of the pattern that already exists in crosstest. So I'm working on a copy of your branch right now to simplify down to "multiplexed" and then I want to see it run in the crosstest locally. Then once I hear back from some folks we can move forward if they are okay with the simplification. > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (THRIFT-2504) TMultiplexedProcessor should allow registering default processor called if no service name is present
[ https://issues.apache.org/jira/browse/THRIFT-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-2504: --- Summary: TMultiplexedProcessor should allow registering default processor called if no service name is present (was: I want a server-side upgrade to MultiplexedProtocol to maintain backwards compatibility with older clients) > TMultiplexedProcessor should allow registering default processor called if no > service name is present > - > > Key: THRIFT-2504 > URL: https://issues.apache.org/jira/browse/THRIFT-2504 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Reporter: Aleksey Pesternikov >Assignee: James E. King, III > Fix For: 0.11.0 > > > Multiplexed Protocol provides a number of benefits. It would be useful for a > developer to be able to upgrade a server to use MultiplexedProtocol while > still allowing older clients using BinaryProtocol (or others?) to submit > their older requests and have them processed as they were before the upgrade, > or perhaps at the very least get an exception telling them to upgrade their > client. Right now I believe the behavior of connecting this way is > undefined; correct me if I am wrong. > In THRIFT-66 I handled this by using an unused byte in the VERSION_1 protocol > header which was always initialized to zero, so I made "channel zero" > something that the server side could implement. In that solution however > both ends continued to use BinaryProtocol so it was easy to maintain > backwards compatibility. In this case we have a server speaking > MultiplexedProtocol and a client speaking some other (BinaryProtocol, let's > say). I'm curious what folks who worked on MultiplexedProtocol think about > this notion. > This is one of those changes that would require every language to adopt and > be made part of the core requirements of MultiplexedProtocol if people feel > it is worth it. The alternative is that the developer could continue to run > an older protocol server on the same port that throws an exception telling > the client to upgrade and what port to go to in the message. This isn't > exactly firewall friendly because it needs a new port opened but it is a > possible solution. Thoughts and suggestions welcome as to whether this is > worth doing or we should resolve as won't fix. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (THRIFT-2504) TMultiplexedProcessor should allow registering default processor called if no service name is present
[ https://issues.apache.org/jira/browse/THRIFT-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-2504: --- Description: The original intention of this story was to allow an older client to connect to a multiplexed server and continue to work by having the multiplexed processor handle any request that does not contain a service name and colon prefix. (was: Multiplexed Protocol provides a number of benefits. It would be useful for a developer to be able to upgrade a server to use MultiplexedProtocol while still allowing older clients using BinaryProtocol (or others?) to submit their older requests and have them processed as they were before the upgrade, or perhaps at the very least get an exception telling them to upgrade their client. Right now I believe the behavior of connecting this way is undefined; correct me if I am wrong. In THRIFT-66 I handled this by using an unused byte in the VERSION_1 protocol header which was always initialized to zero, so I made "channel zero" something that the server side could implement. In that solution however both ends continued to use BinaryProtocol so it was easy to maintain backwards compatibility. In this case we have a server speaking MultiplexedProtocol and a client speaking some other (BinaryProtocol, let's say). I'm curious what folks who worked on MultiplexedProtocol think about this notion. This is one of those changes that would require every language to adopt and be made part of the core requirements of MultiplexedProtocol if people feel it is worth it. The alternative is that the developer could continue to run an older protocol server on the same port that throws an exception telling the client to upgrade and what port to go to in the message. This isn't exactly firewall friendly because it needs a new port opened but it is a possible solution. Thoughts and suggestions welcome as to whether this is worth doing or we should resolve as won't fix.) > TMultiplexedProcessor should allow registering default processor called if no > service name is present > - > > Key: THRIFT-2504 > URL: https://issues.apache.org/jira/browse/THRIFT-2504 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Reporter: Aleksey Pesternikov >Assignee: James E. King, III > Fix For: 0.11.0 > > > The original intention of this story was to allow an older client to connect > to a multiplexed server and continue to work by having the multiplexed > processor handle any request that does not contain a service name and colon > prefix. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-2504) TMultiplexedProcessor should allow registering default processor called if no service name is present
[ https://issues.apache.org/jira/browse/THRIFT-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874773#comment-15874773 ] James E. King, III commented on THRIFT-2504: After working on THRIFT-3706 I found that the Multiplexed Protocol wrapper is not compatible with older clients connecting. It has its own protocol header that would not allow a binary client to connect and use the default processor. As such, this change offers no benefit since one must use multiplexed on either end. This should be reverted. > TMultiplexedProcessor should allow registering default processor called if no > service name is present > - > > Key: THRIFT-2504 > URL: https://issues.apache.org/jira/browse/THRIFT-2504 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Reporter: Aleksey Pesternikov >Assignee: James E. King, III > Fix For: 0.11.0 > > > The original intention of this story was to allow an older client to connect > to a multiplexed server and continue to work by having the multiplexed > processor handle any request that does not contain a service name and colon > prefix. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (THRIFT-2504) TMultiplexedProcessor should allow registering default processor called if no service name is present
[ https://issues.apache.org/jira/browse/THRIFT-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reopened THRIFT-2504: > TMultiplexedProcessor should allow registering default processor called if no > service name is present > - > > Key: THRIFT-2504 > URL: https://issues.apache.org/jira/browse/THRIFT-2504 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Reporter: Aleksey Pesternikov >Assignee: James E. King, III > Fix For: 0.11.0 > > > The original intention of this story was to allow an older client to connect > to a multiplexed server and continue to work by having the multiplexed > processor handle any request that does not contain a service name and colon > prefix. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1191: THRIFT-3706 - Implement multiplexor.
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1191 Well I was hoping the multiplexed implementation was compatible with older clients using binary protocol but it is not. I'm going to send you a PR that changes the Java Server and the c_glib client to work with "multiplexed" as a protocol; we will use binary protocol under all the multiplexed protocol tests. I added support in the java test server to have a second registered processor. It would be nice to augment c_glib to test against "Second" as well as "ThriftTest" so that we're actually testing the multiplexing part. --- 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-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874795#comment-15874795 ] ASF GitHub Bot commented on THRIFT-3706: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1191 Well I was hoping the multiplexed implementation was compatible with older clients using binary protocol but it is not. I'm going to send you a PR that changes the Java Server and the c_glib client to work with "multiplexed" as a protocol; we will use binary protocol under all the multiplexed protocol tests. I added support in the java test server to have a second registered processor. It would be nice to augment c_glib to test against "Second" as well as "ThriftTest" so that we're actually testing the multiplexing part. > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1191: THRIFT-3706 - Implement multiplexor.
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1191 @gadLinux for some reason I cannot send you a PR for this one like I had before, possibly because I rebased on master. If you cherry-pick b2e4e1464b74733ccf78afd68abbe94b92aec96a from my repository it will give you the changes you should need. --- 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-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874806#comment-15874806 ] ASF GitHub Bot commented on THRIFT-3706: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1191 @gadLinux for some reason I cannot send you a PR for this one like I had before, possibly because I rebased on master. If you cherry-pick b2e4e1464b74733ccf78afd68abbe94b92aec96a from my repository it will give you the changes you should need. > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874828#comment-15874828 ] ASF GitHub Bot commented on THRIFT-3706: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1191 I cannot do it since this commit is in thrift main outside master. So I cannot see it. You cannot merge because this branch is still not merged so it's still in my fork. You can merge and then apply the patch you want. Otherwise the only way I think is to make a patch. > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1191: THRIFT-3706 - Implement multiplexor.
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1191 I cannot do it since this commit is in thrift main outside master. So I cannot see it. You cannot merge because this branch is still not merged so it's still in my fork. You can merge and then apply the patch you want. Otherwise the only way I think is to make a patch. --- 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. ---
[GitHub] thrift pull request #1199: THRIFT-3706 - Implement multiplex protocol and cr...
GitHub user jeking3 opened a pull request: https://github.com/apache/thrift/pull/1199 THRIFT-3706 - Implement multiplex protocol and crosstest for c_glib client, java server I added one commit to https://github.com/apache/thrift/pull/1191 to make it work with crosstest, and rebased against master. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jeking3/thrift thrift-3706 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1199.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1199 commit 61d8cb372e0d00f5d509d0bf440673ddb1d23642 Author: Gonzalo Aguilar Delgado Date: 2016-03-04T12:16:22Z Implement multiplexed protocol commit d62dfbbff6f0d9f162c43793958cba9fe9834deb Author: Gonzalo Aguilar Delgado Date: 2016-03-05T00:21:27Z Implement protocol multiplexor. For me there are a pair of things missing. Implement protocol decorator. commit 86994fd0e9cd08457c37b66e723176a31703bdcb Author: Gonzalo Aguilar Delgado Date: 2016-03-28T23:08:52Z Fix protocol decorator cause it failed to register list cls->read_list_end on thrift_protocol_decorator_class_init Change log to debug commit fc70bef51faa0e9acf1dc284b8bd4556853259cf Author: Gonzalo Aguilar Delgado Date: 2017-02-15T09:10:05Z Add Multiplexed protocol to the test commit 88a7d134f19f84f8ba98d5a00251a8c248b40a00 Author: Gonzalo Aguilar Delgado Date: 2017-02-15T10:54:30Z Add multiplexed binary tests against java commit c2579a1b15b85eb6ee72b9778ba96d00ff7cdc17 Author: James E. King, III Date: 2017-02-20T16:49:07Z simplify protocol for multiplexed crosstest and add a second processor on the java server - this will also run in Travis CI because I already added support for multiplexed protocol in jobs #1 and #2 --- 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-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874849#comment-15874849 ] ASF GitHub Bot commented on THRIFT-3706: GitHub user jeking3 opened a pull request: https://github.com/apache/thrift/pull/1199 THRIFT-3706 - Implement multiplex protocol and crosstest for c_glib client, java server I added one commit to https://github.com/apache/thrift/pull/1191 to make it work with crosstest, and rebased against master. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jeking3/thrift thrift-3706 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1199.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1199 commit 61d8cb372e0d00f5d509d0bf440673ddb1d23642 Author: Gonzalo Aguilar Delgado Date: 2016-03-04T12:16:22Z Implement multiplexed protocol commit d62dfbbff6f0d9f162c43793958cba9fe9834deb Author: Gonzalo Aguilar Delgado Date: 2016-03-05T00:21:27Z Implement protocol multiplexor. For me there are a pair of things missing. Implement protocol decorator. commit 86994fd0e9cd08457c37b66e723176a31703bdcb Author: Gonzalo Aguilar Delgado Date: 2016-03-28T23:08:52Z Fix protocol decorator cause it failed to register list cls->read_list_end on thrift_protocol_decorator_class_init Change log to debug commit fc70bef51faa0e9acf1dc284b8bd4556853259cf Author: Gonzalo Aguilar Delgado Date: 2017-02-15T09:10:05Z Add Multiplexed protocol to the test commit 88a7d134f19f84f8ba98d5a00251a8c248b40a00 Author: Gonzalo Aguilar Delgado Date: 2017-02-15T10:54:30Z Add multiplexed binary tests against java commit c2579a1b15b85eb6ee72b9778ba96d00ff7cdc17 Author: James E. King, III Date: 2017-02-20T16:49:07Z simplify protocol for multiplexed crosstest and add a second processor on the java server - this will also run in Travis CI because I already added support for multiplexed protocol in jobs #1 and #2 > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874851#comment-15874851 ] ASF GitHub Bot commented on THRIFT-3706: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1191 Weird, I'm not exactly sure what happened here, but I submitted a new PR rebased against master incorporating your changes here and I added one more commit - see PR #1199. If that passes I'll squash my commit into yours down to a single commit so you show up as the author of the pull request into the master when I merge it in. > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1191: THRIFT-3706 - Implement multiplexor.
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1191 Weird, I'm not exactly sure what happened here, but I submitted a new PR rebased against master incorporating your changes here and I added one more commit - see PR #1199. If that passes I'll squash my commit into yours down to a single commit so you show up as the author of the pull request into the master when I merge it in. --- 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] [Assigned] (THRIFT-1677) MinGW support broken
[ https://issues.apache.org/jira/browse/THRIFT-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-1677: -- Assignee: James E. King, III > MinGW support broken > > > Key: THRIFT-1677 > URL: https://issues.apache.org/jira/browse/THRIFT-1677 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.9 > Environment: Windows 7, MinGW-W64 4.5.3 20110207 >Reporter: Josh D >Assignee: James E. King, III > > It appears that there's been a lot of great work towards getting Apache to > work with Visual Studio that have broken compatability with MinGW. There are > really too many issues, to list them all. In the .8 release, winsdkver.h is > inlcuded (fixed on trunk). Trunk has dozens of issues, that I haven't been > able to fully resolve. Mainly it's checking if _WIN32 is defined and > bypassing code that should be used within MinGW. For example, using > _chsize_s instead of ftruncate or redefining POSIX structures/functions like > gettimeofday, which are present in MinGW. It seems like most of these issues > could be resolved with autoconf. Also, from a 64-bit MinGW perspective, you > C-style cast pointers to "int" which isn't permissible in more modern > versions of gcc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (THRIFT-1677) MinGW support broken
[ https://issues.apache.org/jira/browse/THRIFT-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-1677. Resolution: Duplicate Fix Version/s: 0.11.0 See https://github.com/apache/thrift/blob/master/build/cmake/README-MSYS2.md for more details. > MinGW support broken > > > Key: THRIFT-1677 > URL: https://issues.apache.org/jira/browse/THRIFT-1677 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.9 > Environment: Windows 7, MinGW-W64 4.5.3 20110207 >Reporter: Josh D >Assignee: James E. King, III > Fix For: 0.11.0 > > > It appears that there's been a lot of great work towards getting Apache to > work with Visual Studio that have broken compatability with MinGW. There are > really too many issues, to list them all. In the .8 release, winsdkver.h is > inlcuded (fixed on trunk). Trunk has dozens of issues, that I haven't been > able to fully resolve. Mainly it's checking if _WIN32 is defined and > bypassing code that should be used within MinGW. For example, using > _chsize_s instead of ftruncate or redefining POSIX structures/functions like > gettimeofday, which are present in MinGW. It seems like most of these issues > could be resolved with autoconf. Also, from a 64-bit MinGW perspective, you > C-style cast pointers to "int" which isn't permissible in more modern > versions of gcc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (THRIFT-1145) Implement Thrift runtime for C with ASF compatible dependencies
[ https://issues.apache.org/jira/browse/THRIFT-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-1145: --- Priority: Minor (was: Major) > Implement Thrift runtime for C with ASF compatible dependencies > --- > > Key: THRIFT-1145 > URL: https://issues.apache.org/jira/browse/THRIFT-1145 > Project: Thrift > Issue Type: New Feature > Components: C glib - Compiler, Compiler (General) >Reporter: Carl Steinbach >Priority: Minor > > THRIFT-582 provided a C runtime for Thrift that depends heavily on the GLib > library. The major advantage of using GLib is that it's cross platform, so > the resulting runtime works on both Windows and Linux. However, a big > drawback is that GLib has an LGPL license, which bars a lot of people from > using it directly or indirectly. > This JIRA ticket covers the task of writing an alternative C Thrift runtime > that depends on the Apache Portable Runtime library instead of GLib. It > appears that the major hurdle we need to overcome is APRs lack of an object > system (c_glib takes advantage of GObject). I think the same problem was > solved during the implementation of Avro's C runtime, and perhaps the struct > and inheritance macros that are used in that code could be reused here (and > maybe later even contributed back to APR). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (THRIFT-1145) Implement Thrift runtime for C with ASF compatible dependencies
[ https://issues.apache.org/jira/browse/THRIFT-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-1145: --- Component/s: (was: C glib - Compiler) Wish List > Implement Thrift runtime for C with ASF compatible dependencies > --- > > Key: THRIFT-1145 > URL: https://issues.apache.org/jira/browse/THRIFT-1145 > Project: Thrift > Issue Type: New Feature > Components: Compiler (General), Wish List >Reporter: Carl Steinbach >Priority: Minor > > THRIFT-582 provided a C runtime for Thrift that depends heavily on the GLib > library. The major advantage of using GLib is that it's cross platform, so > the resulting runtime works on both Windows and Linux. However, a big > drawback is that GLib has an LGPL license, which bars a lot of people from > using it directly or indirectly. > This JIRA ticket covers the task of writing an alternative C Thrift runtime > that depends on the Apache Portable Runtime library instead of GLib. It > appears that the major hurdle we need to overcome is APRs lack of an object > system (c_glib takes advantage of GObject). I think the same problem was > solved during the implementation of Avro's C runtime, and perhaps the struct > and inheritance macros that are used in that code could be reused here (and > maybe later even contributed back to APR). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-1145) Implement Thrift runtime for C with ASF compatible dependencies
[ https://issues.apache.org/jira/browse/THRIFT-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874860#comment-15874860 ] James E. King, III commented on THRIFT-1145: I reduced this to Minor Priority. I like the notion of a pure C implementation using APR. There doesn't seem to be much call for it based on response to this ticket however. > Implement Thrift runtime for C with ASF compatible dependencies > --- > > Key: THRIFT-1145 > URL: https://issues.apache.org/jira/browse/THRIFT-1145 > Project: Thrift > Issue Type: New Feature > Components: Compiler (General), Wish List >Reporter: Carl Steinbach >Priority: Minor > > THRIFT-582 provided a C runtime for Thrift that depends heavily on the GLib > library. The major advantage of using GLib is that it's cross platform, so > the resulting runtime works on both Windows and Linux. However, a big > drawback is that GLib has an LGPL license, which bars a lot of people from > using it directly or indirectly. > This JIRA ticket covers the task of writing an alternative C Thrift runtime > that depends on the Apache Portable Runtime library instead of GLib. It > appears that the major hurdle we need to overcome is APRs lack of an object > system (c_glib takes advantage of GObject). I think the same problem was > solved during the implementation of Avro's C runtime, and perhaps the struct > and inheritance macros that are used in that code could be reused here (and > maybe later even contributed back to APR). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3620) Cleanup and consolidate Thrift* jenkins jobs.
[
https://issues.apache.org/jira/browse/THRIFT-3620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874862#comment-15874862
]
James E. King, III commented on THRIFT-3620:
Hi [~jsirois], since all Thrift CI biulds go through Travis CI and Appveyor
now, is this still relevant?
> Cleanup and consolidate Thrift* jenkins jobs.
> -
>
> Key: THRIFT-3620
> URL: https://issues.apache.org/jira/browse/THRIFT-3620
> Project: Thrift
> Issue Type: Task
> Components: Test Suite
>Reporter: John Sirois
>Assignee: John Sirois
>
> I spent some time resurrecting the
> [Thrift-precommit|https://builds.apache.org/job/Thrift-precommit/] job which
> vets pull-requests to use the pool of docker slaves using a dockerized CI
> with guidance from [~jfarrell]. The remaining crop of Thrift* jobs should be
> culled and converted as appropriate.
> Currently we have the jobs
> [here|https://builds.apache.org/view/S-Z/view/Thrift/]:
> {noformat}
> $ curl --netrc -sS https://builds.apache.org/view/S-Z/view/Thrift/config.xml
> | xmllint -xpath "//jobNames" - | grep "" | cut -d'>' -f2 | cut -d'<'
> -f1
> Thrift
> Thrift-all
> Thrift-Compiler-Linux64
> Thrift-Compiler-Windows
> Thrift-env
> Thrift-env-Windows
> Thrift-Test
> Thrift-Windows
> {noformat}
> Of those, [Thrift-env|https://builds.apache.org/job/Thrift-env],
> [Thrift-env-Windows|https://builds.apache.org/job/Thrift-env-Windows] and
> [Thrift-Windows|https://builds.apache.org/job/Thrift-Windows] are all
> disabled and [Thrift|https://builds.apache.org/job/Thrift] and
> [Thrift-Compiler-Linux64|https://builds.apache.org/job/Thrift-Compiler-Linux64]
> seem to be unused based on last run dates. This leaves the following active
> jobs fwict:
> * [|https://builds.apache.org/job/Thrift-all]
> * [|https://builds.apache.org/job/Thrift-Compiler-Windows]
> * [|https://builds.apache.org/job/Thrift-precommit]
> Of these {{Thrift-all}} is broken in a known-way, it really needs to be
> converted to use a Dockerized build like {{Thrift-precommit}} to be insulated
> from the vagaries of the underlying worker machines.
> I propose deltion of all disabled (3) and inactive (2) jobs listed above and
> conversion of {{Thrift-all}} to a Dockerized CI job to guard master with.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-2208) Thrift package for chocolatey
[ https://issues.apache.org/jira/browse/THRIFT-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874864#comment-15874864 ] James E. King, III commented on THRIFT-2208: Someone uploaded the 0.9.3 compiler only here: https://chocolatey.org/packages/thrift > Thrift package for chocolatey > - > > Key: THRIFT-2208 > URL: https://issues.apache.org/jira/browse/THRIFT-2208 > Project: Thrift > Issue Type: Wish > Components: Build Process >Reporter: Jake Farrell >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (THRIFT-3042) Dockerfiles fail to build
[ https://issues.apache.org/jira/browse/THRIFT-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-3042. Resolution: Fixed Assignee: James E. King, III (was: Jake Farrell) Fix Version/s: (was: 1.0) 0.10.0 The docker files for ubuntu and debian have been building well for a while now. I'm going to mark this resolved. > Dockerfiles fail to build > - > > Key: THRIFT-3042 > URL: https://issues.apache.org/jira/browse/THRIFT-3042 > Project: Thrift > Issue Type: Bug > Components: Build Process >Affects Versions: 0.9.3 > Environment: ubuntu 14.04 docker host >Reporter: Randy Abernethy >Assignee: James E. King, III >Priority: Minor > Fix For: 0.10.0 > > Attachments: thrift-3042-ubuntu.patch > > > h3. Docker build on build/docker/ubuntu/Dockerfile fails on Haxe setup. e.g. > docker@ubuntu:~$ docker build -t thrift thrift/build/docker/ubuntu > ... > haxe-3.1.3/std/Xml.hx > Uncaught exception - load.c(237) : Failed to load library : std.ndll > (std.ndll: cannot open shared object file: No such file or directory) > INFO[0011] The command [/bin/sh -c apt-get install -y libneko0 && mkdir > -p /tmp/haxe /usr/lib/haxe && curl > http://haxe.org/website-content/downloads/3,1,3/downloads/haxe-3.1.3-linux64.tar.gz > -o /tmp/haxe/haxe-3.1.3-linux64.tar.gz && tar -xvzf > /tmp/haxe/haxe-3.1.3-linux64.tar.gz -C /usr/lib/haxe --strip-components=1 && >ln -s /usr/lib/haxe/haxe /usr/bin/haxe && ln -s /usr/lib/haxe/haxelib > /usr/bin/haxelib && ln -s /usr/lib/libneko.so.0 /usr/lib/libneko.so && > mkdir -p /usr/lib/haxe/lib && chmod -R 777 /usr/lib/haxe/lib && > haxelib setup /usr/lib/haxe/lib && haxelib install hxcpp] returned a > non-zero code: 1 > h3. Docker build on build/docker/centosDockerfile fails on Boost build. e.g. > docker@ubuntu:~$ docker build -t thrift thrift/build/docker/centos > ... > /tmp/boost/boost_1_55_0/tools/build/v2/tools/gcc.jam:148: in gcc.init from > module gcc > error: toolset gcc initialization: > error: no command provided, default command 'g++' not found > error: initialized from project-config.jam:12 > /tmp/boost/boost_1_55_0/tools/build/v2/build/toolset.jam:41: in toolset.using > from module toolset > /tmp/boost/boost_1_55_0/tools/build/v2/build/project.jam:1007: in using from > module project-rules > project-config.jam:12: in modules.load from module project-config > /tmp/boost/boost_1_55_0/tools/build/v2/build-system.jam:249: in load-config > from module build-system > /tmp/boost/boost_1_55_0/tools/build/v2/build-system.jam:412: in > load-configuration-files from module build-system > /tmp/boost/boost_1_55_0/tools/build/v2/build-system.jam:524: in load from > module build-system > /tmp/boost/boost_1_55_0/tools/build/v2/kernel/modules.jam:289: in import from > module modules > /tmp/boost/boost_1_55_0/tools/build/v2/kernel/bootstrap.jam:139: in > boost-build from module > /tmp/boost/boost_1_55_0/boost-build.jam:17: in module scope from module > INFO[0264] The command [/bin/sh -c mkdir -p /tmp/boost && curl -SL > "http://sourceforge.net/projects/boost/files/boost/1.55.0/boost_1_55_0.tar.gz"; > | tar -xzC /tmp/boost && cd /tmp/boost/boost_1_55_0 && > ./bootstrap.sh && ./b2 install && cd $HOME] returned a non-zero > code: 1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (THRIFT-3250) Apache Thrift should use registered media types with HTTP
[ https://issues.apache.org/jira/browse/THRIFT-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-3250: --- Component/s: Dart - Library .NETCore - Library > Apache Thrift should use registered media types with HTTP > - > > Key: THRIFT-3250 > URL: https://issues.apache.org/jira/browse/THRIFT-3250 > Project: Thrift > Issue Type: Improvement > Components: .NETCore - Library, AS3 - Library, C# - Library, C++ - > Library, Cocoa - Library, D - Library, Dart - Library, Delphi - Library, > Erlang - Library, Go - Library, Haskell - Library, Haxe - Library, Java - > Library, JavaME - Library, JavaScript - Library, Node.js - Library, Perl - > Library, PHP - Library, Python - Library, Ruby - Library >Affects Versions: 0.9.3 > Environment: all >Reporter: Randy Abernethy >Assignee: Randy Abernethy >Priority: Minor > > Now that we have registered media types: > - application/vnd.apache.thrift.binary > - application/vnd.apache.thrift.compact > - application/vnd.apache.thrift.json > We should use them exclusively, replacing the old x-thrift. I suggest > TProtocol gain a getMediaType() method which returns the correct media type > when invoked on a concrete protocol (e.g. TBinaryProtocol.getMediaType() > would return "application/vnd.apache.thrift.binary". > HTTP oriented code can then invoke the getMediaType() method of the protocol > to discover the correct media type to set in HTTP headers. > Thoughts? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3250) Apache Thrift should use registered media types with HTTP
[
https://issues.apache.org/jira/browse/THRIFT-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874929#comment-15874929
]
James E. King, III commented on THRIFT-3250:
Is there a way to do this that's backwards compatible? For example the client
always initiates a request and it can indicate it accepts a list of response
types. Right now {{THttpClient.java}} has:
{noformat}
post.setHeader("Accept", "application/x-thrift");
{noformat}
If this was changed to allow application/vnd.apache.thrift.*, then the server
side could look at the "Accept" field and if the client accepts it, it can use
one of the new fields; or for a poorly written older client that does not use
the Accept header at all, it would default to current behavior.
> Apache Thrift should use registered media types with HTTP
> -
>
> Key: THRIFT-3250
> URL: https://issues.apache.org/jira/browse/THRIFT-3250
> Project: Thrift
> Issue Type: Improvement
> Components: .NETCore - Library, AS3 - Library, C# - Library, C++ -
> Library, Cocoa - Library, D - Library, Dart - Library, Delphi - Library,
> Erlang - Library, Go - Library, Haskell - Library, Haxe - Library, Java -
> Library, JavaME - Library, JavaScript - Library, Node.js - Library, Perl -
> Library, PHP - Library, Python - Library, Ruby - Library
>Affects Versions: 0.9.3
> Environment: all
>Reporter: Randy Abernethy
>Assignee: Randy Abernethy
>Priority: Minor
>
> Now that we have registered media types:
> - application/vnd.apache.thrift.binary
> - application/vnd.apache.thrift.compact
> - application/vnd.apache.thrift.json
> We should use them exclusively, replacing the old x-thrift. I suggest
> TProtocol gain a getMediaType() method which returns the correct media type
> when invoked on a concrete protocol (e.g. TBinaryProtocol.getMediaType()
> would return "application/vnd.apache.thrift.binary".
> HTTP oriented code can then invoke the getMediaType() method of the protocol
> to discover the correct media type to set in HTTP headers.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-2945) Implement support for Rust language
[ https://issues.apache.org/jira/browse/THRIFT-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874943#comment-15874943 ] Tony Przygienda commented on THRIFT-2945: - OK, we're in agreement., I'll get to it & come back when done. Busy right now upstreaming couple other things. Give me couple days ... I'll make an example for the enum macro once I'm @ it. Problem is that match clauses cannot be generated by macros in Rust so you have to provide a macro already implementing the match clause calling a callback function/macro given, especially in case of unions ... --- tony > Implement support for Rust language > --- > > Key: THRIFT-2945 > URL: https://issues.apache.org/jira/browse/THRIFT-2945 > Project: Thrift > Issue Type: New Feature > Components: Rust - Compiler, Rust - Library >Reporter: Maksim Golov >Assignee: Allen George > Fix For: 0.11.0 > > > Work on implementing support for Rust is in progress: > https://github.com/maximg/thrift by Simon Génier and myself. > It will probably take quite some time to complete. Please keep us updated if > there are changes related to our work. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1199: THRIFT-3706 - Implement multiplex protocol and crosstest...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1199 The failure here is environmental (write error). I'll squash and merge. --- 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-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874955#comment-15874955 ] ASF GitHub Bot commented on THRIFT-3706: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1199 The failure here is environmental (write error). I'll squash and merge. > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1191: THRIFT-3706 - Implement multiplexor.
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1191 --- 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. ---
[GitHub] thrift pull request #1199: THRIFT-3706 - Implement multiplex protocol and cr...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1199 --- 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] [Resolved] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-3706. Resolution: Fixed Fix Version/s: 0.11.0 Committed - thanks! > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > Fix For: 0.11.0 > > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874965#comment-15874965 ] ASF GitHub Bot commented on THRIFT-3706: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1191 > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > Fix For: 0.11.0 > > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874966#comment-15874966 ] ASF GitHub Bot commented on THRIFT-3706: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1199 > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > Fix For: 0.11.0 > > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1196: THRIFT-3891 TNonblockingServer configured with more than...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1196 Once someone has a chance to approve the changes I can merge. --- 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-3891) TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()
[
https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874967#comment-15874967
]
ASF GitHub Bot commented on THRIFT-3891:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1196
Once someone has a chance to approve the changes I can merge.
> TNonblockingServer configured with more than one IO threads does not always
> return from serve() upon stop()
> ---
>
> Key: THRIFT-3891
> URL: https://issues.apache.org/jira/browse/THRIFT-3891
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Buğra Gedik
>Assignee: James E. King, III
>Priority: Minor
> Attachments: patch.diff
>
>
> Using {{TNonblockingServer}}, when the number of IO threads is > 1, there is
> race condition in which {{stop()}} does not properly unblock {{serve()}}.
> The problem manifests itself when {{stop()}} is called (obviously from a
> different thread) soon after {{serve()}}.
> The core issue is that, {{event_base_loopbreak()}} is called within the
> {{stop()}} sequence without checking whether the IO thread has actually
> entered its event loop. The documentation of {{event_base_loopbreak()}} says
> (http://www.wangafu.net/~nickm/libevent-book/Ref3_eventloop.html)
> {quote}
> Note also that event_base_loopexit(base,NULL) and event_base_loopbreak(base)
> act differently when no event loop is running: loopexit schedules the next
> instance of the event loop to stop right after the next round of callbacks
> are run (as if it had been invoked with EVLOOP_ONCE) whereas loopbreak only
> stops a currently running loop, and has no effect if the event loop isn’t
> running.
> {quote}
> Attached is a patch (against the released 0.9.3 version of the codebase).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-3250) Apache Thrift should use registered media types with HTTP
[ https://issues.apache.org/jira/browse/THRIFT-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874983#comment-15874983 ] James E. King, III commented on THRIFT-3250: I tried implemented the suggested way in the description however protocols consume transports, and in perl THttpClient is a TTransport. If the media type is in the TProtocol then it isn't available in the transport's code to access. It might make more sense to require another argument to Http client implementations in each language and have the consuming application tell it what media type to use for "Accept". Similarly, it probably makes sense to allow the consuming application specify the "User-Agent" and perhaps also the "Content-Type" so that a newer client can be constructed to work with an older server. My suggestion above allows an older client to connect to a newer server. > Apache Thrift should use registered media types with HTTP > - > > Key: THRIFT-3250 > URL: https://issues.apache.org/jira/browse/THRIFT-3250 > Project: Thrift > Issue Type: Improvement > Components: .NETCore - Library, AS3 - Library, C# - Library, C++ - > Library, Cocoa - Library, D - Library, Dart - Library, Delphi - Library, > Erlang - Library, Go - Library, Haskell - Library, Haxe - Library, Java - > Library, JavaME - Library, JavaScript - Library, Node.js - Library, Perl - > Library, PHP - Library, Python - Library, Ruby - Library >Affects Versions: 0.9.3 > Environment: all >Reporter: Randy Abernethy >Assignee: Randy Abernethy >Priority: Minor > > Now that we have registered media types: > - application/vnd.apache.thrift.binary > - application/vnd.apache.thrift.compact > - application/vnd.apache.thrift.json > We should use them exclusively, replacing the old x-thrift. I suggest > TProtocol gain a getMediaType() method which returns the correct media type > when invoked on a concrete protocol (e.g. TBinaryProtocol.getMediaType() > would return "application/vnd.apache.thrift.binary". > HTTP oriented code can then invoke the getMediaType() method of the protocol > to discover the correct media type to set in HTTP headers. > Thoughts? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (THRIFT-2504) TMultiplexedProcessor should allow registering default processor called if no service name is present
[ https://issues.apache.org/jira/browse/THRIFT-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-2504: --- Comment: was deleted (was: After working on THRIFT-3706 I found that the Multiplexed Protocol wrapper is not compatible with older clients connecting. It has its own protocol header that would not allow a binary client to connect and use the default processor. As such, this change offers no benefit since one must use multiplexed on either end. This should be reverted.) > TMultiplexedProcessor should allow registering default processor called if no > service name is present > - > > Key: THRIFT-2504 > URL: https://issues.apache.org/jira/browse/THRIFT-2504 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Reporter: Aleksey Pesternikov >Assignee: James E. King, III > Fix For: 0.11.0 > > > The original intention of this story was to allow an older client to connect > to a multiplexed server and continue to work by having the multiplexed > processor handle any request that does not contain a service name and colon > prefix. Given that multiplex is just a decorated protocol where the service > name is prepended to the call name, it should be possible to connect a > standard binary protocol client to a multiplex protocol server that treats a > non-multiplex call (one without the colon separator) as a > backwards-compatible call so older clients can continue to connect to newer > servers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (THRIFT-2504) TMultiplexedProcessor should allow registering default processor called if no service name is present
[ https://issues.apache.org/jira/browse/THRIFT-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-2504: --- Description: The original intention of this story was to allow an older client to connect to a multiplexed server and continue to work by having the multiplexed processor handle any request that does not contain a service name and colon prefix. Given that multiplex is just a decorated protocol where the service name is prepended to the call name, it should be possible to connect a standard binary protocol client to a multiplex protocol server that treats a non-multiplex call (one without the colon separator) as a backwards-compatible call so older clients can continue to connect to newer servers. (was: The original intention of this story was to allow an older client to connect to a multiplexed server and continue to work by having the multiplexed processor handle any request that does not contain a service name and colon prefix.) > TMultiplexedProcessor should allow registering default processor called if no > service name is present > - > > Key: THRIFT-2504 > URL: https://issues.apache.org/jira/browse/THRIFT-2504 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Reporter: Aleksey Pesternikov >Assignee: James E. King, III > Fix For: 0.11.0 > > > The original intention of this story was to allow an older client to connect > to a multiplexed server and continue to work by having the multiplexed > processor handle any request that does not contain a service name and colon > prefix. Given that multiplex is just a decorated protocol where the service > name is prepended to the call name, it should be possible to connect a > standard binary protocol client to a multiplex protocol server that treats a > non-multiplex call (one without the colon separator) as a > backwards-compatible call so older clients can continue to connect to newer > servers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-3706: -- Assignee: James E. King, III (was: Gonzalo Aguilar) > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: James E. King, III > Fix For: 0.11.0 > > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reopened THRIFT-3706: I am reopening this to finish the interop work with older clients. It should be possible for a non-multiplexed client using the same protocol as the multiplexed processor on the server side to interop. > There's no support for Multiplexed protocol on c_glib library > - > > Key: THRIFT-3706 > URL: https://issues.apache.org/jira/browse/THRIFT-3706 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > Fix For: 0.11.0 > > > There's no multiplexed protocol. > I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (THRIFT-4096) Remove unnecessary duplication of build/test effort in Travis CI
[ https://issues.apache.org/jira/browse/THRIFT-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4096. Resolution: Duplicate Duping this to an issue I opened previously. > Remove unnecessary duplication of build/test effort in Travis CI > > > Key: THRIFT-4096 > URL: https://issues.apache.org/jira/browse/THRIFT-4096 > Project: Thrift > Issue Type: Improvement > Components: Build Process >Affects Versions: 0.11.0 > Environment: Travis CI >Reporter: James E. King, III >Assignee: Jake Farrell > > Build jobs #1 and #3 use ubuntu. > Build jobs #2 and #4 use debian. > Both of these are long running jobs that run "make cross" and test the same > thing twice. Further, ubuntu is a derivative of debian which makes the > testing somewhat more duplicated. There are also build jobs like #23 which > build everything yet again in ubuntu and produce debian packages, so we build > the same thing many times in Travis CI. Recently we had the number of build > jobs limited because we were using too much resource from Apache's Travis CI > slave pool so we should be good citizens and try to pare down unnecessary > build jobs while maintaining quality. > We should discuss removing the ubuntu jobs and docker environment in favor of > the distribution it originates from and whether that makes sense. In > addition, there has been renewed interest from the Fedora project to build > thrift and I think we would get broader adoption if we had a Fedora docker > image that builds thrift and runs make cross. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (THRIFT-4096) Remove unnecessary duplication of build/test effort in Travis CI
[ https://issues.apache.org/jira/browse/THRIFT-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III closed THRIFT-4096. -- > Remove unnecessary duplication of build/test effort in Travis CI > > > Key: THRIFT-4096 > URL: https://issues.apache.org/jira/browse/THRIFT-4096 > Project: Thrift > Issue Type: Improvement > Components: Build Process >Affects Versions: 0.11.0 > Environment: Travis CI >Reporter: James E. King, III >Assignee: Jake Farrell > > Build jobs #1 and #3 use ubuntu. > Build jobs #2 and #4 use debian. > Both of these are long running jobs that run "make cross" and test the same > thing twice. Further, ubuntu is a derivative of debian which makes the > testing somewhat more duplicated. There are also build jobs like #23 which > build everything yet again in ubuntu and produce debian packages, so we build > the same thing many times in Travis CI. Recently we had the number of build > jobs limited because we were using too much resource from Apache's Travis CI > slave pool so we should be good citizens and try to pare down unnecessary > build jobs while maintaining quality. > We should discuss removing the ubuntu jobs and docker environment in favor of > the distribution it originates from and whether that makes sense. In > addition, there has been renewed interest from the Fedora project to build > thrift and I think we would get broader adoption if we had a Fedora docker > image that builds thrift and runs make cross. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4097) Support for Fedora distribution - packaging and CI builds
James E. King, III created THRIFT-4097: -- Summary: Support for Fedora distribution - packaging and CI builds Key: THRIFT-4097 URL: https://issues.apache.org/jira/browse/THRIFT-4097 Project: Thrift Issue Type: Wish Components: Build Process, Wish List Affects Versions: 0.10.0 Reporter: James E. King, III Priority: Minor Based on discussions elsewhere for thrift on fedora (they were on version 0.9.1) here: https://bugzilla.redhat.com/show_bug.cgi?id=1385702 It was suggested that if the thrift project build packages for fedora it would improve adoption on rpm based systems. They also said that currently the only thing in the distribution that uses thrift is accumulo. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-2945) Implement support for Rust language
[ https://issues.apache.org/jira/browse/THRIFT-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875528#comment-15875528 ] Jens Geyer commented on THRIFT-2945: Hi [~allengeorge] and [~prz], could you open a new ticket for the new issue please? Thanks! > Implement support for Rust language > --- > > Key: THRIFT-2945 > URL: https://issues.apache.org/jira/browse/THRIFT-2945 > Project: Thrift > Issue Type: New Feature > Components: Rust - Compiler, Rust - Library >Reporter: Maksim Golov >Assignee: Allen George > Fix For: 0.11.0 > > > Work on implementing support for Rust is in progress: > https://github.com/maximg/thrift by Simon Génier and myself. > It will probably take quite some time to complete. Please keep us updated if > there are changes related to our work. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4011) Sets of Thrift structs generate Go code that can't be serialized to JSON
[
https://issues.apache.org/jira/browse/THRIFT-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875530#comment-15875530
]
ASF GitHub Bot commented on THRIFT-4011:
Github user Jens-G commented on the issue:
https://github.com/apache/thrift/pull/1156
Ok, thanks.
> Sets of Thrift structs generate Go code that can't be serialized to JSON
>
>
> Key: THRIFT-4011
> URL: https://issues.apache.org/jira/browse/THRIFT-4011
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Reporter: Can Celasun
>
> Consider the following structs:
> {code}
> struct Foo {
> 1: optional string foo
> }
> struct Bar {
> 1: optional set foos
> }
> {code}
> This compiles into the following Go code:
> {code}
> type Bar struct {
> Foos map[*Foo]struct{} `thrift:"foos,1" db:"foos" json:"foos,omitempty"`
> }
> {code}
> Even though the generated code has tags for JSON support, Bar can't be
> serialized to JSON:
> {code}
> json: unsupported type: map[*Foo]struct {}
> {code}
> One solution would be to use slices, not maps, for Thrift sets. Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1156: THRIFT-4011 Use slices for Thrift sets
Github user Jens-G commented on the issue: https://github.com/apache/thrift/pull/1156 Ok, thanks. --- 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. ---
