Return-Path: X-Original-To: apmail-commons-commits-archive@minotaur.apache.org Delivered-To: apmail-commons-commits-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BC937CF9F for ; Fri, 27 Jul 2012 07:36:39 +0000 (UTC) Received: (qmail 53746 invoked by uid 500); 27 Jul 2012 07:36:39 -0000 Delivered-To: apmail-commons-commits-archive@commons.apache.org Received: (qmail 53618 invoked by uid 500); 27 Jul 2012 07:36:39 -0000 Mailing-List: contact commits-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@commons.apache.org Delivered-To: mailing list commits@commons.apache.org Received: (qmail 53608 invoked by uid 99); 27 Jul 2012 07:36:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jul 2012 07:36:39 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jul 2012 07:36:35 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 42BA723888FD for ; Fri, 27 Jul 2012 07:35:51 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1366301 - in /commons/proper/functor/trunk/src: changes/changes.xml site/xdoc/aggregator.xml Date: Fri, 27 Jul 2012 07:35:51 -0000 To: commits@commons.apache.org From: simonetripodi@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20120727073551.42BA723888FD@eris.apache.org> Author: simonetripodi Date: Fri Jul 27 07:35:50 2012 New Revision: 1366301 URL: http://svn.apache.org/viewvc?rev=1366301&view=rev Log: [FUNCTOR-23] aggregator.xml generates broken JavaDoc links - patch provided by Liviu Tudor Modified: commons/proper/functor/trunk/src/changes/changes.xml commons/proper/functor/trunk/src/site/xdoc/aggregator.xml Modified: commons/proper/functor/trunk/src/changes/changes.xml URL: http://svn.apache.org/viewvc/commons/proper/functor/trunk/src/changes/changes.xml?rev=1366301&r1=1366300&r2=1366301&view=diff ============================================================================== --- commons/proper/functor/trunk/src/changes/changes.xml (original) +++ commons/proper/functor/trunk/src/changes/changes.xml Fri Jul 27 07:35:50 2012 @@ -23,6 +23,9 @@ + + aggregator.xml generates broken JavaDoc links + Generify ComparableComparator. Modified: commons/proper/functor/trunk/src/site/xdoc/aggregator.xml URL: http://svn.apache.org/viewvc/commons/proper/functor/trunk/src/site/xdoc/aggregator.xml?rev=1366301&r1=1366300&r2=1366301&view=diff ============================================================================== --- commons/proper/functor/trunk/src/site/xdoc/aggregator.xml (original) +++ commons/proper/functor/trunk/src/site/xdoc/aggregator.xml Fri Jul 27 07:35:50 2012 @@ -15,6 +15,10 @@ WITHOUT WARRANTIES OR CONDITIONS OF ANY See the License for the specific language governing permissions and limitations under the License. --> + Aggregator @@ -48,7 +52,7 @@ limitations under the License.

The framework allows for any List-based implementation to be plugged in, by - implementing createList(), + implementing createList(), however, there is also an ArrayList-based implementation provided in ArrayListBackedAggregator which can be used out-of-the-box. @@ -57,17 +61,17 @@ limitations under the License. While the store implementation stores the data in a list, the nostore one stores just a single object -- every time data is fed into the Aggregator, the data stored in this object and the data - passed in + passed in are "aggregated" there and then using the supplied formula and the result of this operation is stored back in the object this implementation uses to store data.

This has the implication that unlike the list-backed storage implementation (where the - result of aggregating the data is not known until evaluate() + result of aggregating the data is not known until evaluate() is called), with the nostore implementation the result is known (and saved back) at any moment. This arguably makes this class "faster", however this comes at the cost of a - slower add() + slower add() operation, as the aggregation formula is applied. Also, let's remind ourselves that not all formulas can be implemented using the nostore implementation (see above).

@@ -92,9 +96,9 @@ limitations under the License. AbstractTimedAggregator offers support to start a timer internally to do that. The class offers a listener mechanism where classes can register to receive timer notifications (if timer support was configured) and after all listeners have been - notified the aggregator is reset. + notified the aggregator is reset. The result of - evaluate() + evaluate() (the result of aggregating data) is passed in to the listeners. This allows for an object to simply register itself as a timer listener to the aggregator and only react to the timer notifications (e.g. write the result to a file for offline analysis etc) while the @@ -104,7 +108,7 @@ limitations under the License. When the data is being flushed/reset, a TimedAggregatorListener can be registered to receive a notification. The notification is sent after the data is reset. - Prior to resetting the data, evaluate() + Prior to resetting the data, evaluate() is called, and the result of the evaluation is sent to the listener.

@@ -119,7 +123,7 @@ limitations under the License.

  • Using a per-instance timer : by default, when using the - 1 + 1 parameter constructor with a value > 0, the aggregator will create a Timer object internally and schedule the regular task of resetting the aggregator under this Timer. While this helps preventing memory leaks @@ -133,18 +137,18 @@ limitations under the License. href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html#MAIN_TIMER">static timer instance which can be shared amongst all instances of this class, if using the + href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html%23AbstractTimedAggregator(long, boolean)">the constructor with 2 params. When doing so, each such instance will schedule its regular reset task against this timer. While this reduces the memory footprint and threading on the system, it can lead to memory leaks if this is not handled correctly. Therefore please make sure you invoke stop() + href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html%23stop()">stop() on such aggregators when finished working with them.

It is recommended you always invoke stop() + href="apidocs/org/apache/commons/functor/aggregator/AbstractTimedAggregator.html%23stop()">stop() at the end of the lifecycle of an aggregator -- regardless of timer support (shared / per instance) or not -- in particular calling stop() on an aggregator with no timer support has no effect, however doing so ensures code uniformity and cleanliness. @@ -268,7 +272,7 @@ public class AggregatorTesting implement

This has the advantage of a lower memory footprint as well (see above). If your healthcheck indicator is based on the maximum transaction time over a 5 seconds interval, then you simply - replace the aggregation + replace the aggregation function with a max value implementation:

@@ -282,10 +286,10 @@ public class AggregatorTesting implement

Or you can simply roll out your own code -- if using the nostore implementation, all you need to do is implement a BinaryFunction and pass - it to the Aggregator + it to the Aggregator constructor. This function will receive the already-stored aggregated value as the first parameter, and data just passed in (via add()) as the + href="apidocs/org/apache/commons/functor/aggregator/Aggregator.html%23add(T)">add()) as the second parameter; the result of this function will be stored back in the aggregator.