Uploaded image for project: 'ModeShape'
  1. ModeShape
  2. MODE-1620

Big import and workspace clone operations are slow

    XMLWordPrintable

Details

    • Bug
    • Resolution: Cannot Reproduce
    • Critical
    • 3.0.0.CR1
    • 3.0.0.Beta2
    • JCR, Performance
    • None

    Description

      I noticed a dramatic slowdown in our import/ delete operations in case they affect the whole workspace (e.g: all nodes). We have 2 different logicals in our system that are used to either import an workspace from external xml file or to overcopy one workspace content to another workspace in a developement-staging-production workflow. I noticed this was fast under 2.7, but somehow during 2.8 it got slower and also on 3.0.Beta2 its quite slow. Slow here means those operations take 10 to 45 seconds for our small 5MB big repo (XML export file is just that small!). I somehow suspect this issue to be the cause of it: MODE-1422

      The question is now how we can enhance the speed to a point near zero and in best case do this in a closed transaction, so no outsider should notice the underlying content just changed.

      Below are the logical parts that to the JCR work.

      Any recommendations are warmly welcome, as I'm getting a headache thinking at a 10 or even 20MB big repo - then this would mean we need serveral minutes to push content changes.

      Import Logic:

      FileUpload u = upload.getModelObject();
                      if (u != null) {
                          try {
                              InputStream s = u.getInputStream();
                              String id = ManageSnapshotsPanel.this.getModelObject().getId();
                              Brix brix = getBrix();
                              JcrSession session = brix.getCurrentSession(id);
       
                              // explicitely clear brix root and save it to session prior import! - prior Modeshape 2.8.1 this wont be necessary?
                              if (session.itemExists(brix.getRootPath())) {
                                  session.getItem(brix.getRootPath()).remove();
                                  session.save();
                              }
       
                              session.importXML("/", s,
                                      ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
                              session.save();
       
                              brix.initWorkspace(ManageSnapshotsPanel.this.getModelObject(), session);
       
                              getSession().info(ManageSnapshotsPanel.this.getString("restoreSuccessful"));
                          } catch (IOException e) {
                              throw new BrixException(e);
                          }
                      }
      

      Clone-Logic:

        public void clone(JcrSession src, JcrSession dest) {
              cleanWorkspace(dest);
              cloneWorkspace(src, dest);
          }
       
          private void cleanWorkspace(JcrSession session) {
              if (session.itemExists(getRootPath())) {
                  JcrNode root = (JcrNode) session.getItem(getRootPath());
                  root.remove();
                  session.save();
              }
       
              session.save();
          }
       
          public String getRootPath() {
              return "/" + ROOT_NODE_NAME;
          }
       
          private void cloneWorkspace(JcrSession srcSession, JcrSession destSession) {
              String root = getRootPath();
              destSession.getWorkspace().clone(srcSession.getWorkspace().getName(), root, root, true);
          }
      

      Attachments

        1. 2.7.txt
          2 kB
          Oleg Kulikov
        2. 2.8.final.txt
          2 kB
          Oleg Kulikov
        3. 3.0.0.B1.txt
          2 kB
          Oleg Kulikov
        4. 3.0.snapshot.txt
          2 kB
          Oleg Kulikov
        5. jackrabbit.txt
          2 kB
          Oleg Kulikov

        Activity

          People

            oleg.kulikov Oleg Kulikov (Inactive)
            kbachl K. Bachl (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: