[GitHub] thrift issue #1413: 0.8.x
Github user Jens-G commented on the issue: https://github.com/apache/thrift/pull/1413 @jfarrell, could you please close this? ---
[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16250293#comment-16250293 ] ASF GitHub Bot commented on THRIFT-4329: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 Hi @jeking3 I think at the end it was part of the test client... What do you think? It worth it merge it? > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. We also need a > multiplexed processor for the server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 Hi @jeking3 I think at the end it was part of the test client... What do you think? It worth it merge it? ---
[GitHub] thrift issue #1411: Fix remote client for HTTP transport
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1411 Thanks - once the CI builds pass I will re-review. ---
[jira] [Updated] (THRIFT-4385) Go remote client -u flag is broken
[ https://issues.apache.org/jira/browse/THRIFT-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dylan Trotter updated THRIFT-4385: -- Summary: Go remote client -u flag is broken (was: Go remote client doesn't work for HTTP transport) > Go remote client -u flag is broken > -- > > Key: THRIFT-4385 > URL: https://issues.apache.org/jira/browse/THRIFT-4385 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Reporter: Dylan Trotter > > There are two separate but trivial bugs in the Go remote implementation: > * The parseUrl local variable is always empty because the code that attempts > to assign to it actually assigns to a new scoped variable (`parsedUrl, err := > url.Parse(urlString)`). This means that the -u flag does not work and the > http.Get() call deep in the stack returns an obscure message about the URL > scheme being empty (actually the whole URL is empty). > * -When using HTTP transport the tool uses a THttpClient which issues a GET. > The Go http library assumes an empty body for GET requests which means that > the request payload does not accompany the request. Instead of using > THttpClient the tools should use THttpPostClient so that the request payload > will accompany the request.- > The second issue above has separately been resolved: THttpPostClient is > deprecated and is just an alias for THttpClient since 0dd8235. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4385) Go remote client doesn't work for HTTP transport
[ https://issues.apache.org/jira/browse/THRIFT-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dylan Trotter updated THRIFT-4385: -- Description: There are two separate but trivial bugs in the Go remote implementation: * The parseUrl local variable is always empty because the code that attempts to assign to it actually assigns to a new scoped variable (`parsedUrl, err := url.Parse(urlString)`). This means that the -u flag does not work and the http.Get() call deep in the stack returns an obscure message about the URL scheme being empty (actually the whole URL is empty). * -When using HTTP transport the tool uses a THttpClient which issues a GET. The Go http library assumes an empty body for GET requests which means that the request payload does not accompany the request. Instead of using THttpClient the tools should use THttpPostClient so that the request payload will accompany the request.- The second issue above has separately been resolved: THttpPostClient is deprecated and is just an alias for THttpClient since 0dd8235. was: There are two separate but trivial bugs in the Go remote implementation: * The parseUrl local variable is always empty because the code that attempts to assign to it actually assigns to a new scoped variable (`parsedUrl, err := url.Parse(urlString)`). This means that the -u flag does not work and the http.Get() call deep in the stack returns an obscure message about the URL scheme being empty (actually the whole URL is empty). * When using HTTP transport the tool uses a THttpClient which issues a GET. The Go http library assumes an empty body for GET requests which means that the request payload does not accompany the request. Instead of using THttpClient the tools should use THttpPostClient so that the request payload will accompany the request. > Go remote client doesn't work for HTTP transport > > > Key: THRIFT-4385 > URL: https://issues.apache.org/jira/browse/THRIFT-4385 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Reporter: Dylan Trotter > > There are two separate but trivial bugs in the Go remote implementation: > * The parseUrl local variable is always empty because the code that attempts > to assign to it actually assigns to a new scoped variable (`parsedUrl, err := > url.Parse(urlString)`). This means that the -u flag does not work and the > http.Get() call deep in the stack returns an obscure message about the URL > scheme being empty (actually the whole URL is empty). > * -When using HTTP transport the tool uses a THttpClient which issues a GET. > The Go http library assumes an empty body for GET requests which means that > the request payload does not accompany the request. Instead of using > THttpClient the tools should use THttpPostClient so that the request payload > will accompany the request.- > The second issue above has separately been resolved: THttpPostClient is > deprecated and is just an alias for THttpClient since 0dd8235. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1411: Fix remote client for HTTP transport
Github user trotterdylan commented on the issue: https://github.com/apache/thrift/pull/1411 Done. Updated the commit message accordingly. ---
[GitHub] thrift issue #1411: Fix remote client for HTTP transport
Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1411 Please revert the `NewTHttpClient` part of this PR, since `THttpPostClient` is deprecated and is just an alias for `THttpClient` since 0dd82358. ---
[GitHub] thrift pull request #1413: 0.8.x
GitHub user tt918916 opened a pull request: https://github.com/apache/thrift/pull/1413 0.8.x You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/thrift 0.8.x Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1413.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 #1413 commit c303ab8ba5582e848bd5a794a1a87cefc57e693d Author: Jake Farrell Date: 2011-11-26T18:59:52Z Initial branch for the 0.8.x release git-svn-id: https://svn.apache.org/repos/asf/thrift/branches/0.8.x@1206541 13f79535-47bb-0310-9956-ffa450edef68 commit 48d2e64d6ae2277a554e90d06735971e964f6de4 Author: Jake Farrell Date: 2011-11-26T19:51:38Z Updating versioning to 0.8.0. git-svn-id: https://svn.apache.org/repos/asf/thrift/branches/0.8.x@1206566 13f79535-47bb-0310-9956-ffa450edef68 commit be691f4ebfcc0496aaefc464803210e4e40f62ad Author: Jake Farrell Date: 2011-11-26T21:24:24Z Updating CHANGES for 0.8.0 release git-svn-id: https://svn.apache.org/repos/asf/thrift/branches/0.8.x@1206597 13f79535-47bb-0310-9956-ffa450edef68 ---
[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249864#comment-16249864 ] ASF GitHub Bot commented on THRIFT-4329: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 In fact @jeking3 Some of the failures are not related to this issue. So please don't ask me to fix them as part of this issue. One of them is caused in the Java Server because the exception management. Maybe caused by the c_glib client. But I'm NOT implementing the client on this issue but the server. For example: [java] 2017-11-13 18:35:41,759 ERROR thrift.ProcessFunction (ProcessFunction.java:process(38)) - Internal error processing testException [java] org.apache.thrift.TException: TException [java] at org.apache.thrift.server.ServerTestBase$TestHandler.testException(ServerTestBase.java:237) [java] at thrift.test.ThriftTest$Processor$testException.getResult(ThriftTest.java:2089) [java] at thrift.test.ThriftTest$Processor$testException.getResult(ThriftTest.java:2068) [java] at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:36) [java] at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) [java] at org.apache.thrift.TMultiplexedProcessor.process(TMultiplexedProcessor.java:134) [java] at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:291) [java] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [java] at java.lang.Thread.run(Thread.java:745) > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. We also need a > multiplexed processor for the server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 In fact @jeking3 Some of the failures are not related to this issue. So please don't ask me to fix them as part of this issue. One of them is caused in the Java Server because the exception management. Maybe caused by the c_glib client. But I'm NOT implementing the client on this issue but the server. For example: [java] 2017-11-13 18:35:41,759 ERROR thrift.ProcessFunction (ProcessFunction.java:process(38)) - Internal error processing testException [java] org.apache.thrift.TException: TException [java] at org.apache.thrift.server.ServerTestBase$TestHandler.testException(ServerTestBase.java:237) [java] at thrift.test.ThriftTest$Processor$testException.getResult(ThriftTest.java:2089) [java] at thrift.test.ThriftTest$Processor$testException.getResult(ThriftTest.java:2068) [java] at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:36) [java] at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) [java] at org.apache.thrift.TMultiplexedProcessor.process(TMultiplexedProcessor.java:134) [java] at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:291) [java] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [java] at java.lang.Thread.run(Thread.java:745) ---
[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249852#comment-16249852 ] ASF GitHub Bot commented on THRIFT-4329: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 What I'm telling you is that I need help if you want to fix everything on this language. I don't have all the time to implement the full stack. This is an implementation of the processor, not all protocols and transports supported. So if we want to have a full c_glib implementation we should break into smaller issues and give them to different developers. The current implementation is tested on the basic protocols and transports with some languages (not all) if something is broken, then another issue has to be raised to implement that part on the right way. I cannot afford do the full stack implementation for c_glib in one shot. > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. We also need a > multiplexed processor for the server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 What I'm telling you is that I need help if you want to fix everything on this language. I don't have all the time to implement the full stack. This is an implementation of the processor, not all protocols and transports supported. So if we want to have a full c_glib implementation we should break into smaller issues and give them to different developers. The current implementation is tested on the basic protocols and transports with some languages (not all) if something is broken, then another issue has to be raised to implement that part on the right way. I cannot afford do the full stack implementation for c_glib in one shot. ---
[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249845#comment-16249845 ] ASF GitHub Bot commented on THRIFT-4329: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 @jeking3 I don't think is an error, but that all this cross tests are directly not supported. No all protocols are implemented. > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. We also need a > multiplexed processor for the server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 @jeking3 I don't think is an error, but that all this cross tests are directly not supported. No all protocols are implemented. ---
[jira] [Commented] (THRIFT-4385) Go remote client doesn't work for HTTP transport
[ https://issues.apache.org/jira/browse/THRIFT-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249834#comment-16249834 ] ASF GitHub Bot commented on THRIFT-4385: Github user trotterdylan commented on the issue: https://github.com/apache/thrift/pull/1411 Done! https://issues.apache.org/jira/browse/THRIFT-4385 > Go remote client doesn't work for HTTP transport > > > Key: THRIFT-4385 > URL: https://issues.apache.org/jira/browse/THRIFT-4385 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Reporter: Dylan Trotter > > There are two separate but trivial bugs in the Go remote implementation: > * The parseUrl local variable is always empty because the code that attempts > to assign to it actually assigns to a new scoped variable (`parsedUrl, err := > url.Parse(urlString)`). This means that the -u flag does not work and the > http.Get() call deep in the stack returns an obscure message about the URL > scheme being empty (actually the whole URL is empty). > * When using HTTP transport the tool uses a THttpClient which issues a GET. > The Go http library assumes an empty body for GET requests which means that > the request payload does not accompany the request. Instead of using > THttpClient the tools should use THttpPostClient so that the request payload > will accompany the request. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (THRIFT-4385) Go remote client doesn't work for HTTP transport
Dylan Trotter created THRIFT-4385: - Summary: Go remote client doesn't work for HTTP transport Key: THRIFT-4385 URL: https://issues.apache.org/jira/browse/THRIFT-4385 Project: Thrift Issue Type: Bug Components: Go - Compiler Reporter: Dylan Trotter There are two separate but trivial bugs in the Go remote implementation: * The parseUrl local variable is always empty because the code that attempts to assign to it actually assigns to a new scoped variable (`parsedUrl, err := url.Parse(urlString)`). This means that the -u flag does not work and the http.Get() call deep in the stack returns an obscure message about the URL scheme being empty (actually the whole URL is empty). * When using HTTP transport the tool uses a THttpClient which issues a GET. The Go http library assumes an empty body for GET requests which means that the request payload does not accompany the request. Instead of using THttpClient the tools should use THttpPostClient so that the request payload will accompany the request. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1411: Fix remote client for HTTP transport
Github user trotterdylan commented on the issue: https://github.com/apache/thrift/pull/1411 Done! https://issues.apache.org/jira/browse/THRIFT-4385 ---
[jira] [Created] (THRIFT-4384) Using multiple services simultaneously is not thread-safe.
Michael Eiler created THRIFT-4384: - Summary: Using multiple services simultaneously is not thread-safe. Key: THRIFT-4384 URL: https://issues.apache.org/jira/browse/THRIFT-4384 Project: Thrift Issue Type: Bug Components: C++ - Compiler, C++ - Library Affects Versions: 0.10.0 Environment: Should affect all platforms but has been noticed first on Windows, x86_64. Reporter: Michael Eiler Priority: Critical Fix For: 0.11.0, 0.10.0 I'm using the generated *ServiceConcurrentClient classes. They should allow me to call multiple functions at the same time. The issue as that the ::apache::thrift::async::TConcurrentClientSyncInfo class is a member of the generated service. If I have a project with multiple services sharing the same connection (protocol) with each other, the services will not be mutually excluded from reading on the same socket. I did a small test with patching the generated code and injecting the same instance of TConcurrentClientSyncInfo into all my services and everything was fine. Question: Do you need a small project to reproduce this or is it obvious enough? Just check out any generated code and you will see that the TConcurrentClientSyncInfo is not shared between different services. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249647#comment-16249647 ] ASF GitHub Bot commented on THRIFT-4329: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1361 @gadLinux I think you need to re-read the error messages. It says GLib-WARNING and GError. That's the c_glib library. Further it looks like all the "multi" protocol tests failed with c_glib on either the server or client side. I cannot merge this - it will break all future builds. You can run these tests in a docker sandbox, after "make precross" then you can do `test/test.py --client c_glib` to limit the tests to just c_glib clients. > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. We also need a > multiplexed processor for the server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1361 @gadLinux I think you need to re-read the error messages. It says GLib-WARNING and GError. That's the c_glib library. Further it looks like all the "multi" protocol tests failed with c_glib on either the server or client side. I cannot merge this - it will break all future builds. You can run these tests in a docker sandbox, after "make precross" then you can do `test/test.py --client c_glib` to limit the tests to just c_glib clients. ---
[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 Yes but this seems to be in other languages that are not in my scope. So it should be others that fix them. So I think it's good enough for now. Can you merge it? And maybe open a new bug to trac them? ---
[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249565#comment-16249565 ] ASF GitHub Bot commented on THRIFT-4329: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 Yes but this seems to be in other languages that are not in my scope. So it should be others that fix them. So I think it's good enough for now. Can you merge it? And maybe open a new bug to trac them? > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. We also need a > multiplexed processor for the server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-2913) Ruby Server Thrift::ThreadPoolServer should serve inside a thread
[
https://issues.apache.org/jira/browse/THRIFT-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249473#comment-16249473
]
James E. King, III commented on THRIFT-2913:
If someone with Ruby experience could figure this one out, it's causing builds
to fail in Travis CI and may be indicative of an issue that will cause problems
for folks... Thanks.
> Ruby Server Thrift::ThreadPoolServer should serve inside a thread
> -
>
> Key: THRIFT-2913
> URL: https://issues.apache.org/jira/browse/THRIFT-2913
> Project: Thrift
> Issue Type: Bug
> Components: Ruby - Library
>Affects Versions: 0.9.3, 0.10.0
> Environment: openSUSE 13.2, Ruby 2.1.0
> also in docker ubuntu-xenial image, per CI build job failure
>Reporter: Jens Geyer
> Attachments: full-error-message.txt
>
>
> make all fails with:
> {code}
> Server Thrift::ThreadPoolServer should serve inside a thread
> Failure/Error: Unable to find matching line from backtrace
>(#).serve(any args)
>expected: 1 time
>received: 0 times
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249458#comment-16249458 ] ASF GitHub Bot commented on THRIFT-4329: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1361 Job 6 failed due to https://issues.apache.org/jira/browse/THRIFT-2913 which pops up far too often. Job 4 failed legitimitely and indicates there is still something that needs to be fixed: ``` === *** Following 24 failures were unexpected ***: If it is introduced by you, please fix it before submitting the code. === server-client: protocol: transport: result: c_glib-csharp multi-binary framed-ip failure(timeout) c_glib-csharp multic-compactbuffered-ip failure(timeout) c_glib-csharp multic-compactframed-ip failure(timeout) c_glib-csharp multi-binary buffered-ip failure(timeout) c_glib-rs multicbuffered-ip failure(timeout) c_glib-rs multicframed-ip failure(timeout) c_glib-rs multi buffered-ip failure(timeout) c_glib-rs multi framed-ip failure(timeout) java-c_glib multicbuffered-ip failure(1) java-c_glib multicfastframed-framed-ip failure(1) java-c_glib multicbuffered-ip-ssl failure(1) java-c_glib multicfastframed-framed-ip-ssl failure(1) java-c_glib multicframed-ip failure(1) java-c_glib multicframed-ip-ssl failure(1) java-c_glib multi buffered-ip failure(1) java-c_glib multi buffered-ip-ssl failure(1) java-c_glib multi fastframed-framed-ip failure(1) java-c_glib multi fastframed-framed-ip-ssl failure(1) java-c_glib multi framed-ip failure(1) java-c_glib multi framed-ip-ssl failure(1) rs-c_glib multicbuffered-ip failure(1) rs-c_glib multi buffered-ip failure(1) rs-c_glib multicframed-ip failure(1) rs-c_glib multi framed-ip failure(1) === Unexpected failures are logged to test/log/unexpected_failures.log You can browse results at: file:///thrift/src/test/index.html # If you use Chrome, run: # cd /thrift/src # python -m http.server 8001 # then browse: # http://localhost:8001/test/ Full log for each test is here: test/log/server_client_protocol_transport_client.log test/log/server_client_protocol_transport_server.log 24 failed of 2590 tests in total. Test execution took 2038.7 seconds. Mon Nov 13 09:35:57 2017 Makefile:1097: recipe for target 'cross-.*' failed make: *** [cross-.*] Error 1 RET=$? if [ $RET -ne 0 ]; then cat test/log/unexpected_failures.log fi TEST: [c_glib-csharp_multi-binary_framed-ip] *** server message *** Mon Nov 13 09:03:46 2017 Executing: /thrift/src/test/c_glib/test_server --lt-debug --protocol=multi --transport=framed --port=36027 Directory: /thrift/src/test/c_glib config:delay: 5 config:timeout: 9 === test_server:test_server:93: libtool wrapper (GNU libtool) 2.4.6 Debian-2.4.6-0.1 test_server:test_server:114: newargv[0]: /thrift/src/test/c_glib/.libs/lt-test_server test_server:test_server:104: newargv[1]: --protocol=multi test_server:test_server:104: newargv[2]: --transport=framed test_server:test_server:104: newargv[3]: --port=36027 Starting "simple" server (framed/binary:multi) listen on: 36027 (lt-test_server:29796): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: message type invalid for this processor (lt-test_server:29796): GLib-WARNING **:
[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1361 Job 6 failed due to https://issues.apache.org/jira/browse/THRIFT-2913 which pops up far too often. Job 4 failed legitimitely and indicates there is still something that needs to be fixed: ``` === *** Following 24 failures were unexpected ***: If it is introduced by you, please fix it before submitting the code. === server-client: protocol: transport: result: c_glib-csharp multi-binary framed-ip failure(timeout) c_glib-csharp multic-compactbuffered-ip failure(timeout) c_glib-csharp multic-compactframed-ip failure(timeout) c_glib-csharp multi-binary buffered-ip failure(timeout) c_glib-rs multicbuffered-ip failure(timeout) c_glib-rs multicframed-ip failure(timeout) c_glib-rs multi buffered-ip failure(timeout) c_glib-rs multi framed-ip failure(timeout) java-c_glib multicbuffered-ip failure(1) java-c_glib multicfastframed-framed-ip failure(1) java-c_glib multicbuffered-ip-ssl failure(1) java-c_glib multicfastframed-framed-ip-ssl failure(1) java-c_glib multicframed-ip failure(1) java-c_glib multicframed-ip-ssl failure(1) java-c_glib multi buffered-ip failure(1) java-c_glib multi buffered-ip-ssl failure(1) java-c_glib multi fastframed-framed-ip failure(1) java-c_glib multi fastframed-framed-ip-ssl failure(1) java-c_glib multi framed-ip failure(1) java-c_glib multi framed-ip-ssl failure(1) rs-c_glib multicbuffered-ip failure(1) rs-c_glib multi buffered-ip failure(1) rs-c_glib multicframed-ip failure(1) rs-c_glib multi framed-ip failure(1) === Unexpected failures are logged to test/log/unexpected_failures.log You can browse results at: file:///thrift/src/test/index.html # If you use Chrome, run: # cd /thrift/src # python -m http.server 8001 # then browse: # http://localhost:8001/test/ Full log for each test is here: test/log/server_client_protocol_transport_client.log test/log/server_client_protocol_transport_server.log 24 failed of 2590 tests in total. Test execution took 2038.7 seconds. Mon Nov 13 09:35:57 2017 Makefile:1097: recipe for target 'cross-.*' failed make: *** [cross-.*] Error 1 RET=$? if [ $RET -ne 0 ]; then cat test/log/unexpected_failures.log fi TEST: [c_glib-csharp_multi-binary_framed-ip] *** server message *** Mon Nov 13 09:03:46 2017 Executing: /thrift/src/test/c_glib/test_server --lt-debug --protocol=multi --transport=framed --port=36027 Directory: /thrift/src/test/c_glib config:delay: 5 config:timeout: 9 === test_server:test_server:93: libtool wrapper (GNU libtool) 2.4.6 Debian-2.4.6-0.1 test_server:test_server:114: newargv[0]: /thrift/src/test/c_glib/.libs/lt-test_server test_server:test_server:104: newargv[1]: --protocol=multi test_server:test_server:104: newargv[2]: --transport=framed test_server:test_server:104: newargv[3]: --port=36027 Starting "simple" server (framed/binary:multi) listen on: 36027 (lt-test_server:29796): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: message type invalid for this processor (lt-test_server:29796): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: failed to read 4 bytes - Success ** Message: thrif
[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249297#comment-16249297 ] ASF GitHub Bot commented on THRIFT-4329: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 4197.6 Fails... I'm done. Don't know what else to do. Please check what is it... > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. We also need a > multiplexed processor for the server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 4197.6 Fails... I'm done. Don't know what else to do. Please check what is it... ---
[jira] [Commented] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249230#comment-16249230 ] ASF GitHub Bot commented on THRIFT-4329: Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 @jeking3 It doesn't fail for me, even in the docker container. Please review and merge. > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.10.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. We also need a > multiplexed processor for the server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1361: THRIFT-4329: Implement multiplexed processor that matche...
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1361 @jeking3 It doesn't fail for me, even in the docker container. Please review and merge. ---
