It looks like CACHE-95 has been fixed ??

[Matt Rice]

I saw this in the atlassian-jira.log on startup. What is it referring to?

[c.atlassian.jira.NoopCacheEventListenerFactory] It looks like CACHE-95 has been fixed. This workaround should be removed.

[Andy Heinzer]

CACHE-95 appears to be a bug ticket.  I'm not sure where the link to that ticket is or what tracker it might be on.   However I found this warning message in the Jira Server Source code.  If you have a commerical or academic license you too can find this in the library  jira/jira-components/jira-core/src/main/java/com/atlassian/jira/NoopCacheEventListenerFactory.java

There is also some docs on why this is here from  https://docs.atlassian.com/software/jira/docs/api/7.2.2/com/atlassian/jira/NoopCacheEventListenerFactory.html

public final class NoopCacheEventListenerFactory
extends net.sf.ehcache.event.CacheEventListenerFactory

Work-around for CACHE-95 / EHC-1089.

Due to this bug, the first cache that registers a listener configuration pollutes the default configuration with that listener. As a result, every cache thereafter gets that listener factory, too. To prevent this, we explicitly give the default configuration a listener factory that will deliver a single no-op listener on every cache. This ensures that the default configuration has at least one listener, which in turn makes the listener configuration clone itself properly. The extra listener call on every cache notification is unlikely to be at all significant.

This is only public because EhCache wants to instantiate a new one every time it creates a cache. Awesome.

Since:

v6.4