Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5
    • Component/s: clustering, jackrabbit-core
    • Labels:
      None

      Description

      When workspace is created on cluster node A and then node added to that workspace, the proper event is sent to the journal, but other cluster nodes are not able to process it because they don't have the workspace.

      It would be nice to have a configuration option for the cluster to create such workspace automatically (instead of just logging an error)

      1. patch-705243.txt
        34 kB
        Matej Knopp
      2. patch-704324.txt
        29 kB
        Matej Knopp
      3. patch-1677-2.txt
        8 kB
        Matej Knopp
      4. patch-1677-1.txt
        9 kB
        Matej Knopp

        Issue Links

          Activity

          Hide
          Jukka Zitting added a comment -

          Patch applied in revision 711238.

          I also created a test case for this functionality in sandbox/jackrabbit-test-harness/cluster.

          Show
          Jukka Zitting added a comment - Patch applied in revision 711238. I also created a test case for this functionality in sandbox/jackrabbit-test-harness/cluster.
          Hide
          Jukka Zitting added a comment -

          Looks great, thanks! I'll review the patch in more detail and try it out in practice later tonight.

          Show
          Jukka Zitting added a comment - Looks great, thanks! I'll review the patch in more detail and try it out in practice later tonight.
          Hide
          Matej Knopp added a comment -

          Patch with corrected formatting and license headers

          Show
          Matej Knopp added a comment - Patch with corrected formatting and license headers
          Hide
          Matej Knopp added a comment -

          "Proper" patch that uses workspace configuration from original node when creating workspaces across cluster

          Show
          Matej Knopp added a comment - "Proper" patch that uses workspace configuration from original node when creating workspaces across cluster
          Hide
          Alexander Klimetschek added a comment -

          > For example it conflicts with the JackrabbitWorkspace.createWorkspace(String, InputSource) method (see [1]).

          > The reason why the <Workspace/> element in repository.xml is just the default template is to allow different workspace
          > to be configured differently. Such non-uniform setups are actually fairly common (at least in deployments that I see).

          I agree with Jukka. My first patch analysis was faulty, supporting different workspace configurations is important.

          Show
          Alexander Klimetschek added a comment - > For example it conflicts with the JackrabbitWorkspace.createWorkspace(String, InputSource) method (see [1] ). > The reason why the <Workspace/> element in repository.xml is just the default template is to allow different workspace > to be configured differently. Such non-uniform setups are actually fairly common (at least in deployments that I see). I agree with Jukka. My first patch analysis was faulty, supporting different workspace configurations is important.
          Hide
          Jukka Zitting added a comment -

          > not sure what is not technically sound about this.

          For example it conflicts with the JackrabbitWorkspace.createWorkspace(String, InputSource) method (see [1]).

          The reason why the <Workspace/> element in repository.xml is just the default template is to allow different workspace to be configured differently. Such non-uniform setups are actually fairly common (at least in deployments that I see).

          Of course the patch makes such clustered workspace creation optional, so one could argue that people with such non-uniform setups should just not enable this feature. But since implementing this feature properly for all sorts of setups is not really that much harder (the patch for JCR-699 was only twice as big as the current patch here), I would rather not opt for a partial fix that we'd then need to keep supporting for backwards compatibility reasons.

          > i am curious why you removed 1.5 fix version

          See the 1.5 release plan updates on dev@. I plan to move forward with 1.5 already within the next few weeks and would rather postpone unfinished issues to 1.6.

          I'd like have this feature included already in 1.5, but only if we do it along the lines of JCR-699.

          [1] http://jackrabbit.apache.org/api/1.4/org/apache/jackrabbit/api/JackrabbitWorkspace.html#createWorkspace(java.lang.String, org.xml.sax.InputSource)

          Show
          Jukka Zitting added a comment - > not sure what is not technically sound about this. For example it conflicts with the JackrabbitWorkspace.createWorkspace(String, InputSource) method (see [1] ). The reason why the <Workspace/> element in repository.xml is just the default template is to allow different workspace to be configured differently. Such non-uniform setups are actually fairly common (at least in deployments that I see). Of course the patch makes such clustered workspace creation optional, so one could argue that people with such non-uniform setups should just not enable this feature. But since implementing this feature properly for all sorts of setups is not really that much harder (the patch for JCR-699 was only twice as big as the current patch here), I would rather not opt for a partial fix that we'd then need to keep supporting for backwards compatibility reasons. > i am curious why you removed 1.5 fix version See the 1.5 release plan updates on dev@. I plan to move forward with 1.5 already within the next few weeks and would rather postpone unfinished issues to 1.6. I'd like have this feature included already in 1.5, but only if we do it along the lines of JCR-699 . [1] http://jackrabbit.apache.org/api/1.4/org/apache/jackrabbit/api/JackrabbitWorkspace.html#createWorkspace(java.lang.String , org.xml.sax.InputSource)
          Hide
          Igor Vaynberg added a comment -

          not sure what is not technically sound about this. it makes an assumption that all workspace.xml files are the same which is a subset of the case when you make no such assumption....curious under which circumstances you would run a cluster of jackrabbit servers that have different workspace.xml definitions...

          anyways, i am curious why you removed 1.5 fix version, does it mean you no longer plan to support this functionality in 1.5 release?

          Show
          Igor Vaynberg added a comment - not sure what is not technically sound about this. it makes an assumption that all workspace.xml files are the same which is a subset of the case when you make no such assumption....curious under which circumstances you would run a cluster of jackrabbit servers that have different workspace.xml definitions... anyways, i am curious why you removed 1.5 fix version, does it mean you no longer plan to support this functionality in 1.5 release?
          Hide
          Jukka Zitting added a comment -

          > why not apply the patch as it is for 1.5 and fix it better in a later version?

          I don't think that the current patch is a technically sound solution to this issue. Sure, it works in specific circumstances but it also fails miserably in others. There is also no reasonably backwards-compatible way of upgrading this feature to something better in future releases, so it would essentially be a one-off hack.

          Implementing this feature properly shouldn't be too hard. See JCR-699 for an example on how this was done for node type registration.

          Show
          Jukka Zitting added a comment - > why not apply the patch as it is for 1.5 and fix it better in a later version? I don't think that the current patch is a technically sound solution to this issue. Sure, it works in specific circumstances but it also fails miserably in others. There is also no reasonably backwards-compatible way of upgrading this feature to something better in future releases, so it would essentially be a one-off hack. Implementing this feature properly shouldn't be too hard. See JCR-699 for an example on how this was done for node type registration.
          Hide
          Igor Vaynberg added a comment -

          why not apply the patch as it is for 1.5 and fix it better in a later version?

          i think it is reasonable to assume that all nodes are using the same workspace.xml. usually all nodes in a cluster are configured the same way...

          this is also a blocker for us as far as taking our application into production.

          Show
          Igor Vaynberg added a comment - why not apply the patch as it is for 1.5 and fix it better in a later version? i think it is reasonable to assume that all nodes are using the same workspace.xml. usually all nodes in a cluster are configured the same way... this is also a blocker for us as far as taking our application into production.
          Hide
          Jukka Zitting added a comment -

          The patch assumes that the <Workspace/> configuration templates in the repository.xml configuration files on the different cluster nodes are essentially identical. It might be better to explicitly use the workspace.xml file that was used to create the workspace in the originating node.

          More generally, I think it would be better to handle this as an explicit createWorkspace() event in the cluster journal instead of implicitly creating new workspaces whenever cluster events referring to those workspaces are seen.

          Show
          Jukka Zitting added a comment - The patch assumes that the <Workspace/> configuration templates in the repository.xml configuration files on the different cluster nodes are essentially identical. It might be better to explicitly use the workspace.xml file that was used to create the workspace in the originating node. More generally, I think it would be better to handle this as an explicit createWorkspace() event in the cluster journal instead of implicitly creating new workspaces whenever cluster events referring to those workspaces are seen.
          Hide
          Matej Knopp added a comment -

          Removed checkstyle.xml from patch

          Show
          Matej Knopp added a comment - Removed checkstyle.xml from patch
          Hide
          Matej Knopp added a comment -

          The patch includes changes to checkstyle.xml, sorry about it, will commit new patch shortly.

          Show
          Matej Knopp added a comment - The patch includes changes to checkstyle.xml, sorry about it, will commit new patch shortly.
          Hide
          Alexander Klimetschek added a comment -

          The patch looks good to me. Shall we include this for 1.5?

          Show
          Alexander Klimetschek added a comment - The patch looks good to me. Shall we include this for 1.5?
          Hide
          Matej Knopp added a comment -

          Simple patch implementing the feature

          Show
          Matej Knopp added a comment - Simple patch implementing the feature

            People

            • Assignee:
              Jukka Zitting
              Reporter:
              Matej Knopp
            • Votes:
              4 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development