Could not initialize Hazelcast with a dependency on a JPA repository

[JorgenRingen]

Issue after upgrading from version 2.0.4 to 2.0.5+.

Startup fails with:
Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'cacheManager': Requested bean is currently in creation: Is there an unresolvable circular reference?

I'm instantiating a HazelcastInstance bean manually and instantiation relies upon a org.springframework.data.jpa.repository.JpaRepository bean. This causes a circular reference on the cacheManager bean during initialisation.

@Bean public FooMapStore fooMapStore(FooRepository fooRepository) {}
@Bean public Config config(FooMapStore fooMapStore) {}
@Bean public HazelcastInstance hazelcastInstance(Config config) { }

I've debugged the dependency graph and it looks like this:
entityManagerFactory -> cacheManager -> JCacheCacheConfiguration -> hazelcastPropertiesCustomizer -> hazelcastInstance -> config -> fooMapStore -> fooRepository -> (inner bean)#hash -> entityManagerFactory -> cacheManager

Sample application: https://github.com/JorgenRingen/spring-boot-error-cachemanager-currently-in-creation

Any suggestions for workarounds?

[snicoll]

@JorgenRingen the contract with Spring Boot always has been that the cache infrastructure is available before the JPA entity manager kicks in. The main reasoning behind that is that if you don't do this and you use second level cache, Hibernate will attempt to initialize a cache manager and create a duplicate.

Several things:

• The condition that makes sure this happens was faulty and got fixed in 2.0.5, that's why you get a cycle all of a sudden that should always have been there (Hibernate 2nd level cache starts before the regular cache auto-configuration #14181)
• The second level cache infrastructure has changed quite a lot in recent Hibernate versions and there is an issue (Add support for configuring Hibernate L2 Cache #14586) to offer out-of-the-box support for this that may potentially relax the current arrangement

I don't see how we could support both use case and having the cache infrastructure initialized by the time hibernate starts (if you're using that) makes sense to me. Can't you defer the registration of the MapStore rather than doing it from the get go?

[JorgenRingen]

Okey, I see we should've avoided the cycle in the first place.

Are there any preferable way of deferring the registration? As a first draft I'm doing a "lazy-lookup" from the ApplicationContext on the first call on FooRepository from FooMapStore, but it feels a bit awkward :-)

public class FooMapStore implements MapStore<Long, Foo> {

    @Autowired 
    private ApplicationContext applicationContext;
    private FooRepository fooRepository;

    @Override 
    public void store(Long key, Foo value) {
        fooRepository().findAll();
    }

    ...

    private FooRepository fooRepository() {
        if (this.fooRepository == null) {
            this.fooRepository = applicationContext.getBean(FooRepository.class);
        }
        return fooRepository;
    }

[snicoll]

Thanks for the feedback. That's not really what I have in mind. I was more thinking about retrieving the HazelcastInstance later and alter its configuration to register an extra store. Is that a use case that Hazelcast supports?

[JorgenRingen]

I thought about registering the MapStore in a BeanPostProcessor, but according to com.hazelcast.config.Config [Config instances] should not be modified after they are used to create HazelcastInstance.

The creation of the HazelcastInstance bean instantiates it (return Hazelcast.getOrCreateHazelcastInstance(config);) so a BeanPostProcessor is too late. I could also add FooRepository to FooMapStore in a BeanPostProcessor but I think that just adds another layer of confusion compared to looking it up from the ApplicationContext.

[snicoll]

@JorgenRingen that's not what this issue indicates. I've tried and got another Hazelcast problem that I don't really understand:

Caused by: com.hazelcast.nio.serialization.HazelcastSerializationException: There is no suitable serializer for class com.example.cachemanagercurrentlyincreationerror.FooMapStore
	at com.hazelcast.internal.serialization.impl.AbstractSerializationService.serializerFor(AbstractSerializationService.java:491) ~[hazelcast-3.9.4.jar:3.9.4]
	at com.hazelcast.internal.serialization.impl.AbstractSerializationService.writeObject(AbstractSerializationService.java:254) ~[hazelcast-3.9.4.jar:3.9.4]
	... 44 common frames omitted

I've submitted a PR to your repro project.

[JorgenRingen]

Interesting. This error only occurs when the mapstore is added in the postconstruct. As far as I understand hazelcast does some kind of broadcasting of the config if the config is updated after initialisation and thats what causing the serialization issue. From stacktrace:

Caused by: com.hazelcast.nio.serialization.HazelcastSerializationException: Failed to serialize 'com.hazelcast.config.MapConfig'
	at com.hazelcast.internal.serialization.impl.SerializationUtil.handleSerializeException(SerializationUtil.java:75) ~[hazelcast-3.9.4.jar:3.9.4]
	at com.hazelcast.internal.serialization.impl.AbstractSerializationService.toBytes(AbstractSerializationService.java:161) ~[hazelcast-3.9.4.jar:3.9.4]
	at com.hazelcast.internal.serialization.impl.AbstractSerializationService.toBytes(AbstractSerializationService.java:137) ~[hazelcast-3.9.4.jar:3.9.4]
	at com.hazelcast.internal.serialization.impl.AbstractSerializationService.toData(AbstractSerializationService.java:122) ~[hazelcast-3.9.4.jar:3.9.4]
	at com.hazelcast.internal.serialization.impl.AbstractSerializationService.toData(AbstractSerializationService.java:110) ~[hazelcast-3.9.4.jar:3.9.4]
	at com.hazelcast.internal.dynamicconfig.ClusterWideConfigurationService.cloneConfig(ClusterWideConfigurationService.java:227) ~[hazelcast-3.9.4.jar:3.9.4]
	at com.hazelcast.internal.dynamicconfig.ClusterWideConfigurationService.broadcastConfigAsync(ClusterWideConfigurationService.java:219) ~[hazelcast-3.9.4.jar:3.9.4]
	at com.hazelcast.internal.dynamicconfig.ClusterWideConfigurationService.broadcastConfig(ClusterWideConfigurationService.java:199) ~[hazelcast-3.9.4.jar:3.9.4]

Notice "broadcastConfigurationAsync".

I'll try to experiment with the deferred registration in the application where the problem originally occurred a bit later. My example-app is over-simplified with regards to hazelcast in order to show the circular reference problem. Might have to do some additional configuration somewhere in order to do updates of the hazelcast-config after hazelcast initialization.

[nkavian]

I have a similar issue. I want to initialize the Hazelcast Config with one setting from my database, which then I'm hit with the cyclical issue.

[StefanPopa02]

Any updates on this? I'm facing a similar issue