1 2 Previous Next 20 Replies Latest reply on May 11, 2010 7:35 AM by John Ament

    Utilizing Infinispan's GridFilesystem

    Randall Hauch Master

      Infinispan 4.1 Alpha 1 just introduced a pretty cool feature to make Infinispan act like a grid-based file system. This capability would be a fantastic addition to ModeShape to expose and manipulate those files and directories through standard JCR interfaces, while benefiting from the awesome grid storage capabilities of Infinispan.

       

      I've create a JIRA for this new feature (MODE-707), and the good news is that our existing file system connector does everything we need - with the exception of creating that top-level java.io.File object. So there are a few options for how to go about making these few changes.  Here are the options I came up with:

       

      1. The existing file system connector could be changed in a very minor way to accept a root File object in the FileSystemSource. Impact: no firm dependency on Infinispan, since the client would need to instantiate the GridFilesystem. But this could be difficult to set up via XML or JCR configuration.
      2. Subclass the FileSystemSource and place inside the existing Infinispan connector project (so that project would have 2 connectors). Impact: this would introduce in the Infinispan connector a dependency on the modeshape-connector-filesystem project (which depends on nothing else) and the current Infinispan connector depends on 4.0.0.Final rather than 4.1 alpha.
      3. Introduce a new project that extends the file system connector by simply changing how the root File object is created. Impact: this new connector would depend on the FileSystem connector, would have almost no code, but would have zero impact on the other connector projects.

       

      Any thoughts or preferences? If you can think of another option, please say so.

        • 1. Re: Utilizing Infinispan's GridFilesystem
          John Ament Master

          What about option 4?

           

          create a new project that depends on one of the other 2 projects (e.g. infinispan connector or file system connector) and subclass from there.

           

          i think you should look at how the seam 3 team is working w/ their modules; everything is a separate artifact and you don't need to release your entire infrastructure for it.

          • 2. Re: Utilizing Infinispan's GridFilesystem
            Brian Carothers Apprentice

            I think option 3 and option 4 are both saying the same thing.  I vote for option 3/4.  It's consistent with our de facto existing approach ("make a million small subprojects for connectors to keep them as independent as possible").  This is also consistent with Spring  (and, apparently, SEAM) packaging practices.

            • 3. Re: Utilizing Infinispan's GridFilesystem
              Randall Hauch Master

              This is also consistent with Spring  (and, apparently, SEAM) packaging practices.

              I believe that SEAM is starting to move towards releasing each subproject independently, on its own schedule. That's still different than what we're currently doing.

               

              I'm not quite sure we're ready for that yet. It wouldn't really affect a Maven-based app, but for "regular" Java apps with a classpath, the classpath would contain a hodge-podge of different connector/sequencer versions, and that could get messy. So while this wouldn't be my preferred choice, I definitely see the advantages and could be convinced if the community wants to go this route.

              • 4. Re: Utilizing Infinispan's GridFilesystem
                John Ament Master

                Well, your connectors are just implementing a single interface, correct?  I would think if the connector interface does not change then x connector would be compatible with modeshape v.something.

                 

                plus, from the mavenized side, i can't imagine a project being dependent on more than 2 connectors.

                 

                but that's kind of deviating from this thread's topic.

                • 5. Re: Utilizing Infinispan's GridFilesystem
                  Randall Hauch Master

                  John Ament wrote:

                   

                  What about option 4? ... create a new project that depends on one of the other 2 projects (e.g. infinispan connector or file system connector) and subclass from there.

                  ...

                   

                  Brian Carothers wrote:

                   

                  I think option 3 and option 4 are both saying the same thing.  I vote for option 3/4.  It's consistent with our de facto existing approach ("make a million small subprojects for connectors to keep them as independent as possible").  ...

                   

                  This would also be very minimal code if we created a new connector project and subclassed the existing FileSystemSource class (in the file system connector).

                   

                  Then there's the question of which Infinispan version(s) should our connectors depend on. Again, I see three options (please holler if you see other options):

                  1. Have this new connector depend on the latest Infinispan release (e.g., 4.1.0.BETA1 that is due in a few weeks), and leave 'modeshape-connector-infinispan' on 4.0.0.FINAL. This would imply the two connectors couldn't (easily) be used in the same app, unless some classloader magic is used.
                  2. Change both connectors to use Infinispan 4.1.0.BETA1, allowing both to be (easily) used within the same app. If someone wanted to use Infinispan 4.0.0.FINAL, it's quite likely they could use 'modeshape-connector-infinispan' from ModeShape 1.1.
                  3. Keep things simple and wait to create this new connector until a ModeShape release that can depend on Infinispan 4.1.0.FINAL.

                   

                  Thoughts?

                  • 6. Re: Utilizing Infinispan's GridFilesystem
                    Randall Hauch Master

                    John Ament wrote:

                    ...

                    plus, from the mavenized side, i can't imagine a project being dependent on more than 2 connectors.

                    ...

                     

                    You're right - in most traditional JCR applications, there'd be just a single connector to store all content. But with ModeShape it's easy to use the federated connector for the JCR storage, where most content is projected from one storage connector but project other content from other connectors. There are several folks looking at this scenario to allow them to store/access files and directories in one system but the rest of the JCR content in a traditional way.

                    • 7. Re: Utilizing Infinispan's GridFilesystem
                      John Ament Master

                      My vote goes to #1, assuming that you add documentation explaining how to use maven excludes in order to do this properly (since I'd assume 4.1 doesn't change what 4.0 does so the infinispan connector can work correctly).

                       

                      Also, I'm curious to know why you don't have a way to configure infinispan from within modeshape? it seems weird that it's either use the default cache manager or look one up via jndi, but no way to pass in the infinispan config file?

                      • 8. Re: Utilizing Infinispan's GridFilesystem
                        Randall Hauch Master

                        John Ament wrote:

                        ...

                        Also, I'm curious to know why you don't have a way to configure infinispan from within modeshape? it seems weird that it's either use the default cache manager or look one up via jndi, but no way to pass in the infinispan config file?

                        Good point. I'm not sure why we don't offer that option. Care to log a JIRA?

                        • 10. Re: Utilizing Infinispan's GridFilesystem
                          Jeff Brown Newbie

                          Does the "cacheConfigurationName" decribed in the connector for 1.1.0Final Reference guide provide this functionality?  At least from the description it sounds like it:

                          "Optional property that, if used, specifies the name of the configuration that is supplied to the cache manager when creating a new
                          Infinispan CacheManager instance.
                          "

                          Am I missing something?

                          • 11. Re: Utilizing Infinispan's GridFilesystem
                            Brian Carothers Apprentice

                            I believe that, in this case, the documentation describes how it's supposed to work rather than how it works.  The cacheConfigurationName parameter doesn't get read in InifnispanSource.getConnection().

                             

                            You can expect to see that bug get fixed in the near future, but a workaround for right now is to configure the Infinispan cache outside of ModeShape, bind it to JNDI, and use the cacheManagerJndiName property to link the InifnispanRepository to your cache manager.

                            • 12. Re: Utilizing Infinispan's GridFilesystem
                              John Ament Master

                              i think what i'm describing and what you're describing are two very different things.  what i'm saying is that there's no way to tell modeshaper how to configure infinispan before using it - either you create a cache manager and bind it to JNDI, then initial mode shape to use that cache manager; or you use the default cache manager only.  using only the default cache manager covers a very simplistic use case - you miss out on the clustering/replication of infinispan.  the property you're describing tells modeshape what to plugin for the method call cacheManager.getCache(String cacheName), and this doesn't seem to work either.  looking back at what i describe though, it seems clear that there were a few things missed along the way

                              • 13. Re: Utilizing Infinispan's GridFilesystem
                                Brian Carothers Apprentice

                                I could be mistaken, but it sounds like you're expecting the cacheConfigurationName (once fixed) to be used as an argument to cacheManager.getCache(cacheName).  This won't work in the current implementation, as we use one cache per workspace.   In other words, we're already calling cacheManager.getCache(workspaceName).[1]

                                 

                                My intent was to implement this as cacheManager = new DefaultCacheManager(cacheConfigurationName) and use cacheConfigurationName as a path to a resource or file containing configuration information.  This restores the ability to bundle custom Infinispan configuration with a ModeShape deployment that I accidentally removed a few months ago.

                                 

                                This falls somewhat short of the original request in MODE-711 to be able to provide Infinispan configuration either through an external file or inline in the connector configuration.  I'm trying to avoid having inline configuration that would have to match how some other project laid out their configuration file.  Does the approach above get us to where we need to be?

                                 

                                Thanks to all for the discussion and for any future feedback.

                                 

                                 

                                 

                                [1] - It's possible that this could change in the near future.  The connectors that support referenceable nodes are currently undergoing some rework to have better support for atomic transactions.  That's why I haven't already implemented my proposed fix for MODE-711 - the code is in flux.

                                • 14. Re: Utilizing Infinispan's GridFilesystem
                                  Jeff Brown Newbie

                                  Brian, yes I think we are on the same page.  I was expecting that property to point to an Infinispan resource configuration file, so that I could configure the Infinispan cache as distributed or replicated, etc - basically full control over the cache configuration.   Sounds like that is the plan for the future.  For now, I will try the workaround you suggested of instantiating the cache externally and connecting via JNDI.  However, you metion this functionality use to work?  If so, what version of ModeSpace was this working with - perhaps I will revert back to that version...  Thanks again.

                                  1 2 Previous Next