Skip to content

[rsocket-cpp] Enable tck tests in travis builds - #510

Merged
alexmalyshev merged 6 commits into
rsocket:masterfrom
somasun:tck
Jun 14, 2017
Merged

[rsocket-cpp] Enable tck tests in travis builds#510
alexmalyshev merged 6 commits into
rsocket:masterfrom
somasun:tck

Conversation

@somasun

Copy link
Copy Markdown
  • Enable tck tests to run in travis builds
  • Make the server terminate with signal (instead of stdin - which doesnt work well with background jobs)
  • Reuse the same requester for all requests

@lehecka

Copy link
Copy Markdown
Contributor

looks like there are 2 test issues in travis.
I believe there is a race condition in Request*Test.Hello
The second issue is some memory leak in TCK tests.

@somasunsomasun closed this Jun 13, 2017
@somasunsomasun reopened this Jun 13, 2017
Comment threadtck-test/client.cpp
folly::SocketAddress address;
address.setFromHostPort(FLAGS_ip, FLAGS_port);

LOG(INFO) << "Creating client to connect to " << address.describe();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

operator<<(std::ostream&, const folly::SocketAddress&) already exists I think, no need for .describe().

const Test& test,
std::unique_ptr<RSocketRequester> requester)
: requester_(std::move(requester)), test_(test) {
RSocketRequester* requester)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably have this as RSocketRequester&, but this is fine too.

Comment threadtck-test/server.cpp
static void signal_handler(int signal) {
LOG(INFO) << "Terminating program after receiving signal " << signal;
exit(signal);
terminate.set_value();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the chances this is safe to do in a signal handler... Regardless, I don't have a better solution as SignalBarrier isn't open source and it's very likely Linux-only code.

Any particular reason for std::future instead of folly::Future?

@alexmalyshev
alexmalyshev merged commit 5f0db95 into rsocket:masterJun 14, 2017
@somasun
somasun deleted the tck branch June 16, 2017 23:26
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@somasun@lehecka@alexmalyshev