5 Replies Latest reply on Mar 24, 2014 10:52 AM by Randall Hauch

    Suggestion for configuration of binary files

    Michael Dinsmore Newbie

      Hello,

        I am currently looking into using ModeShape to store many various binary files.  Some of these could be very large binary files.  Because of this, I think I would want to use the newer ModeShape version which fixes the hashing for binary files as well as a file-based store instead of a JDBC (Oracle) one.  Is this correct? Any suggestions or recommendations for best practices on setting up a configuration for a binary storage system using ModeShape in this manner.  Is there any known limits for ModeShape in storage of binary files?  I want to use this in a traditional repository sense -- as I need to store/persist files for later retrival.  Any documentation that points me to the right location would be welcome - I'm slowly working my way through the existing documentation (Home - ModeShape 3 - Project Documentation Editor).

       

        I am currently running Wildfly 8 and modeshape-4.0-SNAPSHOT (I downloaded and build sources from GIT repository).

      Thanks,

      Mike

        • 1. Re: Suggestion for configuration of binary files
          Randall Hauch Master

          Feel free to keep using your own 4.0-SNAPSHOTs. An alpha release is imminent, though the "alpha-ness" really applies almost entirely to the new query engine; everything else is really more solid than 3.7.1.

           

          As far as best practices, you can use the nominal repository setup (normal persistence, binary storage, etc.), and simply evaluate this against your requirements. For large files you may want to consider looking at only the file system binary store or the Infinispan binary store (which stores the files in chunks). Another option is to store them outside ModeShape on a file system (perhaps networked) by setting up a file system connector that exposes the directories and files as nodes in one area of the repository. This would allow other applications to directly access the files.

           

          We have community members using both approaches to store very large files. Perhaps they could weigh in here as to what they see as the pros/cons of each approach.

          1 of 1 people found this helpful
          • 2. Re: Suggestion for configuration of binary files
            Michael Dinsmore Newbie

            Thanks for the reply, Randall.  Perhaps the file system connector would be along the lines of what I might want to do but I will try out the other method to see how it works.  I'm trying to find some documentation on how to set that up along with the repository configuration and getting a bit lost.  Some of the documentation, to my novice eyes, appears disjointed and it's hard to see where it all comes together.

            • 4. Re: Suggestion for configuration of binary files
              Michael Dinsmore Newbie

              Thanks, I am, and have, looked at them. I do have it up and running along with connection to the repository in my code.  I have no idea if it's all set up to what should be done versus my setup that works but may not be optimal.  I guess I'll find out as I do more testing!

               

              I'm still trying to decide the best strategy for running this in dev/qa/prod type environments - I guess I need to change my standalone repository configuration to a json definition and load that per environment setting or the like.  Is there a way to have it spit out the json equivalent to my xml configuration when it's running?

              • 5. Re: Suggestion for configuration of binary files
                Randall Hauch Master

                No, unfortunately we don't have any tools that converts an XML configuration to JSON (or vice versa). Honestly we didn't think people would switch very often. The challenge is that the configurations are for entirely different components: the JSON configuration is for the ModeShapeEngine that can be embedded in any Java app, whereas the XML configuration is for the ModeShape subsystem in EAP. The latter uses the former, but still it is a very different component with EAP-based XML structure.