[jira] [Comment Edited] (THRIFT-4594) Unable to Build Test Suite in Alpine Linux
[
https://issues.apache.org/jira/browse/THRIFT-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16535965#comment-16535965
]
Christopher Friedt edited comment on THRIFT-4594 at 7/8/18 3:01 AM:
Aha!
Maybe I was too quick to lay blame. Was just instrumenting TServerSocket.cpp
and it's trying to bind to port 0 on ::1. However, Docker containers do not
support IPv6 (at least not by default), hence bind(2) fails with EADDRNOTAVAIL.
There is no effort made (in TServerSocket::listen()) to retry with AF_INET when
AF_INET6 fails.
What is particularly odd, is that getaddrinfo(3) returns an IPv6 address to
begin with, given that none exist (particularly not on lo).
{code}
~/thrift/src/thrift-0.11.0/lib/cpp/test $ ./UnitTests
Running 51 test cases...
virtual void apache::thrift::transport::TServerSocket::listen(): 518:
attempting to bind to { sin6_family: AF_INET6, sin6_port: 0, sin6_addr: ::1
}
Thrift: Sun Jul 8 01:22:54 2018 TServerSocket::listen() BIND 0
unknown location(0): fatal error: in "TServerSocketTest/test_bind_to_address":
apache::thrift::transport::TTransportException: Could not bind: Address not
available
TServerSocketTest.cpp(35): last checkpoint: "test_bind_to_address" entry.
*** 1 failure is detected in the test module "thrift"
~/thrift/src/thrift-0.11.0/lib/cpp/test $ ifconfig -a
eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02
inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:65839 errors:0 dropped:0 overruns:0 frame:0
TX packets:35873 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:92097704 (87.8 MiB) TX bytes:2303356 (2.1 MiB)
ip6tnl0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1452 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
tunl0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-3C-A6-00-00-00-00-00-00-00-00
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
{code}
was (Author: cfriedt):
Aha!
Maybe I was too quick to lay blame. Was just instrumenting TServerSocket.cpp
and it's trying to bind to port 0 on ::1. However, Docker containers do not
support IPv6 (at least not by default), hence bind(2) fails with ENOADDR.
There is no effort made (in TServerSocket::listen()) to retry with AF_INET when
AF_INET6 fails.
What is particularly odd, is that getaddrinfo(3) returns an IPv6 address to
begin with, given that none exist (particularly not on lo).
{code}
~/thrift/src/thrift-0.11.0/lib/cpp/test $ ./UnitTests
Running 51 test cases...
virtual void apache::thrift::transport::TServerSocket::listen(): 518:
attempting to bind to { sin6_family: AF_INET6, sin6_port: 0, sin6_addr: ::1
}
Thrift: Sun Jul 8 01:22:54 2018 TServerSocket::listen() BIND 0
unknown location(0): fatal error: in "TServerSocketTest/test_bind_to_address":
apache::thrift::transport::TTransportException: Could not bind: Address not
available
TServerSocketTest.cpp(35): last checkpoint: "test_bind_to_address" entry.
*** 1 failure is detected in the test module "thrift"
~/thrift/src/thrift-0.11.0/lib/cpp/test $ ifconfig -a
eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02
inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:65839 errors:0 dropped:0 overruns:0 frame:0
TX packets:35873 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:92097704 (87.8 MiB) TX bytes:2303356 (2.1 MiB)
ip6tnl0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1452 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
[jira] [Commented] (THRIFT-4594) Unable to Build Test Suite in Alpine Linux
[
https://issues.apache.org/jira/browse/THRIFT-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16535965#comment-16535965
]
Christopher Friedt commented on THRIFT-4594:
Aha!
Maybe I was too quick to lay blame. Was just instrumenting TServerSocket.cpp
and it's trying to bind to port 0 on ::1. However, Docker containers do not
support IPv6 (at least not by default), hence bind(2) fails with ENOADDR.
There is no effort made (in TServerSocket::listen()) to retry with AF_INET when
AF_INET6 fails.
What is particularly odd, is that getaddrinfo(3) returns an IPv6 address to
begin with, given that none exist (particularly not on lo).
{code}
~/thrift/src/thrift-0.11.0/lib/cpp/test $ ./UnitTests
Running 51 test cases...
virtual void apache::thrift::transport::TServerSocket::listen(): 518:
attempting to bind to { sin6_family: AF_INET6, sin6_port: 0, sin6_addr: ::1
}
Thrift: Sun Jul 8 01:22:54 2018 TServerSocket::listen() BIND 0
unknown location(0): fatal error: in "TServerSocketTest/test_bind_to_address":
apache::thrift::transport::TTransportException: Could not bind: Address not
available
TServerSocketTest.cpp(35): last checkpoint: "test_bind_to_address" entry.
*** 1 failure is detected in the test module "thrift"
~/thrift/src/thrift-0.11.0/lib/cpp/test $ ifconfig -a
eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02
inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:65839 errors:0 dropped:0 overruns:0 frame:0
TX packets:35873 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:92097704 (87.8 MiB) TX bytes:2303356 (2.1 MiB)
ip6tnl0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1452 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
tunl0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-3C-A6-00-00-00-00-00-00-00-00
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
{code}
> Unable to Build Test Suite in Alpine Linux
> --
>
> Key: THRIFT-4594
> URL: https://issues.apache.org/jira/browse/THRIFT-4594
> Project: Thrift
> Issue Type: Bug
> Components: Test Suite
>Affects Versions: 0.11.0
> Environment: Ubuntu Bionic (native)
> alpine:latest (docker)
>Reporter: Christopher Friedt
>Priority: Minor
> Fix For: 0.12.0
>
> Attachments: make-check-alpine-3.8.txt,
> make-check-macos-10.13.5.text, thrift-alpine-20180701.tar.gz
>
>
> It seems that the 0.11.0 lib/cpp/test suite is not building correctly when
> run inside of Alpine Linux 3.8 in a Docker container.
> I've narrowed the culprits down to the non-portable (NP) class of Mutex
> initializers. The failure occurs in unpatched code (and obviously in my CI
> build recipe, attached).
> Currently, I'm working on automating builds of thrift for Alpine Linux 3.8,
> and they will likely require "make check" to pass successfully in future
> versions. Might as well ensure it works now.
> If you want to duplicate my build easily in Docker, you can use the
> attachment (e.g. tar xpvzf thrift-ci-build-20180627.tar.xz; cd
> thrift-20180627; docker build -t foo .)
> {noformat}
> make check
> ...
> /bin/bash ../../../libtool --tag=CXX --mode=link
> x86_64-alpine-linux-musl-g++ -Wall -Wextra -pedantic -Os -fomit-frame-pointer
> -L/usr/lib -Wl,--no-undefined -o TPipedTransportTest TPipedTransportTest.o
> TPipeInterruptTest.o libtestgencpp.la ../../../lib/cpp/libthrift.la
> /usr/lib/libboost_unit_test_framework.a /usr/lib/libboost_system.a
> /usr/lib/libboost_thread-mt.a -lrt -lpthread
> concurrency/MutexTest.o: In function `MutexTest::happy_path::test_method()':
> MutexTest.cpp:(.text+0x18): undefined reference to
> `apache::thrift::concurrency::Mutex::ERRORCHECK_INITIALIZER(void*)'
> concurrency/MutexTest.o: In function
> `MutexTest::recursive_happy_path::test_method()':
> MutexTest.cpp:(.text+0x580): undefined reference to
> `apache::thrift::concurrency::Mutex::RECURSIVE_INITIALIZER(void*)'
>
[jira] [Commented] (THRIFT-3950) Memory leak while calling oneway method
[ https://issues.apache.org/jira/browse/THRIFT-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16535848#comment-16535848 ] ASF GitHub Bot commented on THRIFT-3950: bforbis edited a comment on issue #1568: THRIFT-3950: Memory leak while calling oneway methods URL: https://github.com/apache/thrift/pull/1568#issuecomment-402201087 This code only affects the clientside, not the server side. This is not about sending a serverside oneway response, it's about executing the supplied clientside callback after the client requested oneway has been sent to the server. The clientside callback will resolve immediately with `null` once the message has been flushed to the server to notify the application that it successfully sent the oneway. Otherwise, this allows for two bad behaviors which this PR fixes: 1. Supplied callbacks to oneways on the client will build up in the _reqs registry and never get executed since oneways will never receive responses. 2. All client calls return promises that can be waited on with `await` or put in a promise chain with `.then()`. Except oneways will never resolve, since their callback just gets put into a registry and never executed, causing an application that waits on a oneway to hang forever. If the client call returns a promise, that promise should have the option to be resolved (in this case, immediately) to prevent this from happening. Otherwise, it should not return a `then`able at all. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Memory leak while calling oneway method > --- > > Key: THRIFT-3950 > URL: https://issues.apache.org/jira/browse/THRIFT-3950 > Project: Thrift > Issue Type: Bug > Components: Node.js - Compiler >Affects Versions: 0.9.3 >Reporter: Sangmin Yoon >Priority: Major > > When you call oneway methods in Node.js, Service._reqs object is bloated. > There is no chance to 'delete this._reqs[rseqid];' because no return from > server. > Also Connection.seqId2Service is bloated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Transport Hints - Message identity and routing
Hi, > Thrift transport (at least in C++) does not have a concept of a > transport hint that could carry through the processor for each request. Correct. Because nobody needs it for pure and simple RPC & serialization which is the scope where Thrift operates. There is no need to carry a correlation ID around unless you need it. We than make it part of the messages we send back and fort. I would love to use THeader for stuff like that, but it's only available for C++ right now. > I am working on Message Bus support for Apache Thrift. Currently I am in > the middle of developing RabbitMQ support and then I will be looking into > Kafka. Specifically, with Rabbit and 0MQ and ActiveMQ I dealt with a while ago, I aloy played with some other systems like MSMQ and Rebus (a NService Bus clone). But before we got down to the matter, could you share an idea about the generalities of the implementation idea? Have fun, JensG -Ursprüngliche Nachricht- From: James E. King III Sent: Friday, July 6, 2018 3:54 PM To: dev@thrift.apache.org Subject: Transport Hints - Message identity and routing I am working on Message Bus support for Apache Thrift. Currently I am in the middle of developing RabbitMQ support and then I will be looking into Kafka. I found that in order to receive requests and route replies properly, I need a way to identify where the request came from when sending the reply. Thrift transport (at least in C++) does not have a concept of a transport hint that could carry through the processor for each request. These hints would be entirely opaque and only useful or understandable to the layer that inserted them. They also would not likely be useful to stream based transports, but I believe they are necessary for message-based transports to work properly. There's a bit of an impedance mismatch there, however any use of a message bus really requires framed transport which separates messages anyway. This is something I will be looking into soon, so if anyone has any thoughts about it please let me know. - Jim
