Hi all, just completed first iteration of Mobicents Cluster Framework 2.x, which includes impl using first alpha release of Infinispan 5. We have everything we had in jboss cache working, it's a dumb down but higher level framework, with stuff like Fault Tolerant timers, which is then reuse in whole Mobicents platform to provide cluster related features. I believe we now already use a lot of stuff from Infinispan rich feature set, so I guess it's good timing to give some feedback, report some minor issues, and clear some doubts. 1) Marshallers Generally I'm "just OK" with the current API, the fact it Externalizers depends on Annotations makes impossible for a higher level framework to allow it's clients to plug their own kind of Externalizers, without exposing Infinispan classes. In concrete, our framework exposes its own Externalizer model, but to use them we need to wrap the instances of classes these handle, in classes bound to Infinispan Externalizers, which when invoked by Infinispan then lookup our "own" Externalizers, that is, 2 Externalizers lookups per call. If there was no annotations required we could wrap instead our clients Externalizers and plug them into Infinispan, this would mean a single Externalizer lookup. By the way, since the Externalizer now uses generics the Annotations values look bad, specially since it's possible to introduce errors that can compile. Another issue, in this case I consider it of minor importance due to low level of Externalizers concept, is the lack of inheritance of Externalizers, for instance we extend DefaultConsistentHash, instead of extending its Externalizer I had to make an Externalizer from scratch, and copy of DefaultConsistenHash's Externalizer code. This is messy to manage, if the code on Infinispan change we will always have to check if the code we copied is still valid. 2) CacheContainer vs CacheManager The API is now deprecating the CacheManager, replacing with CacheContainer, but some functionality is missing, for instance CacheContainer is not a Listenable, thus no option to register Listeners, unless unsafe casting of the instance exposed by the Cache or a ref is available to the original CacheManager. Related matter, IMHO a Cache listener should be able to listen to CacheManager events, becoming global listeners. 3) Configuration stuff Generally I think the Configuration and GlobalConfiguration could be simplified a bit, I found myself several times looking at the impl code to understand how to achieve some configurations. Better documentation wouldn't hurt too, it's great to have a complete reference, but the configuration samples are not ok, one is basically empty, the other has all possible stuff, very unrealistic, would be better to have reusable examples for each mode, with then recommendations on how to improve these. Infinispan 5 introduces a new global configuration setter to provide an instance, with same method name as the one to provide the class name. I believe one is enough, and to be more friendly with Microcontainer and similar frameworks I would choose the one to set the instance. 4) AtomicMap doubt I read in the Infinispan blog that AtomicMap provides colocation of all entries, is that idea outdated? If not we may need a way to turn that off :) For instance would not that mean the Tree API does not works well with distribution mode? I apologize in advance if I'm missing something, but if AtomicMap defines colocation, AtomicMap is good for the node's data map, but not for the node's childs fqns. Shouldn't each child fqn be freely distributed, being colocated instead with the related node cache entry and data (atomic)map? Our impl is kind of an "hybrid" of the Tree API, allows cache entries references (similar to childs) but no data map, and the storage of references through AtomicMap in same way as Tree API worries me. Please clarify. 5) Minor issues found See these a lot, forgotten info logging? 03:39:06,603 INFO [TransactionLoggerImpl] Starting transaction logging 03:39:06,623 INFO [TransactionLoggerImpl] Stopping transaction logging MBean registration tries twice the same MBean, the second time fails and prints log (no harm besides that, the process continues without failures): 03:39:06,395 INFO [ComponentsJmxRegistration] Could not register object with name: org.infinispan:type=Cache,name="___defaultcache(dist_sync)",manager="DefaultCacheManager",component=Cache 6) Final thoughts Kind of feel bad to provide all these negative stuff in a single mail, took me an hour to write it, but don't get me wrong, I really enjoy Infinispan, it's a great improvement. I'm really excited to have it plugged in AS7 (any plan on this?) and then migrate our platform to this new cluster framework. I expect a big performance improvement, on something already pretty fast, and much less memory usage, our Infinispan impl "feels" very fine grained and optimized in all points of view. Of course, the distribution mode is the cherry on top of the cake, hello true scalability. I hope to find time to contribute back more, and in better ways, like concrete enhancements or issues with test cases as happened with jboss cache, but right now that's the best I could. By the way, I'm using the nick mart1ns in the infinispan freenode irc channel, feel free to ping me there. Regards, -- Eduardo .............................................. http://emmartins.blogspot.com http://redhat.com/solutions/telco