Karaf
  1. Karaf
  2. KARAF-1349

Can not share new configuration between user defined groups which have common node

    Details

      Description

      1.Start karaf and install cellar
      2.using group-create,group-set command,at last have two groups: grp1: n1&n2; grp2: n2&n3

      karaf@trun> cluster:group-list
      Node Group
      xlding:5702 grp1

      • xlding:5701 grp1
        xlding:5703 grp2
        xlding:5702 grp2

      3.on n1,

      karaf@trun> config:edit newPID
      karaf@trun> config:update

      4.on n3,

      karaf@trun> cluster:config-list grp2

      can not output 'newPID' in the last step,it should output it.

        Issue Links

          Activity

          Hide
          Jean-Baptiste Onofré added a comment -

          I'm gonna try to reproduce. Maybe the config sync is not enabled for grp2.

          I guess that n1 is in grp2, correct ?

          Show
          Jean-Baptiste Onofré added a comment - I'm gonna try to reproduce. Maybe the config sync is not enabled for grp2. I guess that n1 is in grp2, correct ?
          Hide
          Xiaoli Ding added a comment - - edited

          1.n1 and n2 in grp1,n2 and n3 in grp2. grp1 and grp2 has common node:n2. i excute 'config:edit newPID' on n1,i expect n1 propagate event to grp1,n2 create this configuration and throw an event to grp2 (as it also belongs to grp2. n3 also apply this change).

          2.for your question:"Maybe the config sync is not enabled for grp2."?
          when i create grp1 and grp2,i did not see the info about grp1 and grp2 in the file 'org.apache.karaf.cellar.groups.cfg',only have info about default group.about this,have filed a bug:https://issues.apache.org/jira/browse/KARAF-1306.
          so from myside,i hope would better to fix the 'KARAF-1306' first.
          when i filed this bug:'KARAF-1349',i create grp1 and grp2,i did not add the 'config sync' for grp2 manually.if there is no info about 'config sync' for grp2,it is enabled or not enabled by default?

          Show
          Xiaoli Ding added a comment - - edited 1.n1 and n2 in grp1,n2 and n3 in grp2. grp1 and grp2 has common node:n2. i excute 'config:edit newPID' on n1,i expect n1 propagate event to grp1,n2 create this configuration and throw an event to grp2 (as it also belongs to grp2. n3 also apply this change). 2.for your question:"Maybe the config sync is not enabled for grp2."? when i create grp1 and grp2,i did not see the info about grp1 and grp2 in the file 'org.apache.karaf.cellar.groups.cfg',only have info about default group.about this,have filed a bug: https://issues.apache.org/jira/browse/KARAF-1306 . so from myside,i hope would better to fix the ' KARAF-1306 ' first. when i filed this bug:' KARAF-1349 ',i create grp1 and grp2,i did not add the 'config sync' for grp2 manually.if there is no info about 'config sync' for grp2,it is enabled or not enabled by default?
          Hide
          Xiaoli Ding added a comment -

          for the again tring,i added the 'config sync' for grp1 and grp2 manually:'grp1.config.sync=true' and 'grp2.config.sync=true',grp1 and grp2 still have common node:n2,excute as follows:

          on n1(not the common node):

          karaf@trun> config:edit newPID
          karaf@trun> config:update

          on n3:

          karaf@trun> cluster:config-list grp2

          can not output 'newPID' on n3

          Show
          Xiaoli Ding added a comment - for the again tring,i added the 'config sync' for grp1 and grp2 manually:'grp1.config.sync=true' and 'grp2.config.sync=true',grp1 and grp2 still have common node:n2,excute as follows: on n1(not the common node): karaf@trun> config:edit newPID karaf@trun> config:update on n3: karaf@trun> cluster:config-list grp2 can not output 'newPID' on n3
          Hide
          Jean-Baptiste Onofré added a comment -

          Ok understood: I disabled the cluster event broadcasting in the LocalConfigurationListener as it creates an infinite loop in the ConfigurationEventHandler which consume a lot of CPU.

          I have to find a way to check where the update comes from in the event handler.

          Show
          Jean-Baptiste Onofré added a comment - Ok understood: I disabled the cluster event broadcasting in the LocalConfigurationListener as it creates an infinite loop in the ConfigurationEventHandler which consume a lot of CPU. I have to find a way to check where the update comes from in the event handler.
          Hide
          Xiaoli Ding added a comment -

          for the fourth step in description,still can not work

          Show
          Xiaoli Ding added a comment - for the fourth step in description,still can not work

            People

            • Assignee:
              Jean-Baptiste Onofré
              Reporter:
              Xiaoli Ding
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development