INT-3752: Add AggregatingMetricsFactory

JIRA: https://jira.spring.io/browse/INT-3752
JIRA: https://jira.spring.io/browse/INT-3754

The statistics are based on this count so, for example the
`meanSendDuration` reflects the mean of total duration from the first send to
the last in each batch.

Also change the linked lists to `Deque`s.

Also remove `isTraceEnabled()` calls - too expensive in high volume environments.

Polishing

Assign the count to a local variable so the mod (%) operation is short
circuited rather than short circuiting the call to isFullStatsEnabled().

INT-3752: Fix Aggregating Metrics

Previously, the duration was for the first message in each sample.

We need to capture the total elapsed time for the sample and use it
for the duration calculation.

Add 'newCount' to the context so the after... method can calculate
the duration at the end of the sample.

The start field does not need to be volatile because its updates
are synchronized.

INT-3752: Fix Javadocs
This commit is contained in:
Gary Russell
2015-06-26 15:13:34 -04:00
committed by Artem Bilan
parent 5298368168
commit a480354210
14 changed files with 472 additions and 61 deletions

View File

@@ -509,6 +509,29 @@ By default, a `DefaultMetricsFactory` provides default implementation of `Messag
To override the default `MetricsFactory` use the MBean exporter's `metrics-factory` attribute to provide a reference to your `MetricsFactory` bean instance.
You can either customize the default implementations as described in the next bullet, or provide completely different implementations by overriding `AbstractMessageChannelMetrics` and/or `AbstractMessageHandlerMetrics`.
In addition to the default metrics factory described above, the framework provides the `AggregatingMetricsFactory`.
This factory creates `AggregatingMessageChannelMetrics` and `AggregatingMessageHandlerMetrics`.
In very high volume scenarios, the cost of capturing statistics can be prohibitive (2 calls to the system time and
storing the data).
The aggregating metrics aggregate the response time over a sample of messages.
This can save significant CPU time.
CAUTION: The statistics will be skewed if messages arrive in bursts.
These metrics are intended for use with high, constant-volume, message rates.
[source, xml]
----
<context:mbean-server />
<int-jmx:mbean-export metrics-factory="aggregatingMetricsFactory" />
<bean id="aggregatingMetricsFactory" class="org.springframework.integration.monitor.AggregatingMetricsFactory">
<constructor-arg value="1000" /> <!-- sample size -->
</bean>
----
The above configuration aggregates the response time over 1000 messages.
Counts (send, error) are maintained per-message but the statistics are per 1000 messages.
* *Customizing the Default Channel/Handler Statistics*