@Timeout behavior without @Asynchronous
See original GitHub issueI wasn’t able to find any info in the spec that would say that a method annotated with @Timeout
should block until the execution is finished if the execution is non interruptible, yet the last assertion in TimeoutUninterruptableTest#testTimeout
checks that.
Does it mean that @Timeout
without @Asynchronous
has to be executed on the callers thread?
Issue Analytics
- State:
- Created 5 years ago
- Comments:9 (9 by maintainers)
Top Results From Across the Web
Timeout for an async loop: if loop do not finishes before ...
Hi Team,. I propose a new syntax : await[timeoutInMs] to control timeout of a promise. I have summarized this whole thread here in...
Read more >Task.Delay(0) not asynchronous - Stack Overflow
The reason Task.Delay(0) does not run asynchronously is because the async-await state machine explicitly checks whether the task is ...
Read more >No way to stop async job on timeout #2105 - Miserlou/Zappa
Create an async job that takes longer than 900 seconds. Run your async job, let it time out, and it will retry regardless...
Read more >Running an async task with a timeout - Swift Forums
I wrote a function async(timeoutAfter:work:) . Its goal is to run an async task with a timeout. If the timeout expires and the...
Read more >On awaiting a task with a timeout in C# - The Old New Thing
Say you have an awaitable object, and you want to await it, but with a timeout. How would you build that? What you...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
We discussed this issue on the call yesterday. I still believe that what we want for the user is to have the caller’s CDI context available in the execution and it should not matter if the execution happens on the same thread or not. It was pointed out that having it on the same thread is a simpler concept to grasp for the user and its easier to implement. The conclusion was to leave the spec and the test as it is and to revisit it when the spec will be modified to fit the reactive model. @Emily-Jiang please correct me if I missed something.
Isn’t that limiting though, forcing implementations as to how to manage threads?