-
Notifications
You must be signed in to change notification settings - Fork 24
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
Add Async Bean Generation #736
Conversation
b596a10
to
796c390
Compare
what should be the annotation's name?
|
…ponent Once we have a component that depends on a Async component that all needs to resolve when creating the BeanScope.
I'm wondering how practical this is in real life? Once we have a component that depends on an async component the BeanScope needs to wait for the CompletableFuture to finish etc. That is, as soon as the "slow" components you might want this on have components that depend on them it quickly hits that wait. Seems to me the use case is something that is "slow" that also doesn't have many components that depend on it? What would real life examples of this be? Lazy seems like the better option for the "relatively expensive" components (like Desktop UI components) for on demand lazy creation use case. |
well the one situation it might be useful is when the async component is also retrieved lazily. suppose I had a bean like this: @AsyncBean
@Component
public class MyUseOfBackground {
private final BackgroundBean backgroundBean;
public MyUseOfBackground(@Named("single") BackgroundBean backgroundBean) {
this.backgroundBean = backgroundBean;
}
} then used it like this: @Component
public class UseBackground {
private final Provider<MyUseOfBackground> backgroundBeanProv;
public UseBackground(Provider<MyUseOfBackground> backgroundBeanProv) {
this.backgroundBeanProv = backgroundBeanProv;
}
} in a case like this, the |
hmm, perhaps it should be an option of the |
Do we require synchronization?
No, I'm pretty sure I got that wrong (and we need to undo my changes
there). The wiring all happens single threaded in the foreground.
Lazy
Id say thats "on demand". Is there benefit in "on demand + via another
thread"? ... cause the thread that invoked the lazy is just waiting? Hmm.
…On Wed, 20 Nov 2024, 3:20 am Josiah Noel, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In inject/src/main/java/io/avaje/inject/spi/DBeanMap.java
<#736 (comment)>:
> + private final Map<String, DContextEntry> beans = new ConcurrentHashMap<>();
+ private final Set<String> qualifiers = Collections.synchronizedSet(new HashSet<>());
Do we require synchronization? The async beans don't have an opportunity
to write to these collections. They are registered as jakarta providers.
—
Reply to this email directly, view it on GitHub
<#736 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTATNWS7PKH6AZFT4H7FT2BNCK5AVCNFSM6AAAAABR5RORXGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDINBVGYZDANZYGY>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
use case
The case I can think of is where an app has multiple db connection pools,
and there is a desire for these to initialize in parallel in the
background.
So the effective benefit is that initialisation is done in parallel (vs
currently serial).
... but to me this is not a case for Lazy per se [because I want it to fail
eagerly if any of those pools fail to initialise].
I should check the spring issue related to this.
…On Wed, 20 Nov 2024, 7:17 am Rob Bygrave, ***@***.***> wrote:
> Do we require synchronization?
No, I'm pretty sure I got that wrong (and we need to undo my changes
there). The wiring all happens single threaded in the foreground.
> Lazy
Id say thats "on demand". Is there benefit in "on demand + via another
thread"? ... cause the thread that invoked the lazy is just waiting? Hmm.
On Wed, 20 Nov 2024, 3:20 am Josiah Noel, ***@***.***>
wrote:
> ***@***.**** commented on this pull request.
> ------------------------------
>
> In inject/src/main/java/io/avaje/inject/spi/DBeanMap.java
> <#736 (comment)>:
>
> > + private final Map<String, DContextEntry> beans = new ConcurrentHashMap<>();
> + private final Set<String> qualifiers = Collections.synchronizedSet(new HashSet<>());
>
> Do we require synchronization? The async beans don't have an opportunity
> to write to these collections. They are registered as jakarta providers.
>
> —
> Reply to this email directly, view it on GitHub
> <#736 (review)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABTATNWS7PKH6AZFT4H7FT2BNCK5AVCNFSM6AAAAABR5RORXGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDINBVGYZDANZYGY>
> .
> You are receiving this because your review was requested.Message ID:
> ***@***.***>
>
|
Apparently, it's one of the most voted issues ever: spring-projects/spring-framework#13410 |
We have to be a little bit careful though because:
avaje-inject avoids scanning altogether PLUS has already ordered the dependency wiring so yes we are a lot faster than Spring DI due to that. For myself, I also use libraries that also can avoid classpath scanning (Ebean ORM, ebean-migrations ... so no scanning and no dynamic proxies). In the past I have been here though in terms of a Spring app starting up in around 30+ seconds. In a large modular application (not microservices, more "modular monolith") people can "feel" the startup time with Spring but again I'm saying we don't actually have this at all with avaje-inject because we don't have any scanning or any dynamic proxies. So I'd say that slow startup time in an avaje-inject app is going to come from specific network activities (like obtaining remote configuration secrets/properties, initialising datasources, running database migrations, initialising queuing clients, populating caches on startup).
That's just nuts and also provides zero detail as to what is actually slow.
That's due to Hibernate's use of classpath scanning and dynamic proxies. I don't have a lot of sympathy for people who do this to be honest. |
Seems like a solution in search of a problem. Closing unless somebody actually needs it. |
First crack at #735
given a class
the following will generate