Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2442
I have been feeling that many schedulers co-exist today, and some
schedulers occupy config keys which don't contain scheduler name or so to
determine the usage, and so as newly added configuratio
Github user HeartSaVioR commented on a diff in the pull request:
https://github.com/apache/storm/pull/2438#discussion_r154863967
--- Diff:
external/storm-kafka-client/src/main/java/org/apache/storm/kafka/spout/KafkaSpout.java
---
@@ -372,19 +370,23 @@ private void
ackRetriableOff
Github user HeartSaVioR commented on a diff in the pull request:
https://github.com/apache/storm/pull/2438#discussion_r154863797
--- Diff:
external/storm-kafka-client/src/main/java/org/apache/storm/kafka/spout/KafkaSpout.java
---
@@ -242,9 +242,7 @@ public void nextTuple() {
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2438
Sorry I didn't recognize the code has changed. I'll revoke my +1 and take a
look. Sorry about that.
---
Github user asfgit closed the pull request at:
https://github.com/apache/storm/pull/2437
---
Github user srdo commented on a diff in the pull request:
https://github.com/apache/storm/pull/2438#discussion_r154863225
--- Diff:
external/storm-kafka-client/src/main/java/org/apache/storm/kafka/spout/KafkaSpout.java
---
@@ -242,9 +242,7 @@ public void nextTuple() {
Hi devs,
We have been exposing "standalone mode" of Storm SQL which leverages Storm
SQL in a JVM process rather than composing topology and run.
At a start we implemented both standalone and trident modes with same
approach, but while we improved Storm SQL by leveraging more features on
Calcite, w
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2438
@hmcl
I'm still +1 and I think @srdo agreed to make change. Let's merge in.
---
Github user hmcl commented on the issue:
https://github.com/apache/storm/pull/2438
@srdo @HeartSaVioR thanks for the review. Can you please take another look.
Thanks.
---
Github user hmcl commented on the issue:
https://github.com/apache/storm/pull/2409
@ptgoetz I would suggest putting in different patches the that the minor
refactoring around coding style and adding adding Javadoc. Also, can you please
squash the commits once you have the necessary +1
Github user HeartSaVioR commented on a diff in the pull request:
https://github.com/apache/storm/pull/2443#discussion_r154632607
--- Diff:
sql/storm-sql-core/src/jvm/org/apache/storm/sql/planner/streams/rel/StreamsStreamInsertRel.java
---
@@ -27,50 +30,46 @@
import org.apache
Github user HeartSaVioR commented on a diff in the pull request:
https://github.com/apache/storm/pull/2443#discussion_r154631668
--- Diff:
sql/storm-sql-core/src/jvm/org/apache/storm/sql/planner/streams/rel/StreamsStreamInsertRel.java
---
@@ -27,50 +30,46 @@
import org.apache
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2443
While working with Streams API, I feel the needs for Source (typed Spout)
and Sink (typed Sink Bolt) so have been thinking about interfaces/abstract
classes, but due to ACK mechanism and various
GitHub user HeartSaVioR opened a pull request:
https://github.com/apache/storm/pull/2443
ISSUE-2406 [Storm SQL] Change underlying API to Streams API
* This will enable us to provide windowed aggregation, join, etc later.
* Tuple-to-tuple is making more sense than micro-batch in
14 matches
Mail list logo
