[
https://issues.apache.org/jira/browse/QPID-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199159#comment-16199159
]
Keith Wall commented on QPID-7799:
----------------------------------
Hi Alex
Thanks for the feedback.
The implementation (notedly the decision to drive from a context variables) was
driven by two of the requirements stated in the JIRA description above:
# the ability to produce statistics for either all objects of a *given
category* or a *single object instance*. The target object might be ephemeral
(i.e. non-durable). The use cases I have in mind are, say, the ability to
turn on logging for a single existing connection (non-durable), or a single
queue (durable or non) for diagnostic purposes, without turning on logging for
all connections or all queues.
# the ability to enable/disable/reconfigure statistics logging at runtime,
without restarting the Broker or Virtualhosts.
I assume your idea is to have a {{statisticLogging}} attribute on Broker and
Virtualhost with structured content specifying what statistics need to be
logged for their pat of the tree. This doesn't work well for ephemerals object
like connections or non-durable queues. It would be weird to record references
to ephemeral objects in the attribute. What would be responsible for
cleaning up the dangling references? It was this problem that drove me to
the context variables based implementation.
I did consider exposing the object's statisticsReportPattern as a attribute on
the object itself. However, the need to turn on statistics logging for, say all
queues,. would mean the attribute would have needed special behaviour and be
unlike other attributes. For instance, say I wanted to turn on statistics
logging for all queues. How would the existing queues get the new
configuration? This would require special casing so is unappealing.
>...segregated formatting...
I suppose this is a matter of taste. I wanted the user to be in control of the
log format string so they could make it as verbose or terse as they like and
chose between raw values or human readable strings.
> StatisticsReportingTask looks for the settings in the context every time
The alternative is to somehow listen to the entire tree for context variable
changes and update local reference. I think that statistic reporting period
will be typically be minutes. I don't think the cost of the context variable
access is a concern.
> Statistics logging requires pre-created logging rule for logger
> qpid.statistics.*"
I think automatically adding and removing a rule would be surprising to the
user.
> Additionally, the implementation only allows to enable reporting per category
> basis.
No, that is not correct. See test
org.apache.qpid.server.stats.StatisticsReportingTest#testVirtualHostStatistics
which illustrates turning the stats reporting on for an existing object.
> I am not sure about replacing StatisticsCounter with AtomicLongs as that
> might create a problem with updating statistics from multiple threads
Why would there be threading concerns? We are currently only using
StatisticsCounter for its ability to count deliveries/bytes etc. Underneath, it
is calculating peak and rates, but we never expose this information. I think
we need these features, so it looks to me like StatisticsCounter could be
mechanically swapped for a AtomicLong.
> Broker should be able to write a periodic dump of statistics
> ------------------------------------------------------------
>
> Key: QPID-7799
> URL: https://issues.apache.org/jira/browse/QPID-7799
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7799-Java-Broker-Improve-statistics-reporting.patch
>
>
> To assist those running a service, the Broker should have the ability to
> write a periodic dump of ConiguredObject statistics to the log file. It
> should be possible to configure the statistics dumped at runtime and be
> configured on a per-category or per-object instance basis. Within a HA
> group, the configuration applied to objects belonging to a virtualhost must
> survive a mastership change.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
