Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Use the correct default executor to fire async CDI events
See original GitHub issueWe’re currently using ForkJoinPool.commonPool().
@stuartwdouglas @dmlloyd @manovotn WDYT?
Issue Analytics
- State:
- Created 4 years ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
CDI 2.0: How to check how many asynchronous events fired ...
For your first question - the default is going to be based on available processors. Something along the lines of Runtime.getRuntime().
Read more >Asynchronous CDI Events - Java Code Geeks
They give you a chance to define if you want to use synchronous (default, EventBus) or asynchronous event dispatchers (AsyncEventBus.).
Read more >[CDI-499] Firing events asynchronously - Red Hat Issue Tracker
We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the CompletionStage interface.
Read more >Using Events in CDI Applications - Java EE
Events allow beans to communicate without any compile-time dependency. One bean can define an event, another bean can fire the event, and yet...
Read more >[cdi-dev] On @Observes for async events
(Not the thread that fires the event, another > thread, ... option is to combine those two and by default call the observers...
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 Free
Top 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
No I was responding to the title of the proposal, which is to use a better default executor, which seems reasonable.
I have mixed feelings about the
ForkJoinPool. On the one hand, it’s largely invisible and just does its work in the background without interfering much (at run time at least). On the other hand it creates yet more threads that the user has limited control over, and there’s also really no way to defeat it. 🤷♂️I guess we should only use (or allow usage of) the
ForkJoinPoolfor things that are actually fork-join or parallel stream based (i.e. user code which uses fork-join or parallel streams). Our stuff should usually stick to our thread pools.@dmlloyd But using
ForkJoinPool.commonPool()during STATIC_INIT should be ok, or? TBH I don’t think that async CDI events are frequently used and especially not in the integration code (which is mostly the CDI stuff run in STATIC_INIT). In other words, if usingForkJoinPool.commonPool()during STATIC_INIT is OK I wouldn’t spend more time on this.