Make ConditionAwaiter#executor configurable about awaitility HOT 12 CLOSED

Fair enough. What if instead of making ExecutorService configurable Awaitility just provides an option to run everything in the same thread? That would be just a boolean flag in the API.

from awaitility.

Ok so I've now implemented support for this, for example:

given().pollInSameThread().await().atMost(1000, MILLISECONDS).until(() -> fakeRepository.getValue() == 1);

You can also specify a thread factory:

with().pollThread(Thread::new).await().atMost(1000, MILLISECONDS).until(() -> fakeRepository.getValue() == 1);

or an ExecutorService:

given().pollExecutorService(executorService).await().atMost(1000, MILLISECONDS).until(() -> threadLocalRepo.getValue() == 1);

There are static configuration options as well such as:

Awaitility.pollInSameThread();

Please try it out and let me know what you think by depending on 3.0.0-rc2:

<dependency>
    <groupId>org.awaitility</groupId>
    <artifactId>awaitility</artifactId>
    <version>3.0.0-rc2</version>
</dependency>

from awaitility.

@btrummer Thanks for your feedback

from awaitility.

Hmm I see your point but I'm not totally convinced. It could lead to more support issues that are due to the use of a custom ExecutorService. For example what if you supplied an instance of ScheduledThreadPoolExecutor? That could potentially mess up the way Awaitility behaves. It's also a very slim use case so I'm doubtful whether this is worth the extra complexity and expand the API.

from awaitility.

I have a similar situation in my current project now. In the past we used awaitility together with rest-assured (embedded in lambdas) which works perfectly fine. In the current project we use serenity-rest-assured now, which in fact is "plain" rest-assured plus some extra magic so the requests/responses make it into the serenity test reports. This magic however is ThreadLocal based and therefore each request we make starts breaking with a NullPointerException as soon as it is embedded within an await().until(...).

My current workaround is to have a custom "single-threaded" implementation of the awaitility DSL, with an API stripped down to the bare minimum of what we really need (only .until(lambda), and a fixed atMost() and pollInterval()).

Long story short: I don't see the necessity to hook in custom ExecutorServices. In my case, I just would like to have the possibility to switch awaitility into an "in-same-thread" polling mode, either globally or just for single await().until(...) clauses by adding a ".and().pollInSameThread()" just before the .until(), or something like that...

Thanks.

from awaitility.

I'm thinking about removing the polling thread altogether and just make Awaitility use the same thread as the test. Would this solve your issues? I'm not 100% sure that this would work, but with my current understanding I can't see why not so I hope that I can at least give it a try.

from awaitility.

It might not solve all problems, there may be situations (with thread-local et al) that the state is not visible to awaitility unless you give it another thread. So maybe the thread (and maybe event a classloader in the long run?) could be made configurable but default to the same thread as the test?

from awaitility.

Would be great for me.

IMHO the only reason to do this is to be able to enforce the "atMost" timeout in case the called condition/lambda gets stuck or hung up in an endless loop.
However, at least the use cases I have wouldn't require awaitility to do this for me. If I would have brittle conditions I'd rather fix those ;-) and/or I'd add a forced test timeout to the maven surefire/failsafe plugin config to prevent a test run from getting stuck.

from awaitility.

Ok now I remember why Awaitility uses a thread to execute the condition "poll". This is because the the condition supplied to Awaitility can exceed the "at most" time limit and Awaitility detects this and terminates the poll thread. Otherwise there's a chance that a condition might block forever.

from awaitility.

Hmm but maybe it's possible to work around this. I need some time :)

from awaitility.

I'm going to close this issue, please tell me whether I should reopen or not.

from awaitility.

Sorry for the late response.
I tried 3.0.0-rc3 and can confirm that pollInSameThread() works fine.

Fun fact: there was a recent fix in serenity, which actually fixes the NPE I mentioned above. So whether or not I use pollInSameThread(), the NPE is gone now.
However, please leave pollInSameThread() in the awaitility code, because I think it's a useful feature anyway. :-)

from awaitility.