Timeout stops threads if they are uninterruptible.

[aslakhellesoy]

If a thread does not respond to interrupt() we'll
try to stop() it after twice the specified timeout.

This uses the deprecated Thread.stop() method, but
for a testing tool like Cucumber that should be ok.

Ref #343.

[aslakhellesoy]

@brasmusson @os97673 let me know what you think about this approach to deal with the situation described in #343.

Acceptable?

[paul8620]

True the junit and testng solution works, but if I have a scenario in witch I know how much time a request should work then... I don't want that increased to double the timeout

[paul8620]

http://pastie.org/9788117#10

[aslakhellesoy]

@paul8620 please send your fix in a pull request. The code you pasted doesn't seem to solve the problem,

[dkowis]

So the infinite loop without any sleep or anything in there is a terrible thing, that will spin so tightly it'll use up 100% of all the CPU on any system. There's some flaws in there...

[aslakhellesoy]

@dkowis yes it's a terrible thing, and cucumber should be able to time out terrible things like that. junit can. Try this:

@Test(timeout = 20)
public void yep() {
    while(true);
}

[brasmusson]

I can't say I'm that familiar with all the intricate details of the thread handling in Java. This post makes a strong case that Thread.interrupt should be the first option, and only if the running step definition does not play nicely with Thread.interrupt, Thread.stop could be tried.

It seems like not even Thread.stop will always work, however (quote from the post):
"It should be noted that in all situations where a waiting thread doesn't respond to Thread.interrupt, it wouldn't respond to Thread.stop either. Such cases include deliberate denial-of-service attacks, and I/O operations for which thread.stop and thread.interrupt do not work properly." Maybe the last resort should be to log that cucumber tried to stop the step definition but couldn't.

[aslakhellesoy]

I'm not a fan of using Thread.stop either. Does anyone have the time and energy to find out how JUnit deals with it? The snippet I posted above is definitely not interruptible with Thread.interrupt.

[brasmusson]

JUnit uses Thread.interrupt see Javadoc, that does not necessarily stop the test, but as each test is launched in a separate thread, JUnit can still mark the test as failed, and launch the next test. This gist (executed from Eclipse on Linux) demonstrates that tests continues to run after they have been interrupted due to the timeout.

[mpkorstanje]

If we want to do things the junit way then it seems to me that the timeout is done at the wrong level.

We should start a worker thread for the calls in Runner.runPickle. This would also require that we wrap the EventBus to prevent slow pickles from sending events after they've had a timeout and listen to step finished events to reset the timer.

If the Pickle refused to die the worker thread it is on can then safely be left to spin while the main thread continues with the next Pickle.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.