edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From queeniema <...@git.apache.org>
Subject [GitHub] incubator-quarks-website pull request: [QUARKS-159] Update website...
Date Fri, 29 Apr 2016 20:54:47 GMT
Github user queeniema commented on a diff in the pull request:

    https://github.com/apache/incubator-quarks-website/pull/53#discussion_r61643306
  
    --- Diff: site/recipes/recipe_adaptable_deadtime_filter.md ---
    @@ -4,63 +4,63 @@ title: Using an adaptable deadtime filter
     
     Oftentimes, an application wants to control the frequency that continuously generated
analytic results are made available to other parts of the application or published to other
applications or an event hub.
     
    -For example, an application polls an engine temperature sensor every second and performs
various analytics on each reading - an analytic result is generated every second.  By default,
the application only wants to publish a (healthy) analytic result every 30 minutes.  However,
under certain conditions, the desire is to publish every per-second analytic result.
    +For example, an application polls an engine temperature sensor every second and performs
various analytics on each reading &mdash; an analytic result is generated every second.
By default, the application only wants to publish a (healthy) analytic result every 30 minutes.
However, under certain conditions, the desire is to publish every per-second analytic result.
     
     Such a condition may be locally detected, such as detecting a sudden rise in the engine
temperature or it may be as a result of receiving some external command to change the publishing
frequency.
     
     Note this is a different case than simply changing the polling frequency for the sensor
as doing that would disable local continuous monitoring and analysis of the engine temperature.
     
    -This case needs a *deadtime filter* and Quarks provides one for your use!  In contrast
to a *deadband filter*, which skips tuples based on a deadband value range, a deadtime filter
skips tuples based on a *deadtime period* following a tuple that is allowed to pass through.
 E.g., if the deadtime period is 30 minutes, after allowing a tuple to pass, the filter skips
any tuples received for the next 30 minutes.  The next tuple received after that is allowed
to pass through, and a new deadtime period is begun.
    +This case needs a *deadtime filter* and Quarks provides one for your use! In contrast
to a *deadband filter*, which skips tuples based on a deadband value range, a deadtime filter
skips tuples based on a *deadtime period* following a tuple that is allowed to pass through.
For example, if the deadtime period is 30 minutes, after allowing a tuple to pass, the filter
skips any tuples received for the next 30 minutes. The next tuple received after that is allowed
to pass through, and a new deadtime period is begun.
     
    -See ``quarks.analytics.sensors.Filters.deadtime()`` and ``quarks.analytics.sensors.Deadtime``.
    +See `quarks.analytics.sensors.Filters.deadtime()` (on [GitHub](https://github.com/apache/incubator-quarks/blob/master/analytics/sensors/src/main/java/quarks/analytics/sensors/Filters.java))
and `quarks.analytics.sensors.Deadtime` (on [GitHub](https://github.com/apache/incubator-quarks/blob/master/analytics/sensors/src/main/java/quarks/analytics/sensors/Deadtime.java)).
    --- End diff --
    
    Yes, once the Javadoc is updated, then we should update these types of links to point
to there. In the meantime, I figured that pointing to the source code might be helpful.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message