Hi Val, SmartInitializingSingleton#afterSingletonsInstantiated is invoked right at the end of the singleton pre-instantiation phase, *with a guarantee that all regular singleton beans have been created already*. This behavior allows avoiding the deadlock case described in the first message. InitializingBean#afterPropertiesSet method is called when a lock on the Spring's internal collection of singleton beans is being held (due to a singleton bean instantiation) and not all singleton beans have been initialized.
With SmartInitializingSingleton approach it won't be possible to call Ignite instance methods inside any kind of init methods of other beans. For example, it won't be possible to call any operation on the Ignite instance inside @PostConstruct annotated methods because the Ignite instance won't be started by that time. Kind regards, Alex. On Wed, Oct 18, 2017 at 8:50 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Hi Alex, > > This indeed has to be fixed, I've seen this issue multiple times. > > Can you please clarify the difference between SmartInitializingSingleton > and InitializingBean? And what exactly will not work if we switch? Can you > give an example? > > -Val > > On Wed, Oct 18, 2017 at 8:56 AM, Alexander Fedotov < > alexander.fedot...@gmail.com> wrote: > > > Hi Igniters, > > > > There is an issue that IgniteSpringBean deadlocks when there is > CacheStore, > > Service, you name it with @SpringResource annotated fields > > https://issues.apache.org/jira/browse/IGNITE-6555. The issue appeared > > after > > moving the logic for starting statically configured caches to operate in > > the same way as for dynamic ones: from GridDhtPartitionsExchangeFuture. > > Deadlock occurs because IgniteSpringBean having acquired internal Spring > > lock waits for a GridDhtPartitionsExchangeFuture which is executed in a > > separate thread and which in turn tries to inject @SpringResource > annotated > > fields using the passed Spring application context what leads to an > attempt > > to acquire the same internal Spring lock that is already being held by > the > > main thread. > > > > A possible solution is to remove IgniteSpringBean#afterPropertiesSet, > make > > IgniteSpringBean implement SmartInitializingSingleton and start Ignite > > instance inside afterSingletonsInstantiated. > > The only possible problem here is that an Ignite bean cannot be > > referenced from init-like methods: afterPropertiesSet, @PostConstruct > etc. > > > > Any thoughts? Suggestions? > > > > Kind regards, > > Alex. > > >
