[
https://issues.apache.org/jira/browse/ARTEMIS-4007?focusedWorklogId=810727&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-810727
]
ASF GitHub Bot logged work on ARTEMIS-4007:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 21/Sep/22 12:31
Start Date: 21/Sep/22 12:31
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4228:
URL: https://github.com/apache/activemq-artemis/pull/4228#discussion_r976438246
##########
artemis-cli/src/main/resources/org/apache/activemq/artemis/cli/commands/bin/artemis-service:
##########
@@ -1,4 +1,4 @@
-#!/usr/bin/env sh
+ #!/usr/bin/env sh
Review Comment:
Should this be here?
##########
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/server/ConfigurationTest.java:
##########
@@ -122,6 +124,9 @@ public void testPropertiesConfigReload() throws Exception {
return mytopic_31.getBindings().size() == 3;
});
+ // verify round trip apply
+
Assert.assertTrue(server.getActiveMQServerControl().getStatus().contains("2"));
Review Comment:
Is the config update application atomic or can updates to one element be
seen mid-application of others? If the latter then this doesnt necessarily seem
to reliably achieve what you want as the 'status' value may be visible before
other changes in the update are actually applied? I guess you could apply a
second status-only change to the config, after the first round is seen, to know
the first update process had finished, since you can see the second update in
effect.
##########
artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/ActiveMQServerControl.java:
##########
@@ -521,6 +521,9 @@ public interface ActiveMQServerControl {
@Attribute(desc = "The runtime size of the authorization cache")
long getAuthorizationCacheSize();
+ @Attribute(desc = "The current status of the server")
+ String getStatus();
+
Review Comment:
Having a 'status' attribute ("The current status of the server") which isnt
actually a server status but just a configurable config string that defaults to
empty, seems off to me. I would call this something else either more specific
or more general. Seems more like the intent is to use it as a config update
correlation of sorts, perhaps wind that function into the name?
Issue Time Tracking
-------------------
Worklog Id: (was: 810727)
Time Spent: 20m (was: 10m)
> properties config - complete feedback loop with server status attribute
> -----------------------------------------------------------------------
>
> Key: ARTEMIS-4007
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4007
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 2.25.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Following on from ARTEMIS-4001 - in kubernetties - where properties can be
> mounted as projections of config maps, there can be a large delay between
> update and the refresh being visible to the broker.
> Adding a status attribute to the server control that is driven by
> configuration, will allow properties files to embed version or status
> information and see those reflected via admin or jolokia queries.
> This then provides a nice feedback loop. I am calling it status like MetaData
> status, but also leaving it free form such that any sensible json can be
> embedded once there is coordination.
> Initially the value will just be set like any property.
> Eventually it could provide an entry point for the parser to inform of
> property key=value mismatch or errors on update in some "error" section.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
