You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@edgent.apache.org by dl...@apache.org on 2016/04/20 20:12:02 UTC
[1/3] incubator-quarks-website git commit: [QUARKS-150] add Value
Recipe
Repository: incubator-quarks-website
Updated Branches:
refs/heads/master 70f00190a -> 083536c67
[QUARKS-150] add Value Recipe
Project: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/commit/91e1a19a
Tree: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/tree/91e1a19a
Diff: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/diff/91e1a19a
Branch: refs/heads/master
Commit: 91e1a19afe5e1185e55d196922bd3e42081b1c81
Parents: f73115b
Author: Dale LaBossiere <dl...@us.ibm.com>
Authored: Tue Apr 19 17:43:23 2016 -0400
Committer: Dale LaBossiere <dl...@us.ibm.com>
Committed: Tue Apr 19 17:43:23 2016 -0400
----------------------------------------------------------------------
site/_data/mydoc/mydoc_sidebar.yml | 8 +++
site/recipes/recipe_dynamic_analytic_control.md | 52 ++++++++++++++++++++
2 files changed, 60 insertions(+)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/blob/91e1a19a/site/_data/mydoc/mydoc_sidebar.yml
----------------------------------------------------------------------
diff --git a/site/_data/mydoc/mydoc_sidebar.yml b/site/_data/mydoc/mydoc_sidebar.yml
index 08eea8e..d6bf447 100644
--- a/site/_data/mydoc/mydoc_sidebar.yml
+++ b/site/_data/mydoc/mydoc_sidebar.yml
@@ -138,6 +138,14 @@ entries:
version: all
output: web, pdf
+ - title: Dynamically Enabling Analytic Flows
+ url: /recipes/recipe_dynamic_analytic_control.html
+ audience: writers, designers
+ platform: all
+ product: all
+ version: all
+ output: web, pdf
+
- title: Sample Programs
audience: writers, designers
platform: all
http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/blob/91e1a19a/site/recipes/recipe_dynamic_analytic_control.md
----------------------------------------------------------------------
diff --git a/site/recipes/recipe_dynamic_analytic_control.md b/site/recipes/recipe_dynamic_analytic_control.md
new file mode 100644
index 0000000..7900bc4
--- /dev/null
+++ b/site/recipes/recipe_dynamic_analytic_control.md
@@ -0,0 +1,52 @@
+---
+title: Dynamically Enabling Analytic Flows
+---
+
+This recipe addresses the question: How can I dynamically enable or disable entire portions of my application's analytics?
+
+Imagine a topology that has a variety of analytics that it can perform. Each analytic flow comes with certain costs in terms of demands on the CPU or memory and implications for power consumption. Hence an application may wish to dynamically control whether or not an analytic flow is currently enabled.
+
+## Valve
+
+A ``quarks.topology.plumbing.Valve`` is a simple construct that can be inserted in stream flows to dynamically enable or disable downstream processing. A Valve is used as a Predicate to ``TStream.filter()``. The valve is either OPEN, tuples are accepted, or CLOSED, tuples are rejected, essentially enabling or disabling downstream processing respectively.
+
+For example, consider a a topology consisting of 3 analytic processing flows that want to be dynamically enabled or disabled:
+
+```java
+ Valve<Readings> flow1Valve = new Valve<>(); // default is OPEN
+ Valve<Readings> flow2Valve = new Valve<>(Valve.State.CLOSED);
+ Valve<Readings> flow3Valve = new Valve<>(Valve.State.CLOSED);
+
+ TStream<Readings> readings = topology.poll(mySensor, 1, TimeUnit.SECONDS);
+ addAnalyticFlow1(readings.filter(flow1Valve));
+ addAnalyticFlow2(readings.filter(flow2Valve));
+ addAnalyticFlow3(readings.filter(flow3Valve));
+```
+
+Elsewhere in the application, perhaps as a result of processing some device command from an external service such as when using an IotProvider or IotDevice, valves may be opened and closed dynamically to achieve the desired effects. For example:
+
+```java
+ TStream<JsonObject> cmds = simulatedValveCommands(topology);
+ cmds.sink(json -> {
+ String valveId = json.getPrimitive("valve").getAsString();
+ String stateName = json.getPrimitive("state").getAsString();
+ Valve.State state = Valve.State.valueOf(stateName);
+ switch(valveId) {
+ case "flow1": flow1Valve.setState(state); break;
+ case "flow2": flow2Valve.setState(state); break;
+ case "flow3": flow3Valve.setState(state); break;
+ }
+ });
+```
+
+## Loosely Coupled Quarks Applications
+
+Another approach for achieving dynamic control over what analytics flows are running is to utilize loosely coupled applications. The following is a brief introduction to the topic.
+
+In this approach, the overall application is partitioned into multiple applications (topologies). In the above example there could be four applications: one that publishes the sensor Readings stream, and one for each of the analytic flows.
+
+The separate applications can connect to each other using the ``quarks.connectors.pubsub.PublishSubscribe`` connector.
+
+Rather than having all of the analytic topologies running all of the time, applications can be registered with an ApplicationService. Registered applications can then be started dynamically and a started application, a "job", can be dynamically cancelled.
+
+The Quarks IotProvider packages up all of these services and more in support of this style of use.
\ No newline at end of file
[2/3] incubator-quarks-website git commit: adapt to changes to Valve
Posted by dl...@apache.org.
adapt to changes to Valve
Project: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/commit/ccfd9ed1
Tree: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/tree/ccfd9ed1
Diff: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/diff/ccfd9ed1
Branch: refs/heads/master
Commit: ccfd9ed1957d677119d6143f7b24db6fe0ed390f
Parents: 91e1a19
Author: Dale LaBossiere <dl...@us.ibm.com>
Authored: Wed Apr 20 10:48:07 2016 -0400
Committer: Dale LaBossiere <dl...@us.ibm.com>
Committed: Wed Apr 20 10:48:07 2016 -0400
----------------------------------------------------------------------
site/recipes/recipe_dynamic_analytic_control.md | 25 ++++++++++----------
1 file changed, 12 insertions(+), 13 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/blob/ccfd9ed1/site/recipes/recipe_dynamic_analytic_control.md
----------------------------------------------------------------------
diff --git a/site/recipes/recipe_dynamic_analytic_control.md b/site/recipes/recipe_dynamic_analytic_control.md
index 7900bc4..e345cc6 100644
--- a/site/recipes/recipe_dynamic_analytic_control.md
+++ b/site/recipes/recipe_dynamic_analytic_control.md
@@ -8,14 +8,14 @@ Imagine a topology that has a variety of analytics that it can perform. Each an
## Valve
-A ``quarks.topology.plumbing.Valve`` is a simple construct that can be inserted in stream flows to dynamically enable or disable downstream processing. A Valve is used as a Predicate to ``TStream.filter()``. The valve is either OPEN, tuples are accepted, or CLOSED, tuples are rejected, essentially enabling or disabling downstream processing respectively.
+A ``quarks.topology.plumbing.Valve`` is a simple construct that can be inserted in stream flows to dynamically enable or disable downstream processing. A valve is either open or closed. When used as a Predicate to ``TStream.filter()``, filter passes tuples only when the valve is open. Hence downstream processing is enabled when the valve is open and effectively disabled when the valve is closed.
For example, consider a a topology consisting of 3 analytic processing flows that want to be dynamically enabled or disabled:
```java
- Valve<Readings> flow1Valve = new Valve<>(); // default is OPEN
- Valve<Readings> flow2Valve = new Valve<>(Valve.State.CLOSED);
- Valve<Readings> flow3Valve = new Valve<>(Valve.State.CLOSED);
+ Valve<Readings> flow1Valve = new Valve<>(); // default is open
+ Valve<Readings> flow2Valve = new Valve<>(false); // closed
+ Valve<Readings> flow3Valve = new Valve<>(false);
TStream<Readings> readings = topology.poll(mySensor, 1, TimeUnit.SECONDS);
addAnalyticFlow1(readings.filter(flow1Valve));
@@ -29,24 +29,23 @@ Elsewhere in the application, perhaps as a result of processing some device comm
TStream<JsonObject> cmds = simulatedValveCommands(topology);
cmds.sink(json -> {
String valveId = json.getPrimitive("valve").getAsString();
- String stateName = json.getPrimitive("state").getAsString();
- Valve.State state = Valve.State.valueOf(stateName);
+ boolean isOpen = json.getPrimitive("isOpen").getAsBoolean();
switch(valveId) {
- case "flow1": flow1Valve.setState(state); break;
- case "flow2": flow2Valve.setState(state); break;
- case "flow3": flow3Valve.setState(state); break;
+ case "flow1": flow1Valve.setOpen(isOpen); break;
+ case "flow2": flow2Valve.setOpen(isOpen); break;
+ case "flow3": flow3Valve.setOpen(isOpen); break;
}
});
```
## Loosely Coupled Quarks Applications
-Another approach for achieving dynamic control over what analytics flows are running is to utilize loosely coupled applications. The following is a brief introduction to the topic.
+Another approach for achieving dynamic control over what analytics flows are running is to utilize loosely coupled applications.
In this approach, the overall application is partitioned into multiple applications (topologies). In the above example there could be four applications: one that publishes the sensor Readings stream, and one for each of the analytic flows.
-The separate applications can connect to each other using the ``quarks.connectors.pubsub.PublishSubscribe`` connector.
+The separate applications can connect to each other's streams using the ``quarks.connectors.pubsub.PublishSubscribe`` connector.
-Rather than having all of the analytic topologies running all of the time, applications can be registered with an ApplicationService. Registered applications can then be started dynamically and a started application, a "job", can be dynamically cancelled.
+Rather than having all of the analytic applications running all of the time, applications can be registered with a ``quarks.topology.services.ApplicationService``. Registered applications can then be started and stopped dynamically.
-The Quarks IotProvider packages up all of these services and more in support of this style of use.
\ No newline at end of file
+The ``quarks.providers.iot.IotProvider`` is designed to facilitate this style of use.
\ No newline at end of file
[3/3] incubator-quarks-website git commit: Merge pull request #47
Posted by dl...@apache.org.
Merge pull request #47
This closes #47
Project: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/commit/083536c6
Tree: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/tree/083536c6
Diff: http://git-wip-us.apache.org/repos/asf/incubator-quarks-website/diff/083536c6
Branch: refs/heads/master
Commit: 083536c67446ebd6cd212a7727b166f4c4cd6e90
Parents: 70f0019 ccfd9ed
Author: Dale LaBossiere <dl...@us.ibm.com>
Authored: Wed Apr 20 14:11:43 2016 -0400
Committer: Dale LaBossiere <dl...@us.ibm.com>
Committed: Wed Apr 20 14:11:43 2016 -0400
----------------------------------------------------------------------
site/_data/mydoc/mydoc_sidebar.yml | 8 +++
site/recipes/recipe_dynamic_analytic_control.md | 51 ++++++++++++++++++++
2 files changed, 59 insertions(+)
----------------------------------------------------------------------