Anyone had any luck using the new JCache APIs? Which provider implementation are you using?
The publicly available version of ehcache-jcache:1.5.0-0.5 is severely out of date. I’m running into the following issue when using EventCountSnapshotterTrigger (as well as my own custom EventStreamDecorators) that rely on registering a CacheListener. https://github.com/Terracotta-OSS/ehcache-jcache/issues/10
Also, Spring 4 depends on cache-api:1.0.0-RC1, while Axon depends on 0.5. The APIs have changed quite a lot. Aside from the above blocker, I can’t use Spring 4’s JCacheManagerFactoryBean with the older cache-api due to NoSuchMethodErrors. Conversely, using cache-api:1.0.0-RC1 satisfies Spring but breaks Axon.
Also worth noting that, at least Ehcache in its current version, does not support notifying CacheEntryRemovedListeners when Cache.removeAll() is called or during cache shutdown. So the EventCountSnapshotterTrigger could get the wrong count when this happens.
this caching thing is really annoying. I was thinking about writing a custom abstraction, just like Spring did, but decided on using JCache as it seemed final. Unfortunately, the most recent version available differs too much from the final version. So I have to admit that, indeed, using JSR 107 was premature.
I am thinking about rewriting the EventCountSnapshotterTrigger to prevent the need for a Cache Listener. Once that’s done, it’s much easier to write an abstraction. Only add, update, delete and exists operations are required, similar to a Map.
Meanwhile, I will consider adding possibility for using EhCache directly, instead of the JCache abstraction in 2.1.x versions. That should work around the issue and make it usable again.
I’m not using Spring 4 yet, but I have had to work around JSR107 issues.
I had to make a forked copy of ehcache-jcache 1.5.-0.5 which fixed issue #10 and release it internally, then rebuild ontop of it.
It’s pretty suboptimal, but it seems to work.
I’d be totally onboard for Axon dropping JSR107 support in favour of a vanilla interface (bonus if it supported Ehcache), at least until JSR107 is more common place.
Thanks for the heads up about the jcache 1.0.0-RC1 <-> jcache 0.5 conflict!
I will think about releasing an internal version of ehcache-jcache – it sounds like you found the only workable solution – but for now I’ll just wait to upgrade to Axon 2.1.
We are impacted by this issue too. We’ve disabled caching for now awaiting for a fix.
Is there an existing issue logged for this in the Axon backlog ? I’m just trying to establish whether there’s a way for us to easily notice when this issue is resolved…
I have already started on a fix. With a bit of luck I’ll be able to release version 2.1.2 with the fix today. The issue is registered under http://issues.axonframework.org/youtrack/issue/AXON-229.
Just wondering, is anyone using another Cache provider than EhCache?
For now, this will not change anything about the custom Axon Cache API (which is much smaller than the javax cache one) approach. But it may hold some hope for the near future that EhCache will come up with a version implementing this API.
I didn’t quite manage to get the release done, but the fix has been deployed in the latest snapshot version: 2.1.2-SNAPSHOT
You can find the snapshot in Sonatype’s repository: https://oss.sonatype.org/content/repositories/snapshots/
If anyone has time to validate whether that fixes the problem for you, please let me know how it turned out.
Note that you will have to use the EhCacheAdapter between the Axon component and the EhCache that you’re using. Simply passing the EhCache instance into the EhCacheAdapter’s constructor should do the trick.
I was about to send an email that I will release 2.1.2 as soon as I have confirmation that this approach works. Did that just happen?
I’ll release 2.1.2 this evening or early tomorrow (CET).
