[
https://issues.apache.org/jira/browse/QUARKS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250167#comment-15250167
]
ASF GitHub Bot commented on QUARKS-124:
---------------------------------------
Github user dlaboss commented on a diff in the pull request:
https://github.com/apache/incubator-quarks/pull/91#discussion_r60439481
--- Diff:
analytics/sensors/src/main/java/quarks/analytics/sensors/Deadtime.java ---
@@ -0,0 +1,98 @@
+package quarks.analytics.sensors;
+
+import java.util.Date;
+import java.util.Objects;
+import java.util.concurrent.TimeUnit;
+
+import quarks.function.Predicate;
+
+/**
+ * A generic "deadtime" {@link Predicate}.
+ * <p>
+ * After accepting a tuple ({@link #test(Object) test()} returns true),
+ * any tuples received during the "deadtime" period are rejected
+ * ({@link #test(Object) test()} returns false).
+ * Then the next tuple is accepted and a new deadtime period begun.
+ * </p><p>
+ * The deadtime period may be changed while the topology is running
+ * via {@link #setPeriod(long, TimeUnit)}.
+ * </p>
+ *
+ * @param <T> tuple type
+ */
+public class Deadtime<T> implements Predicate<T> {
+ private static final long serialVersionUID = 1L;
+ private transient long deadtimePeriod;
+ private transient TimeUnit deadtimeUnit;
+ private transient long deadtimePeriodMillis;
+ private transient long lastPassTimeMillis;
+ private transient long nextPassTimeMillis;
+
+ /**
+ * Create a new deadtime Predicate
+ * <p>
+ * Same as {@code Deadtime(0, TimeUnit.SECONDS)}
+ */
+ public Deadtime() {
+ setPeriod(0, TimeUnit.SECONDS);
+ }
+
+ /**
+ * Create a new deadtime Predicate
+ * <p>
+ * The first received tuple is always "accepted".
+ * @param deadtimePeriod see {@link #setPeriod(long, TimeUnit)
setDeadtimePeriod()}
+ * @param unit {@link TimeUnit} of {@code deadtimePeriod}
+ */
+ public Deadtime(long deadtimePeriod, TimeUnit unit) {
+ setPeriod(deadtimePeriod, unit);
+ }
+
+ /**
+ * Set the deadtime period
+ * <p>
+ * The next time to enable a tuple to be accepted is
+ * immediately adjusted relative to the last accepted tuple time.
+ * </p><p>
+ * The deadtime period behavior is subject to the accuracy
+ * of the system's {@link System#currentTimeMillis()}.
+ * </p>
+ * @param deadtimePeriod the amount of to time to reject
+ * tuples received after the last passed tuple.
+ * Specify a value of 0 to pass all received tuples.
+ * Must be >= 0.
+ * A period of 0 is used if the specified period is less than
1ms.
+ * @param unit {@link TimeUnit} of {@code deadtimePeriod}
+ */
+ public synchronized void setPeriod(long deadtimePeriod, TimeUnit unit)
{
+ if (deadtimePeriod < 0)
+ throw new IllegalArgumentException("deadtimePeriod");
+ Objects.requireNonNull(unit, "unit");
--- End diff --
Using requireNonNull with a msg is better for the caller than just
receiving a "naked" NPE a few lines down, right? Using it also enforces the
requirement even if later the code below it doesn't end up referencing ``unit``.
> Add a recipe for changing the rate at which data is published
> -------------------------------------------------------------
>
> Key: QUARKS-124
> URL: https://issues.apache.org/jira/browse/QUARKS-124
> Project: Quarks
> Issue Type: Task
> Components: Documentation
> Reporter: Dale LaBossiere
> Assignee: Dale LaBossiere
>
> e.g., analytics are being continuously performed and new results generated
> say every 1min but under "normal" conditions a "normal" result is only
> published (equivalently an IotDevice event generated) every 30min. Some
> alert condition is detected by local analytics and the application wants to
> start publishing the results every 1min.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
