Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop relying on timeouts in specs #196

Open
ghost opened this issue Oct 9, 2014 · 11 comments
Open

Stop relying on timeouts in specs #196

ghost opened this issue Oct 9, 2014 · 11 comments

Comments

@ghost
Copy link

ghost commented Oct 9, 2014

The specs should run in a way that doesn't rely on timeouts, in order to avoid load-dependent heisenspecs, like this one: https://travis-ci.org/seancribbs/webmachine-ruby/jobs/37496051#L1659

@Asmod4n
Copy link
Member

Asmod4n commented Oct 9, 2014

can it be done with travis that each adapter runs in its own instance?

@ghost
Copy link
Author

ghost commented Oct 9, 2014

Sure, but I don't see how that solves the problem of the specs asserting that a certain piece of code finish within a certain timeframe. When saying "load-dependent heisenspecs", I mean specs that succeed or fail based on the load stress of the machine they're running on. One straightforward workaround would be to increase the timeouts. A proper solution, on the other hand, would look at the correct thing, of which I'm not sure what it is.

@Asmod4n
Copy link
Member

Asmod4n commented Oct 9, 2014

One could use a IO.pipe and wait on it till the server is started

@mostlyobvious
Copy link
Contributor

I had simillar idea once when spawning processes to wait on something like:

  • specific text in stdout
  • socket readiness
  • ability to respond to request

Have a look at https://github.com/drugpl/bbq-spawn/blob/master/lib/bbq/spawn.rb#L54-L84

@Asmod4n
Copy link
Member

Asmod4n commented Oct 9, 2014

rd, wr = IO.pipe
Thread.new {
  puts rd.read
  rd.close
}
Thread.new {
  wr.write('initialized')
  wr.close
}

Or with a queue

queue = Queue.new
Thread.new {
  puts queue.pop
}
Thread.new {
  queue << 'initialized'
}

@Asmod4n
Copy link
Member

Asmod4n commented Oct 17, 2014

Got new errors from HTTPkit now, https://travis-ci.org/seancribbs/webmachine-ruby/builds/38243104

@Asmod4n
Copy link
Member

Asmod4n commented Oct 17, 2014

Does https://github.com/seancribbs/webmachine-ruby/blob/master/lib/webmachine/spec/adapter_lint.rb#L36 get run every time it checks something? it looks totally like it..

@Asmod4n
Copy link
Member

Asmod4n commented Oct 17, 2014

@Asmod4n
Copy link
Member

Asmod4n commented Oct 17, 2014

Had to re add Adapter#shutdown again, but i believe it works now... Will run it three more times to be sure.

@seancribbs @lgierth

@Asmod4n
Copy link
Member

Asmod4n commented Oct 17, 2014

Eventmachine gives me headaches, but it's working now.

@mostlyobvious
Copy link
Contributor

Not sure if still an issue, in RES we've been using http://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent/Exchanger.html to synchronize threaded tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants