[jira] [Commented] (THRIFT-2441) Cannot shutdown TThreadedServer when clients are still connected
[ https://issues.apache.org/jira/browse/THRIFT-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386277#comment-14386277 ] Randy Abernethy commented on THRIFT-2441: - Hey Ben, I agree with your rational, however this patch applies after the listening socket has already been shutdown/closed, so the nasty case you describe is avoided. The exposure we are left with is an abortive close of a stream socket independent of the control thread. This could certainly cause a communications error but so could a broken network link (one of those things you just need to code for). While I don't think this server was broken before (it just waited for clients to close before exiting), I don't think it is broken now post patch either. Folks just need to know how stop() works. Now it means stop listening (first) and then disconnect all clients regardless of what they are in the middle of. Pull the plug. Signalling server threads to let them finish any in-progress RPC would certainly be nice but I might prefer the abortive close, used once in a rare while, to the extra clean shutdown overhead, used on every single recv. -Randy Cannot shutdown TThreadedServer when clients are still connected Key: THRIFT-2441 URL: https://issues.apache.org/jira/browse/THRIFT-2441 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.1 Reporter: Chris Stylianou Assignee: Roger Meier When calling stop() on the TThreadedServer no interrupts are sent to the client threads. This means the stop() call blocks on tasksMonitor.wait() until all client naturally disconnect. How can we tell the client thread connections to close/exit during the TThreadedServer::stop() call? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3059) Performance issues of TThreadedSelectorServer
[ https://issues.apache.org/jira/browse/THRIFT-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaoshuang LU updated THRIFT-3059: -- Description: Let's assume that there is a client or a thread talks with TThreadedSelectorServer by a transport. During this period, no other clients or threads could send or receive data via this transport, i.e. the transport is exclusive. As a result, the performance/throughput of the server could not be utilized as much as possible. On the other hand, if we don't care about the performance, could these transports be shared by different clients or threads? I am afraid that the answer is negative. Even we suppose that both reading messages from transports and writing messages to transports are atomic operations, transports still could not be multiplexed because clients do not know how to pick up their own responses from the stream. We may add queues to hold the calls at both client sides and server sides. I think Hadoop RPC provides a good reference implementation. was: Let's Assume that there is a client or a thread talks with TThreadedSelectorServer by a transport. During this period, no other clients or threads could send or receive data via this transport, i.e. the transport is exclusive. As a result, the performance/throughput of the server could not be utilized as much as possible. On the other hand, if we don't care about the performance, could these transports be shared by different clients or threads? I am afraid that the answer is negative. Even we suppose that both reading messages from transports and writing messages to transports are atomic operations, transports still could not be multiplexed because clients do not know how to pick up their own responses from the stream. We may add queues to hold the calls at both client sides and server sides. I think Hadoop RPC provides a good reference implementation. Performance issues of TThreadedSelectorServer --- Key: THRIFT-3059 URL: https://issues.apache.org/jira/browse/THRIFT-3059 Project: Thrift Issue Type: Improvement Components: Java - Library Affects Versions: 0.9.2 Reporter: Xiaoshuang LU Priority: Critical Let's assume that there is a client or a thread talks with TThreadedSelectorServer by a transport. During this period, no other clients or threads could send or receive data via this transport, i.e. the transport is exclusive. As a result, the performance/throughput of the server could not be utilized as much as possible. On the other hand, if we don't care about the performance, could these transports be shared by different clients or threads? I am afraid that the answer is negative. Even we suppose that both reading messages from transports and writing messages to transports are atomic operations, transports still could not be multiplexed because clients do not know how to pick up their own responses from the stream. We may add queues to hold the calls at both client sides and server sides. I think Hadoop RPC provides a good reference implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3059) Performance issues of TThreadedSelectorServer
[ https://issues.apache.org/jira/browse/THRIFT-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaoshuang LU updated THRIFT-3059: -- Description: Let's Assume that there is a client or a thread talks with TThreadedSelectorServer by a transport. During this period, no other clients or threads could send or receive data via this transport, i.e. the transport is exclusive. As a result, the performance/throughput of the server could not be utilized as much as possible. On the other hand, if we don't care about the performance, could these transports be shared by different clients or threads? I am afraid that the answer is negative. Even we suppose that both reading messages from transports and writing messages to transports are atomic operations, transports still could not be multiplexed because clients do not know how to pick up their own responses from the stream. We may add queues to hold the calls at both client sides and server sides. I think Hadoop RPC provides a good reference implementation. was: Assuming there is a client or a thread talks with TThreadedSelectorServer by a transport, no other clients or threads could send or receive data via this transport during this period, i.e. the transport is exclusive. As a result, the performance/throughput of the server could not be utilized as much as possible. On the other hand, if we don't care about the performance, could these transports be shared by different clients or threads? As far as I know, the answer is negative. Even we suppose that both reading messages from and writing messages to transport are atomic operations, transports still could not be multiplexed because clients do not know how to pick up their own responses from the stream. We may add queues to hold the calls at both client sides and server sides. I think Hadoop RPC provides a good reference implementation. Performance issues of TThreadedSelectorServer --- Key: THRIFT-3059 URL: https://issues.apache.org/jira/browse/THRIFT-3059 Project: Thrift Issue Type: Improvement Components: Java - Library Affects Versions: 0.9.2 Reporter: Xiaoshuang LU Priority: Critical Let's Assume that there is a client or a thread talks with TThreadedSelectorServer by a transport. During this period, no other clients or threads could send or receive data via this transport, i.e. the transport is exclusive. As a result, the performance/throughput of the server could not be utilized as much as possible. On the other hand, if we don't care about the performance, could these transports be shared by different clients or threads? I am afraid that the answer is negative. Even we suppose that both reading messages from transports and writing messages to transports are atomic operations, transports still could not be multiplexed because clients do not know how to pick up their own responses from the stream. We may add queues to hold the calls at both client sides and server sides. I think Hadoop RPC provides a good reference implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request: Add compiler/cpp/lex.yythriftl.cc to gitignor...
GitHub user huerlisi opened a pull request: https://github.com/apache/thrift/pull/412 Add compiler/cpp/lex.yythriftl.cc to gitignore. I've accidentially checked that file in in another PR. So this commit adds that file to the .gitignore. Might be that this is only a temporary file, as I got some compiling issues. Should be ignored anyway. You can merge this pull request into a Git repository by running: $ git pull https://github.com/huerlisi/thrift fixes/ignore-yacc-output Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/412.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 #412 commit 415549dd77f443b7d626c013a679fb893f773257 Author: Simon Hürlimann (CyT) simon.huerlim...@cyt.ch Date: 2015-03-30T10:54:15Z Add compiler/cpp/lex.yythriftl.cc to gitignore. I've accidentially checked that file in in another PR. So this commit adds that file to the .gitignore. Might be that this is only a temporary file, as I got some compiling issues. Should be ignored anyway. --- 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-2441) Cannot shutdown TThreadedServer when clients are still connected
[
https://issues.apache.org/jira/browse/THRIFT-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386646#comment-14386646
]
James E. King, III commented on THRIFT-2441:
I believe this change is an improvement for the reason Randy suggested - this
is analogous to a network disconnect, and all Thrift based implementations that
require idempotent behavior must already account for that, therefore this
change imposes no additional requirements on any implementation.
One could certainly file an enhancement request to change stop to take a
{{const boost::posix_time::time_duration}} so that the caller can decide how
long to wait for the open handler requests to complete if folks want the
ability to control this. That would not be difficult to do.
Cannot shutdown TThreadedServer when clients are still connected
Key: THRIFT-2441
URL: https://issues.apache.org/jira/browse/THRIFT-2441
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.9.1
Reporter: Chris Stylianou
Assignee: Roger Meier
When calling stop() on the TThreadedServer no interrupts are sent to the
client threads. This means the stop() call blocks on tasksMonitor.wait()
until all client naturally disconnect.
How can we tell the client thread connections to close/exit during the
TThreadedServer::stop() call?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2441) Cannot shutdown TThreadedServer when clients are still connected
[ https://issues.apache.org/jira/browse/THRIFT-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386681#comment-14386681 ] Ben Craig commented on THRIFT-2441: --- however this patch applies after the listening socket has already been shutdown/closed That is making the assumption that this Thrift server is the only thing in the process dealing with sockets. I routinely deal with processes that have three or four different 'things' dealing with sockets. The thrift worker thread may end up 'stealing' an http connection from an entirely different code base. The case that I had to fix in the wild involved a Microsoft RPC server connection getting stolen by some mDNS IPC code that was using a closed socket, pretty much in exactly this kind of use case. Cannot shutdown TThreadedServer when clients are still connected Key: THRIFT-2441 URL: https://issues.apache.org/jira/browse/THRIFT-2441 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.1 Reporter: Chris Stylianou Assignee: Roger Meier When calling stop() on the TThreadedServer no interrupts are sent to the client threads. This means the stop() call blocks on tasksMonitor.wait() until all client naturally disconnect. How can we tell the client thread connections to close/exit during the TThreadedServer::stop() call? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2441) Cannot shutdown TThreadedServer when clients are still connected
[ https://issues.apache.org/jira/browse/THRIFT-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386696#comment-14386696 ] Ben Craig commented on THRIFT-2441: --- When there is a network disconnect, the socket handle is still valid, even though the underlying connection is dead. The code for ThreadedServer prior to this change didn't ever touch a transport after the transport had been closed, even in cases where a connection was reset / aborted. Cannot shutdown TThreadedServer when clients are still connected Key: THRIFT-2441 URL: https://issues.apache.org/jira/browse/THRIFT-2441 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.1 Reporter: Chris Stylianou Assignee: Roger Meier When calling stop() on the TThreadedServer no interrupts are sent to the client threads. This means the stop() call blocks on tasksMonitor.wait() until all client naturally disconnect. How can we tell the client thread connections to close/exit during the TThreadedServer::stop() call? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2441) Cannot shutdown TThreadedServer when clients are still connected
[ https://issues.apache.org/jira/browse/THRIFT-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386751#comment-14386751 ] James E. King, III commented on THRIFT-2441: The code in TSocket and TSSLSocket both protect against a double close by setting the socket value to something invalid and testing for it. Any transport close() must defend against this behavior. This means socket close happens once and only once, however since the TThreadedServer::Task::run() calls close() in the task thread and the newly added stop() calls close() in another thread, they need to be mutually exclusive for it truly to be once and only once, and this patch doesn't do that. Thank you for pointing this out. Cannot shutdown TThreadedServer when clients are still connected Key: THRIFT-2441 URL: https://issues.apache.org/jira/browse/THRIFT-2441 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.1 Reporter: Chris Stylianou Assignee: Roger Meier When calling stop() on the TThreadedServer no interrupts are sent to the client threads. This means the stop() call blocks on tasksMonitor.wait() until all client naturally disconnect. How can we tell the client thread connections to close/exit during the TThreadedServer::stop() call? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2441) Cannot shutdown TThreadedServer when clients are still connected
[ https://issues.apache.org/jira/browse/THRIFT-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386763#comment-14386763 ] Ben Craig commented on THRIFT-2441: --- I am leery in general of closing a transport in one thread and reading from the transport in another thread, without any thread synchronization between them. Cannot shutdown TThreadedServer when clients are still connected Key: THRIFT-2441 URL: https://issues.apache.org/jira/browse/THRIFT-2441 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.1 Reporter: Chris Stylianou Assignee: Roger Meier When calling stop() on the TThreadedServer no interrupts are sent to the client threads. This means the stop() call blocks on tasksMonitor.wait() until all client naturally disconnect. How can we tell the client thread connections to close/exit during the TThreadedServer::stop() call? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request: Fixes nodejs readme syntax
GitHub user huerlisi opened a pull request: https://github.com/apache/thrift/pull/411 Fixes nodejs readme syntax The README for nodejs examples had strange syntax letting Markdown thinking everything is a header. You can merge this pull request into a Git repository by running: $ git pull https://github.com/huerlisi/thrift fixes/nodejs-readme-syntax Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/411.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 #411 commit 3659cc77e3e7446f91b92031c5d60aeaf0438759 Author: Simon Hürlimann (CyT) simon.huerlim...@cyt.ch Date: 2015-03-30T10:37:48Z nodejs: Fix Markdown syntax for README. commit b57d312fcd360b03eb6d2bc5fb8318c6eab05150 Author: Simon Hürlimann (CyT) simon.huerlim...@cyt.ch Date: 2015-03-30T10:45:03Z nodejs: Add main header to example README. --- 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: Fixes nodejs readme syntax
Github user huerlisi commented on the pull request: https://github.com/apache/thrift/pull/411#issuecomment-87633148 Fixed, ready for review. --- 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: Fixes nodejs readme syntax
Github user huerlisi commented on the pull request: https://github.com/apache/thrift/pull/411#issuecomment-87639738 The failing test (Haskel: https://travis-ci.org/apache/thrift/jobs/56395742) seems to be unrelated to my changes. --- 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: Fixes nodejs readme syntax
Github user huerlisi commented on the pull request: https://github.com/apache/thrift/pull/411#issuecomment-87632748 Sorry, accidentally checked in a generated file, will fix and amend the last commit. --- 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] [Created] (THRIFT-3059) Performance issues of TThreadedSelectorServer
Xiaoshuang LU created THRIFT-3059: - Summary: Performance issues of TThreadedSelectorServer Key: THRIFT-3059 URL: https://issues.apache.org/jira/browse/THRIFT-3059 Project: Thrift Issue Type: Improvement Components: Java - Library Affects Versions: 0.9.2 Reporter: Xiaoshuang LU Priority: Critical Assuming there is a client or a thread talks with TThreadedSelectorServer by a transport, no other clients or threads could send or receive data via this transport during this period, i.e. the transport is exclusive. As a result, the performance/throughput of the server could not be utilized as much as possible. On the other hand, if we don't care about the performance, could these transports be shared by different clients or threads? As far as I know, the answer is negative. Even we suppose that both reading messages from and writing messages to transport are atomic operations, transports still could not be multiplexed because clients do not know how to pick up their own responses from the stream. We may add queues to hold the calls at both client sides and server sides. I think Hadoop RPC provides a good reference implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2441) Cannot shutdown TThreadedServer when clients are still connected
[ https://issues.apache.org/jira/browse/THRIFT-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386836#comment-14386836 ] James E. King, III commented on THRIFT-2441: I understand now, and your original comment makes sense. As such, it sounds like we should back out this change for now, as we need a fix that can properly force a close from the server side without the possibility of reading from an unexpected file descriptor. Another reference for this discussion, although it is over 4 years old: http://stackoverflow.com/questions/3624365/blocking-recv-doesnt-exit-when-closing-socket-from-another-thread Cannot shutdown TThreadedServer when clients are still connected Key: THRIFT-2441 URL: https://issues.apache.org/jira/browse/THRIFT-2441 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.1 Reporter: Chris Stylianou Assignee: Roger Meier When calling stop() on the TThreadedServer no interrupts are sent to the client threads. This means the stop() call blocks on tasksMonitor.wait() until all client naturally disconnect. How can we tell the client thread connections to close/exit during the TThreadedServer::stop() call? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3060) Node.js client retry logic doesn't flush offline queue on reconnect
[ https://issues.apache.org/jira/browse/THRIFT-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386927#comment-14386927 ] ASF GitHub Bot commented on THRIFT-3060: Github user cjthompson commented on the pull request: https://github.com/apache/thrift/pull/395#issuecomment-87740047 I submitted a patch to issue THRIFT-3060. Node.js client retry logic doesn't flush offline queue on reconnect --- Key: THRIFT-3060 URL: https://issues.apache.org/jira/browse/THRIFT-3060 Project: Thrift Issue Type: Bug Components: Node.js - Library Affects Versions: 0.9.2 Reporter: Chris Thompson Priority: Minor Attachments: thrift-3060-fix_retry_logic.patch The Node.js client includes retry logic in case the connection terminates unexpectedly. On reconnect, the `offline_queue` variable never gets reset, so any requests still in the queue will get processed on every reconnect. In addition, the variables the keep track of the retry state are not initialized prior to a successful connection, meaning that if the initial connection doesn't succeed, that the retry timer is set to `NaN` and doesn't work as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (THRIFT-3061) C++ TSSLSocket shutdown delay/vulnerability
James E. King, III created THRIFT-3061:
--
Summary: C++ TSSLSocket shutdown delay/vulnerability
Key: THRIFT-3061
URL: https://issues.apache.org/jira/browse/THRIFT-3061
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.9.2, 0.9.1, 0.9, 0.8
Reporter: James E. King, III
In the C++ implementation of TSSLSocket, during close() the following code
sequence is found:
{noformat}
void TSSLSocket::close() {
if (ssl_ != NULL) {
int rc = SSL_shutdown(ssl_);
if (rc == 0) {
rc = SSL_shutdown(ssl_);
}
{noformat}
According to the OpenSSL documentation, while it is nice to attempt to
shutdown SSL in this way, it is not required when the code is performing a
unilateral shutdown (meaning the underlying connection will be closed). It is
only necessary to call SSL_Shutdown twice like this if the socket (and
configured SSL therein) is going to be reused.
It is possible to have a misbehaving client that does not handle this part of
the shutdown process properly and fail to reply, and also fail to close. The
most likely embodiment would be a program designed specifically to fail to
reply to the close notify and hold the socket open in order to produce a
denial-of-service attack. Another possibility is a poorly written client.
Given the OpenSSL documentation states that calling SSL_Shutdown once is
sufficient when the socket is going to be closed, I recommend that we remove
the second SSL_Shutdown call and prevent something that can block the close()
call. We have seen this happen, and it interacts with THRIFT-2441.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2441) Cannot shutdown TThreadedServer when clients are still connected
[ https://issues.apache.org/jira/browse/THRIFT-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386953#comment-14386953 ] Randy Abernethy commented on THRIFT-2441: - Indeed, good example. Cannot shutdown TThreadedServer when clients are still connected Key: THRIFT-2441 URL: https://issues.apache.org/jira/browse/THRIFT-2441 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.1 Reporter: Chris Stylianou Assignee: Roger Meier When calling stop() on the TThreadedServer no interrupts are sent to the client threads. This means the stop() call blocks on tasksMonitor.wait() until all client naturally disconnect. How can we tell the client thread connections to close/exit during the TThreadedServer::stop() call? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (THRIFT-3062) C++ TServerSocket invalid port number (over 999999) causes stack corruption
James E. King, III created THRIFT-3062:
--
Summary: C++ TServerSocket invalid port number (over 99)
causes stack corruption
Key: THRIFT-3062
URL: https://issues.apache.org/jira/browse/THRIFT-3062
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.9.2
Reporter: James E. King, III
In {{TServerSocket::listen()}} a buffer of size 7 is allocated for the string
to numeric translation of the port number, defined as {{int}}:
{noformat} char port[sizeof(65536) + 1];
...
sprintf(port, %d, port_);{noformat}
An input of 100 or more will cause stack corruption. Recommend changing
sprintf to something safer, or making a larger buffer. In this case, one can
safely allocate a fixed size buffer on the stack to accomodate the largest
result possible, avoiding the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3033) Perl: Support for Multiplexing Services on any Transport, Protocol and Server
[
https://issues.apache.org/jira/browse/THRIFT-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14387522#comment-14387522
]
Jens Geyer commented on THRIFT-3033:
Hi [~hs2323],
I modified the makefile and added a bunch of {{use strict}}. You may find the
result in my GitHub repo at
https://github.com/Jens-G/thrift/tree/THRIFT-3033-perl-multiplex. Please use
that as a base, I'll make the final patch out of that branch when all tests
succeed.
When running {{make check}} I get this:
{code}
make check
Making check in test
make[1]: Entering directory '/home/jens/Desktop/Thrift/lib/perl/test'
make check-local
make[2]: Entering directory '/home/jens/Desktop/Thrift/lib/perl/test'
../../../compiler/cpp/thrift --gen perl
../../../lib/rb/benchmark/Benchmark.thrift
../../../compiler/cpp/thrift --gen perl ../../../contrib/async-test/aggr.thrift
make[2]: Leaving directory '/home/jens/Desktop/Thrift/lib/perl/test'
make[1]: Leaving directory '/home/jens/Desktop/Thrift/lib/perl/test'
make[1]: Entering directory '/home/jens/Desktop/Thrift/lib/perl'
make -f Makefile-perl.mk
make[2]: Entering directory '/home/jens/Desktop/Thrift/lib/perl'
make[2]: Leaving directory '/home/jens/Desktop/Thrift/lib/perl'
find blib -name 'Makefile*' -exec rm -f {} \;
make check-local
make[2]: Entering directory '/home/jens/Desktop/Thrift/lib/perl'
/usr/bin/perl -Iblib/lib -I/home/jens/Desktop/Thrift/lib/perl -I./test/gen-perl
\
/home/jens/Desktop/Thrift/lib/perl/test.pl
/home/jens/Desktop/Thrift/lib/perl/test/*.t
/home/jens/Desktop/Thrift/lib/perl/test/memory_buffer.t .. ok
/home/jens/Desktop/Thrift/lib/perl/test/multiplex.t .. Can't locate
Thrift/MultiplexedProcessor.pm in @INC (you may need to install the
Thrift::MultiplexedProcessor module) (@INC contains: blib/lib
/home/jens/Desktop/Thrift/lib/perl ./test/gen-perl
/home/jens/perl5/lib/perl5/i586-linux-thread-multi
/home/jens/perl5/lib/perl5/i586-linux-thread-multi /home/jens/perl5/lib/perl5
/home/jens/perl5/lib/perl5/i586-linux-thread-multi /home/jens/perl5/lib/perl5
/home/jens/perl5/lib/perl5/i586-linux-thread-multi /home/jens/perl5/lib/perl5
/usr/lib/perl5/site_perl/5.20.1/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.20.1
/usr/lib/perl5/vendor_perl/5.20.1/i586-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.20.1 /usr/lib/perl5/5.20.1/i586-linux-thread-multi
/usr/lib/perl5/5.20.1 /usr/lib/perl5/site_perl .) at
/home/jens/Desktop/Thrift/lib/perl/test/multiplex.t line 28.
BEGIN failed--compilation aborted at
/home/jens/Desktop/Thrift/lib/perl/test/multiplex.t line 28.
# Looks like your test exited with 2 before it could output anything.
/home/jens/Desktop/Thrift/lib/perl/test/multiplex.t .. Dubious, test
returned 2 (wstat 512, 0x200)
Failed 6/6 subtests
/home/jens/Desktop/Thrift/lib/perl/test/processor.t .. ok
Test Summary Report
---
/home/jens/Desktop/Thrift/lib/perl/test/multiplex.t(Wstat: 512 Tests: 0
Failed: 0)
Non-zero exit status: 2
Parse errors: Bad plan. You planned 6 tests but ran 0.
Files=3, Tests=8, 4 wallclock secs ( 0.08 usr 0.17 sys + 0.57 cusr 0.51
csys = 1.33 CPU)
Result: FAIL
Failed 1/3 test programs. 0/8 subtests failed.
Makefile:778: recipe for target 'check-local' failed
make[2]: *** [check-local] Error 255
make[2]: Leaving directory '/home/jens/Desktop/Thrift/lib/perl'
Makefile:647: recipe for target 'check-am' failed
make[1]: *** [check-am] Error 2
make[1]: Leaving directory '/home/jens/Desktop/Thrift/lib/perl'
Makefile:498: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1
{code}
Perl: Support for Multiplexing Services on any Transport, Protocol and Server
-
Key: THRIFT-3033
URL: https://issues.apache.org/jira/browse/THRIFT-3033
Project: Thrift
Issue Type: Sub-task
Reporter: Shankar Narayan
Assignee: Jens Geyer
Attachments: MessageType.pm, MultiplexedProcessor.pm,
MultiplexedProtocol.pm, ProtocolDecorator.pm
Currently there is no support for mutliplexing services via perl.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3051) Go Thrift generator creates bad go code
[
https://issues.apache.org/jira/browse/THRIFT-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14387362#comment-14387362
]
Jens Geyer commented on THRIFT-3051:
Hi [~swsnider],
would it be possible for you to submit a patch or pull request?
Go Thrift generator creates bad go code
---
Key: THRIFT-3051
URL: https://issues.apache.org/jira/browse/THRIFT-3051
Project: Thrift
Issue Type: Bug
Components: Go - Compiler
Affects Versions: 0.9.2, 1.0
Environment: Mac OS X 10.10.2
Thrift 0.9.2 installed via homebrew, and Thrift HEAD (identifies as
1.0.0-dev) installed via homebrew
Reporter: Silas Snider
h2. Motivation
I was attempting to build a go tool that used the Apache Aurora thrift
interface, only to be stymied because thrift generates invalid code for the
current api.thrift interface. (found under
api/src/main/thrift/org/apache/aurora/gen/api.thrift)
h2. Steps to replicate
# Create a thrift file called test.thrift containing the text:
{code:title=test.thrift|borderStyle=solid}
struct Option1 {
}
struct Option2 {
1: optional string name
}
union Descendant {
1: Option1 option1
2: Option2 option2
}
struct TestStruct {
1: optional Descendant descendant = { option1: {}}
}
{code}
# Run {{thrift -o somedir -r --gen go test.thrift}}
h2. Expected Result
The command indicates success, and the {{somedir}} directory contains a tree
of go code that successfully compiles.
h2. Actual Result
The above command outputs
{code}
/somedir/gen-go//test/ttypes.go:317:6: expected '}', found ':='
/somedir/gen-go//test/ttypes.go:318:3: expected declaration, found 'IDENT'
descendant
WARNING - Running 'gofmt -w /somedir/gen-go//test/ttypes.go' failed.
{code}
The code fails to compile with similar errors. On inspection, it appears that
the go compiler outputs
{code:title=ttypes.go|borderStyle=solid}
var TestStruct_Descendant_DEFAULT *Descendant = Descendant{
v1 := Option1{}
descendant.Option1 = v1}
{code}
which is entirely incorrect. This code should instead be
{code:title=ttypes.go|borderStyle=solid}
var TestStruct_Descendant_DEFAULT *Descendant = Descendant{
Option1: Option1{}}
{code}
When this change is made, the compilation succeeds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3050) Client certificate authentication for non-http TLS in C#
[ https://issues.apache.org/jira/browse/THRIFT-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14387528#comment-14387528 ] Hudson commented on THRIFT-3050: SUCCESS: Integrated in Thrift #1487 (See [https://builds.apache.org/job/Thrift/1487/]) THRIFT-3050 Client certificate authentication for non-http TLS in C# (jensg: rev af577247c9b6af55f8828d56e10d4db7298cb97e) * lib/csharp/src/Transport/TTLSServerSocket.cs * lib/csharp/src/Transport/TTLSSocket.cs Client certificate authentication for non-http TLS in C# Key: THRIFT-3050 URL: https://issues.apache.org/jira/browse/THRIFT-3050 Project: Thrift Issue Type: New Feature Components: C# - Library Affects Versions: 0.9.2 Reporter: Hans-Peter Klett Assignee: Jens Geyer Labels: security Fix For: 0.9.3 Currently I don't see a way for the server to authenticate the client certificate. Related issues: THRIFT-181 - Superceded by THRIFT-2347, but mentions lack of client certificate validation THRIFT-2347 - Added TLS support. THRIFT-2455 - Adds client certificate validation for HTTP, but not regular TLS THRIFT-2568 - Added validator support for server TLS certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3051) Go Thrift generator creates bad go code
[
https://issues.apache.org/jira/browse/THRIFT-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14387386#comment-14387386
]
Silas Snider commented on THRIFT-3051:
--
No: I took a look at the generator code, and a) I don't know C++ very well, b)
even with the knowledge I do have, it's really non-obvious to me what to
change, and c) I haven't gone through the process to get my employer's OK
before contributing a patch, so that'd also lengthen the time it would take for
me to submit one. Sorry.
Go Thrift generator creates bad go code
---
Key: THRIFT-3051
URL: https://issues.apache.org/jira/browse/THRIFT-3051
Project: Thrift
Issue Type: Bug
Components: Go - Compiler
Affects Versions: 0.9.2, 1.0
Environment: Mac OS X 10.10.2
Thrift 0.9.2 installed via homebrew, and Thrift HEAD (identifies as
1.0.0-dev) installed via homebrew
Reporter: Silas Snider
h2. Motivation
I was attempting to build a go tool that used the Apache Aurora thrift
interface, only to be stymied because thrift generates invalid code for the
current api.thrift interface. (found under
api/src/main/thrift/org/apache/aurora/gen/api.thrift)
h2. Steps to replicate
# Create a thrift file called test.thrift containing the text:
{code:title=test.thrift|borderStyle=solid}
struct Option1 {
}
struct Option2 {
1: optional string name
}
union Descendant {
1: Option1 option1
2: Option2 option2
}
struct TestStruct {
1: optional Descendant descendant = { option1: {}}
}
{code}
# Run {{thrift -o somedir -r --gen go test.thrift}}
h2. Expected Result
The command indicates success, and the {{somedir}} directory contains a tree
of go code that successfully compiles.
h2. Actual Result
The above command outputs
{code}
/somedir/gen-go//test/ttypes.go:317:6: expected '}', found ':='
/somedir/gen-go//test/ttypes.go:318:3: expected declaration, found 'IDENT'
descendant
WARNING - Running 'gofmt -w /somedir/gen-go//test/ttypes.go' failed.
{code}
The code fails to compile with similar errors. On inspection, it appears that
the go compiler outputs
{code:title=ttypes.go|borderStyle=solid}
var TestStruct_Descendant_DEFAULT *Descendant = Descendant{
v1 := Option1{}
descendant.Option1 = v1}
{code}
which is entirely incorrect. This code should instead be
{code:title=ttypes.go|borderStyle=solid}
var TestStruct_Descendant_DEFAULT *Descendant = Descendant{
Option1: Option1{}}
{code}
When this change is made, the compilation succeeds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3050) Client certificate authentication for non-http TLS in C#
[ https://issues.apache.org/jira/browse/THRIFT-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14387477#comment-14387477 ] ASF GitHub Bot commented on THRIFT-3050: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/410 Client certificate authentication for non-http TLS in C# Key: THRIFT-3050 URL: https://issues.apache.org/jira/browse/THRIFT-3050 Project: Thrift Issue Type: New Feature Components: C# - Library Affects Versions: 0.9.2 Reporter: Hans-Peter Klett Assignee: Jens Geyer Labels: security Currently I don't see a way for the server to authenticate the client certificate. Related issues: THRIFT-181 - Superceded by THRIFT-2347, but mentions lack of client certificate validation THRIFT-2347 - Added TLS support. THRIFT-2455 - Adds client certificate validation for HTTP, but not regular TLS THRIFT-2568 - Added validator support for server TLS certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request: THRIFT-3050 TLS Client cert validation TLS C#
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/410 --- 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-3050) Client certificate authentication for non-http TLS in C#
[ https://issues.apache.org/jira/browse/THRIFT-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-3050. Resolution: Fixed Fix Version/s: 0.9.3 Committed, thank you! Client certificate authentication for non-http TLS in C# Key: THRIFT-3050 URL: https://issues.apache.org/jira/browse/THRIFT-3050 Project: Thrift Issue Type: New Feature Components: C# - Library Affects Versions: 0.9.2 Reporter: Hans-Peter Klett Assignee: Jens Geyer Labels: security Fix For: 0.9.3 Currently I don't see a way for the server to authenticate the client certificate. Related issues: THRIFT-181 - Superceded by THRIFT-2347, but mentions lack of client certificate validation THRIFT-2347 - Added TLS support. THRIFT-2455 - Adds client certificate validation for HTTP, but not regular TLS THRIFT-2568 - Added validator support for server TLS certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3062) C++ TServerSocket invalid port number (over 999999) causes stack corruption
[
https://issues.apache.org/jira/browse/THRIFT-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-3062:
---
Labels: security (was: )
C++ TServerSocket invalid port number (over 99) causes stack corruption
---
Key: THRIFT-3062
URL: https://issues.apache.org/jira/browse/THRIFT-3062
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.9.2
Reporter: James E. King, III
Labels: security
In {{TServerSocket::listen()}} a buffer of size 7 is allocated for the string
to numeric translation of the port number, defined as {{int}}:
{noformat} char port[sizeof(65536) + 1];
...
sprintf(port, %d, port_);{noformat}
An input of 100 or more will cause stack corruption. Recommend changing
sprintf to something safer, or making a larger buffer. In this case, one can
safely allocate a fixed size buffer on the stack to accomodate the largest
result possible, avoiding the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-3060) Node.js client retry logic doesn't flush offline queue on reconnect
[ https://issues.apache.org/jira/browse/THRIFT-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Thompson updated THRIFT-3060: --- Attachment: thrift-3060-fix_retry_logic.patch Node.js client retry logic doesn't flush offline queue on reconnect --- Key: THRIFT-3060 URL: https://issues.apache.org/jira/browse/THRIFT-3060 Project: Thrift Issue Type: Bug Components: Node.js - Library Affects Versions: 0.9.2 Reporter: Chris Thompson Priority: Minor Attachments: thrift-3060-fix_retry_logic.patch The Node.js client includes retry logic in case the connection terminates unexpectedly. On reconnect, the `offline_queue` variable never gets reset, so any requests still in the queue will get processed on every reconnect. In addition, the variables the keep track of the retry state are not initialized prior to a successful connection, meaning that if the initial connection doesn't succeed, that the retry timer is set to `NaN` and doesn't work as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request: NodeJS Client: Fix connection retry logic
Github user cjthompson commented on the pull request: https://github.com/apache/thrift/pull/395#issuecomment-87740047 I submitted a patch to issue THRIFT-3060. --- 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-3060) Node.js client retry logic doesn't flush offline queue on reconnect
[ https://issues.apache.org/jira/browse/THRIFT-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14386926#comment-14386926 ] Chris Thompson commented on THRIFT-3060: See GitHub PR : https://github.com/apache/thrift/pull/395 Node.js client retry logic doesn't flush offline queue on reconnect --- Key: THRIFT-3060 URL: https://issues.apache.org/jira/browse/THRIFT-3060 Project: Thrift Issue Type: Bug Components: Node.js - Library Affects Versions: 0.9.2 Reporter: Chris Thompson Priority: Minor Attachments: thrift-3060-fix_retry_logic.patch The Node.js client includes retry logic in case the connection terminates unexpectedly. On reconnect, the `offline_queue` variable never gets reset, so any requests still in the queue will get processed on every reconnect. In addition, the variables the keep track of the retry state are not initialized prior to a successful connection, meaning that if the initial connection doesn't succeed, that the retry timer is set to `NaN` and doesn't work as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
