Race condition in handling of @Lookup annotation [SPR-14333]

[spring-projects-issues]

Piotr Findeisen opened SPR-14333 and commented

repro steps

1. Have a prototype bean with a @Lookup method.
2. Try to acquire it (for the first time) from 2 or more threads concurrently
3. Call the @Lookup on acquired instance (either directly if it's pubic, or call other method that uses the @Lookup method if that one is protected

expected

• @Lookup intercepted and served by the DI container

observed

• Sometimes, the @Lookup method is not overridden, as if there was some kind of race condition or other concurrency issue in handling of that annotation.

workaround

Use <lookup-method/> in XML configuration. That one is handled at parse time, which is definitely single threaded, and does not suffer from concurrent lazy initialization.

---

Affects: 4.2.2, 4.2.6

Referenced from: commits 9131ebb, 47c62fd

Backported to: 4.2.7

[spring-projects-issues]

Piotr Findeisen commented

test PR: spring-attic/spring-framework-issues#131

[spring-projects-issues]

Juergen Hoeller commented

It looks like our MethodOverrides set needs to be guarded against concurrent modifications since prepareMethodOverrides relies on it being stable. I'll fix this for 4.3 GA, backporting it to 4.2.7.

[spring-projects-issues]

Piotr Findeisen commented

Indeed. I once even got ConcurrentModificationException somewhere close to prepareMethodOverrides, but I couldn't reproduce it reliably.

[spring-projects-issues]

Juergen Hoeller commented

I've fixed this through on-demand use of synchronization now (i.e. just in case of actual method overrides). This will be available in the upcoming 4.3.0.BUILD-SNAPSHOT and in the next 4.2.7.BUILD-SNAPSHOT tonight.