Skip to content
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

Regression: Early instantiation of a bean prevents proxying for @Async in 4.2.x but works in 4.1.x [SPR-14030] #18602

Closed
spring-issuemaster opened this issue Mar 9, 2016 · 6 comments
Assignees
Milestone

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Mar 9, 2016

Andy Wilkinson opened SPR-14030 and commented

There's a behaviour difference between 4.2.x and 4.1.x around proxy creation for beans with @Async methods. When using 4.2.x, early instantiation of the bean makes it ineligible for proxying. It works fine with 4.1.x.

I'll submit a spring-framework-issues PR with a test that illustrates the problem once I've got the issue number.


Affects: 4.2.5

Reference URL: spring-projects/spring-boot#5366

Issue Links:

  • #18293 Regression: AsyncAnnotationBeanPostProcessor fails on startup when encountering ambiguous TaskExecutor beans
  • #17839 AsyncAnnotationBeanPostProcessor could find TaskExecutor by type/name
  • #19059 Nested @Async annotations can block indefinitely
  • #20125 Consistently accept "taskExecutor" bean of type Executor (as stated in @EnableAsync's javadoc)
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 9, 2016

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 10, 2016

Stéphane Nicoll commented

That is a side effect of the change in #17839

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 11, 2016

Juergen Hoeller commented

I've addressed this through moving that lookup logic into AsyncExecutionAspectSupport, performed on demand when we actually execute a given @Async method. We already had resolution logic for qualifier-based executors there, so now we simply have our resolution logic for the default executor there as well.

As a consequence, the intermediate AsyncAnnotationAdvisor class doesn't initialize a local default SimpleAsyncTaskExecutor anymore. This is now also left to AsyncExecutionAspectSupport since it would otherwise prevent the logic there from kicking in.

As a side effect of the above, our AspectJ async aspect will receive a default executor now if it has been configured with a BeanFactory. Previously, it skipped execution completely if no explicit executor was given - even if it had a BeanFactory. However, the mismatch with its own qualifier-based resolution and with proxy-based setup was questionable before, so we consistently apply default resolution in case of a given BeanFactory in any scenario now. The only way to make the AspectJ async aspect skip async execution completely is to not populate the aspect at all, in particular neither with an Executor nor with a BeanFactory.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 19, 2016

Sam Brannen commented

Reopening this issue since it has caused tests in EnableSchedulingTests to fail.

See failing performance builds starting with https://build.spring.io/browse/SPR-PERF-724.

Note that the following tests have been temporarily disabled via @Ignore until this is resolved.

  • withExplicitSchedulerAmbiguity_andSchedulingEnabled()
  • withAmbiguousTaskSchedulers_andSingleTask()
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 25, 2016

Juergen Hoeller commented

Andy Wilkinson, this is also available in 4.2.6.BUILD-SNAPSHOT as of last night... Let me know whether it restores lazy initialization behavior along the lines of 4.1.x for you.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 29, 2016

Andy Wilkinson commented

Looks good – the project supplied with the original Boot issue is proxied correctly with the latest 4.2.6 snapshot and the async method runs on a separate thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.