1 Reply Latest reply on Jun 18, 2014 10:01 AM by rhauch

    Repository backup/restore (tearing my hair)

    nl

      Hi guys,

       

      I am stuck on this issue running ModeShape 3.8 on a EAP5.1.

      My repository is started with a couple of node definitions using cnd files but also allows to create (dynamically) mixins and property defninitions on the fly which is working very well.

      For saftey reasons I want to create backups of my repository but regardless of what I do I fail...

       

      1. using session.exportSystemView("/", out, false, false) creates my a nice xml export file. The jcr:system node is included and reads the custom mixins and property defintitions. But once I try to import this into a "clean" repositoy ModeShape complains about missing node types and property definitions for each custom mixin and defintion (regardless of what ImportUUIDBehavior I choose. This leads me to the conclusion that the jcr:system node (and its subnodes) are not updated at all.
      2. using repositoryManager.backupRepository(directory) seems to work way faster than 1) but again I cannot restore a "clean" repository due to some Infinispan errors

        {noformat}

        java.lang.StringIndexOutOfBoundsException: String index out of range: 22

            at java.lang.String.substring(String.java:1907)

            at org.infinispan.schematic.internal.document.DefaultDocumentValueFactory.createDate(DefaultDocumentValueFactory.java:83)

            at org.infinispan.schematic.internal.document.JsonReader$DateValueMatcher.evaluateDate(JsonReader.java:988)

            at org.infinispan.schematic.internal.document.JsonReader$DateValueMatcher.parseDateFromLiteral(JsonReader.java:973)

        {noformat}

      Any ideas?

       

      Thanks, Niels

        • 1. Re: Repository backup/restore (tearing my hair)
          rhauch

          There are lots of conceptual problems with exporting XML for "backup" purposes, even when using the system view format. Exporting and importing this way will lose information, including version history. It's simply the limitation of the standard JCR import/export semantics. We created the backup and restore feature because it would be a much better (and faster) fit.

           

          I think you're running into the second problem because of timezone representations in the restore process. Can you share the backup that has this problem, or if not recreate one that does? Firstly, we need to fix the problem, and I can't figure out why the date format is wrong. Secondly, we need to improve the trace logging of the restore so that, via logging, one can determine what is going on and where it failed.