[
https://issues.apache.org/jira/browse/QUARKS-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267346#comment-15267346
]
ASF GitHub Bot commented on QUARKS-159:
---------------------------------------
Github user dlaboss commented on a diff in the pull request:
https://github.com/apache/incubator-quarks-website/pull/53#discussion_r61791053
--- 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)).
This recipe demonstrates how to use an adaptable deadtime filter.
-A Quarks ``IotProvider`` and ``IoTDevice`` with its command streams would
be a natural way to control the application. In this recipe we will just
simulate a "set deadtime period" command stream.
+A Quarks `IotProvider` ad `IoTDevice` with its command streams would be a
natural way to control the application. In this recipe we will just simulate a
"set deadtime period" command stream.
## Create a polled sensor readings stream
```java
- Topology top = ...;
- SimulatedTemperatureSensor tempSensor = new
SimulatedTemperatureSensor();
- TStream<Double> engineTemp = top.poll(tempSensor, 1,
TimeUnit.SECONDS)
- .tag("engineTemp");
+Topology top = ...;
+SimulatedTemperatureSensor tempSensor = new SimulatedTemperatureSensor();
+TStream<Double> engineTemp = top.poll(tempSensor, 1, TimeUnit.SECONDS)
+ .tag("engineTemp");
```
It's also a good practice to add tags to streams to improve the usability
of the development mode Quarks console.
-## Create a deadtime filtered stream - initially no deadtime
+## Create a deadtime filtered stream—initially no deadtime
-In this recipe we'll just filter the direct ``engineTemp`` sensor reading
stream. In practice this filtering would be performed after some analytics
stages and used as the input to ``IotDevice.event()`` or some other connector
publish operation.
+In this recipe we'll just filter the direct ``engineTemp`` sensor reading
stream. In practice this filtering would be performed after some analytics
stages and used as the input to ``IotDevice.event()`` or some other connector
publish operation.
```java
- Deadtime<Double> deadtime = new Deadtime<>();
- TStream<Double> deadtimeFilteredEngineTemp =
engineTemp.filter(deadtime)
- .tag("deadtimeFilteredEngineTemp");
+Deadtime<Double> deadtime = new Deadtime<>();
+TStream<Double> deadtimeFilteredEngineTemp = engineTemp.filter(deadtime)
+ .tag("deadtimeFilteredEngineTemp");
```
## Define a "set deadtime period" method
```java
- static <T> void setDeadtimePeriod(Deadtime<T> deadtime, long period,
TimeUnit unit) {
- System.out.println("Setting deadtime period="+period+" "+unit);
- deadtime.setPeriod(period, unit);
- }
+static <T> void setDeadtimePeriod(Deadtime<T> deadtime, long period,
TimeUnit unit) {
+ System.out.println("Setting deadtime period="+period+" "+unit);
+ deadtime.setPeriod(period, unit);
+}
```
## Process the "set deadtime period" command stream
-Our commands are on the ``TStream<JsonObject> cmds`` stream. Each
``JsonObject`` tuple is a command with the properties "period" and "unit".
+Our commands are on the ``TStream<JsonObject> cmds`` stream. Each
``JsonObject`` tuple is a command with the properties "period" and "unit".
```java
- cmds.sink(json -> setDeadtimePeriod(deadtimeFilteredEngineTemp,
- json.getAsJsonPrimitive("period").getAsLong(),
-
TimeUnit.valueOf(json.getAsJsonPrimitive("unit").getAsString())));
+cmds.sink(json -> setDeadtimePeriod(deadtimeFilteredEngineTemp,
+ json.getAsJsonPrimitive("period").getAsLong(),
+ TimeUnit.valueOf(json.getAsJsonPrimitive("unit").getAsString())));
```
## The final application
-When the application is run it will initially print out temperature sensor
readings every second for 15 seconds - the deadtime period is 0. Then every 15
seconds the application will toggle the deadtime period between 5 seconds and 0
seconds, resulting in a reduction in tuples being printed during the 5 second
deadtime period.
+When the application is run it will initially print out temperature sensor
readings every second for 15 seconds—the deadtime period is 0. `Then
every 15 seconds the application will toggle the deadtime period between 5
seconds and 0 seconds, resulting in a reduction in tuples being printed during
the 5 second deadtime period.
--- End diff --
I made the adjustment when merging
> Update website to follow style guide
> ------------------------------------
>
> Key: QUARKS-159
> URL: https://issues.apache.org/jira/browse/QUARKS-159
> Project: Quarks
> Issue Type: Improvement
> Components: Documentation, Web Site
> Reporter: Queenie Ma
> Assignee: Queenie Ma
>
> The style guide is located in
> [README.md|https://github.com/apache/incubator-quarks-website/blob/master/README.md].
> See QUARKS-153.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
