Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2.12, 2.4.1, 2.5
    • Component/s: None
    • Labels:
      None

      Description

      I need to know the cluster node id in my application. I didn't find any other way than to cast to org.apache.jackrabbit.core.RepositoryImpl : ((RepositoryImpl) session.getRepository()).getConfig().getClusterConfig().getId()

      I would appreciate it if I could get to this using the system property ClusterNode.SYSTEM_PROPERTY_NODE_ID.

        Activity

        Hide
        Bart van der Schans added a comment -

        The only problem I can think of is when running two JR instances in one JVM. If that is a concern we could add a method (in the JR api?) to fetch the id. Is this a real concern or can I go ahead and apply the patch?

        Show
        Bart van der Schans added a comment - The only problem I can think of is when running two JR instances in one JVM. If that is a concern we could add a method (in the JR api?) to fetch the id. Is this a real concern or can I go ahead and apply the patch?
        Hide
        Alex Parvulescu added a comment -

        > two JR instances in one JVM
        I can see one problem where you start 2 nodes one after the other, the first one generates an id and sets the system property, then the second one will use the already set property as the id.
        This will break the scenario where you start 2 nodes just to run a simple test on you local machine, and it can probably affect unit testing / integration testing as well.

        If this is only about convenience, probably adding a method to JctUtils would be the easiest.

        Show
        Alex Parvulescu added a comment - > two JR instances in one JVM I can see one problem where you start 2 nodes one after the other, the first one generates an id and sets the system property, then the second one will use the already set property as the id. This will break the scenario where you start 2 nodes just to run a simple test on you local machine, and it can probably affect unit testing / integration testing as well. If this is only about convenience, probably adding a method to JctUtils would be the easiest.
        Hide
        Jukka Zitting added a comment -

        In CRX we expose the cluster node id through an extra "crx.cluster.id" repository descriptor. I think Jackrabbit could well do something similar.

        Show
        Jukka Zitting added a comment - In CRX we expose the cluster node id through an extra "crx.cluster.id" repository descriptor. I think Jackrabbit could well do something similar.
        Hide
        Bart van der Schans added a comment -

        I like the descriptor idea. I'll try to find some time to create a patch,

        Show
        Bart van der Schans added a comment - I like the descriptor idea. I'll try to find some time to create a patch,
        Hide
        Bart van der Schans added a comment -

        Any objections to committing this also to the 2.4 and 2.2 branches?

        Show
        Bart van der Schans added a comment - Any objections to committing this also to the 2.4 and 2.2 branches?
        Hide
        Jukka Zitting added a comment -

        The descriptor, not the system property? No objections here.

        We normally avoid backporting any non-bugfix changes to maintenance branches to reduce the chance of unexpected breakage (and to avoid compatibility issues between two patch releases from the same branch), but the potential impact of a change like this is so minimal that if you find this feature useful then I'm fine with backporting it to 2.4 and 2.2.

        Show
        Jukka Zitting added a comment - The descriptor, not the system property? No objections here. We normally avoid backporting any non-bugfix changes to maintenance branches to reduce the chance of unexpected breakage (and to avoid compatibility issues between two patch releases from the same branch), but the potential impact of a change like this is so minimal that if you find this feature useful then I'm fine with backporting it to 2.4 and 2.2.
        Hide
        Bart van der Schans added a comment -

        That is exactly the reason why I asked Thx. Backported to 2.4 and 2.2.

        Show
        Bart van der Schans added a comment - That is exactly the reason why I asked Thx. Backported to 2.4 and 2.2.

          People

          • Assignee:
            Bart van der Schans
            Reporter:
            Unico Hommes
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development