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 — 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 [email protected] or file a JIRA ticket
with INFRA.
---
