edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QUARKS-124) Add a recipe for changing the rate at which data is published
Date Wed, 20 Apr 2016 16:14:25 GMT

    [ 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)

Mime
View raw message