Juergen Hoeller

The `executeOngoingLoop` code path is primarily there for the internal `SimpleAsyncTaskExecutor` which starts a new `Thread` for every (re-)scheduling attempt, reusing every `Thread` for as long as possible. Instead of...

On review along with #32252, there is actually an argument for scaling down in the default setup in particular with virtual threads. Since thread creation is cheap there, this would...

I've revised `idleReceivesPerTaskLimit` to apply to surplus consumers on a default/simple executor. Core consumers up until `concurrentConsumers` remain scheduled for any number of receives (since they would get rescheduled immediately...

See https://github.com/spring-projects/spring-framework/issues/13410#issuecomment-1967596598 for a variant of this to be introduced in 6.2, at the granularity of the entire bean creation phase for a particular bean. The new background initialization flag...

@snicoll is this possibly a regression caused by #22725?

Since the use of `Ordered` in an aspect can generally have unpleasant initialization side effects, we throw a descriptive `AopConfigException` hinting at the `Ordered` vs. `@Order` problem now if advisor...

We intend to revisit core container performance concerns in 6.2 (see e.g. #28122), so let's see what we can do about AOP Advisor matching. In general, we are very controlled...

One further note on parallel processing there is the order of the outcome. In general, we treat advisors as per their registration order. With parallel streams, we cannot guarantee that...

Assuming that your advisors are mostly of type `AspectJExpressionPointcut`, could you provide a few examples for the pointcut expressions that you are declaring there? AspectJ matching performance rather strongly depends...

For wildcard type matches, there is https://bugs.eclipse.org/bugs/show_bug.cgi?id=532033 from six years ago which unfortunately never got released, apparently due to breaking Spring Framework tests - which I cannot reproduce (anymore), our...