0

We have refactored some parts of our application, and after that, methods annotated with spring cachable stopped being cached although the class containing the cached method was not touched.

After some debugging, we can see that after refactoring and adding some new Spring beans, the bean with the cachable method is now created in the same batch as the internalCacheAdvisor itself. The Advice can thus not be applied and the Spring cache aspect is never invoked. So the method result is not cached, @Cachable annotation does not work.

What mechanism is deciding what beans that can be created simultaneously, and how can I debug and affect this mechanism?

I have looked in the Spring method BeanFactoryAdvisorRetrievalHelper::findAdvisorBeans, and when running the old and worikng code, it looks like this: cachable bean created with success

After refactoring it looks like this: enter image description here

Our annotated class couchbaseTranslationProvider is created at the same batch as internalCacheAdvisor, which is not possible. When trying to apply the advice proxy, I get a debug message "Skipping currently created advisor ...". (I think this should have been an error message!)

Our POM-file enabling the cache looks like this:

@Configuration
@EnableWebMvc
@ComponentScan({"[package]", "[package].connectors"})
@Import({EventsConfig.class,
        CmsConfig.class})
@EnableCaching
public class ApiConfig {

    public static class Caches{
        public static final String SPORTS = "sports";
        [...]
        public static final String PIPEDTRANSLATIONS = "translations";
    }

    @Value("${[package].document}")
    private String someUrl;

    @Bean
    public CouchbaseClient getCouchbaseClient() throws IOException {
        [code]
    }

    @Bean
    public CacheManager cacheManager() {
        SimpleCacheManager cacheManager = new SimpleCacheManager();
        cacheManager.setCaches(Arrays.asList(new ConcurrentMapCache(Caches.SPORTS),
                [...],
                new ConcurrentMapCache(Caches.PIPEDTRANSLATIONS)));
        return cacheManager;
    }

    @Autowired
    private EventUpdateGate eventUpdateGate;

    @Bean
    @ConditionalOnProperty("AdapterGate.events.active")
    public AdapterGateReceiver eventAdapterGateReceiver(@Value("${AdapterGate.events.gateChannel}") String channel,
                                                @Value("${AdapterGate.events.apiVersion}") String version) {
        return new AdapterGateReceiver(channel, version, eventUpdateGate);
    }
}
Andreas Lundgren
  • 12,043
  • 3
  • 22
  • 44
  • are you injecting `couchbaseTranslationProvider` in your configuration class by any chance? Any weird configuration arrangement on that class? Does it work on another class? – Stephane Nicoll Oct 13 '14 at 14:17
  • Yes, actually I am... I didn't see this before. After the refactoring, the EventUpdateGate was introduced. This bean injects another bean, that injects another bean that injects the couchbaseTranslationProvider . I have now tested to move the EventUpdateGate (and AdapterGateReceiver) to its own config file, and the problem is now solved, thanks! – Andreas Lundgren Oct 14 '14 at 09:17
  • Cool, glad it helped. Ironically, we got a similar report to yours that lead to https://jira.spring.io/browse/SPR-12336 – Stephane Nicoll Oct 15 '14 at 14:21
  • I think that it may be justified to either print an error in the log or to even throw a "Circular Reference" exception here. Without debug level on logs, the only indication you get of your miss-configuration is that (some) cache-annotated methods no longer are cached and that your application runs slightly slower. Of cause this maybe have side effects that I'm not aware of, and an exception would not be backward compatible, but maybe conciser to add an error log. – Andreas Lundgren Oct 17 '14 at 06:52
  • There is a already a log at INFO level that tells you the bean that isn't eligible for proxying but I see what you mean. 4.1.2 should fix the issue but you should always be careful when injecting components in configuration classes. – Stephane Nicoll Oct 19 '14 at 11:56

0 Answers0