0 Replies Latest reply on Jul 30, 2015 1:36 PM by Alex Kochnev

    Redis backed distributed cache implementation and configuration

    Alex Kochnev Newbie

      We're implementing a distributed cache implementation that can store the cache data in Redis using JBoss EAP 6.2 (apprently, JBoss AS 7.x). We have things more or less working, but a few things don't quite fit with how it seems things should be, so I'm looking for some thoughts / guidance .

       

      I haven an implementation of org.jboss.as.clustering.web.DistributedCacheManagerFactory and it's registered in META-INF services (similar to how it works in jboss-as/clustering/web-infinispan ) , so that whenever the web app is marked as <distributable/> in web.xml, my distributed cache manager factory is called. The implementation is somewhat basic, but in the end it manages to accomplish the task of storing the session data into Redis.

       

      Now, here are a few things that aren't quite right :

      * In order for the distributed cache to work, it needs some configuration data passed on to it (e.g. the redis servers that it needs to connect to, etc). In the current situation, the DistributedCacheManagerFactory implementation registered in META-INF doesn't have a way of getting that configuration information at startup. I've looked at some of the configuration objects that I could inject into the implementation (similar to how  jboss-as/DistributedCacheManagerFactory.java at master · PayU/jboss-as · GitHub  works), but I didn't find a way that I can add some configuration in the infinispan subsystem configuration (xml) that I can later consume when the distributed cache manager factory is called. What is the proper way to do this ? Should I be implementing a jboss subsystem/extension for my own implementation that can then take this configuration that I want, or is there a lower-friction approach that I could use (e.g. maybe put the configuration that I need in a "store") ?


      * For that matter, if I only want to change where the distributed cache data is stored (e.g. in Redis), should I be just implementing a custom-store using my own class instead of going the full DistributedCacheManager factory ?

       

      * Looking at the jboss-as/DistributedCacheManagerFactory.java at master · PayU/jboss-as · GitHub implementation, there is quite a bit going on - the injected services, how they get injected and how they interact, etc. I think I have managed to wrap my head around it (far from understanding it all), but I wonder : is there something somewhere (other than source code) that explains how to work w/ the internals of JBoss (e.g. all of these services being registered, dependencies being added, etc)  - e.g. a book, wiki document, Jira issue, something...

       

      * One of the ways that I managed to get around the configuration issue for the cache is that I have a SAR deployed in JBoss that performs the initialization (and has the configuration that's needed), and then when the distributed cache manager is called it can use the initialized configuration from the SAR deployment. That approach however is not quite solid because of the initialization / ordering - e.g. often times the DistributedCacheManager would be called first (during the internal tomcat initialization) before the SAR service is initialized (causing unpleasant dilemmas on how to deal w/ this initialization order). If this is the approach, at least I'd like to be able to specify that the DistributedCacheManager shouldn't be initialized until my SAR is initialized; however, I couldn't quite figure out a way to add a dependency on the SAR module in the module that provides the distributed cache manager.

       

      In any case - I understand that many of the questions above might not have straightforward answers, but I would appreciate thoughts and pointers as to where I should look. I feel like I've scoured all the places I could search for answers, looked at source code, and still don't have an answer that works as well as I expect it should (after all, JBoss is a wonderful, modular, and things like this are done all the time, I just don't know how).