Github user ghajos commented on the issue:
https://github.com/apache/storm/pull/2660
@raghavgautam Thanks for the quick reaction!
Unfortunately the newly introduced test passes without #2643, so it does
not test the original issue. Since in this modification both the server
Github user ghajos commented on the issue:
https://github.com/apache/storm/pull/2633
@srdo Can you please take a look at?
---
Github user ghajos commented on the issue:
https://github.com/apache/storm/pull/2643
@raghavgautam I think it is out of scope to test a tcp testing in Storm. Do
you have an idea how to do that?
---
Github user ghajos commented on the issue:
https://github.com/apache/storm/pull/2633
@revans2 @srdo I'm sorry! There is no reason to set both commit frequency
count and commit frequency sec. I hope that this is already addressed in the
last commit.
---
Github user ghajos commented on a diff in the pull request:
https://github.com/apache/storm/pull/2633#discussion_r188606821
--- Diff:
external/storm-hdfs/src/main/java/org/apache/storm/hdfs/spout/HdfsSpout.java ---
@@ -221,14 +221,18 @@ public void nextTuple() {
while
Github user ghajos commented on the issue:
https://github.com/apache/storm/pull/2660
@raghavgautam I completely missed something with my test. Originally
started a tcp server and a tcp client in separate processes and sent KILLTERM
to the client side. The server port stayed
Github user ghajos commented on the issue:
https://github.com/apache/storm/pull/2643
@HeartSaVioR @raghavgautam @arunmahadevan Thank you for the review!
---
Github user ghajos commented on the issue:
https://github.com/apache/storm/pull/2585
@HeartSaVioR @revans2 Thank you for the review!
---
GitHub user ghajos opened a pull request:
https://github.com/apache/storm/pull/2633
STORM-3028 HdfsSpout: handle empty file in case of ackers
There is a problem with all the storm-hdfs junit tests. The test results
may not be valid.
You can merge this pull request into a Git
GitHub user ghajos opened a pull request:
https://github.com/apache/storm/pull/2643
STORM-3039 handle slot ports in TIME_WAIT state
When worker is killed slot port remains in TIME_WAIT state. Since worker
process is killed it is secure to start a new worker process on the same port
Github user ghajos commented on the issue:
https://github.com/apache/storm/pull/2643
@HeartSaVioR Can you please take a look at?
---
Github user ghajos commented on the issue:
https://github.com/apache/storm/pull/2583
Sorry for the late reply!
---
Github user ghajos commented on the issue:
https://github.com/apache/storm/pull/2583
@srdo @HeartSaVioR @revans2 Thank you for the review and the patience!
---
Github user ghajos commented on a diff in the pull request:
https://github.com/apache/storm/pull/2583#discussion_r178527233
--- Diff: storm-client/test/jvm/org/apache/storm/utils/UtilsTest.java ---
@@ -173,4 +176,49 @@ public void
GitHub user ghajos opened a pull request:
https://github.com/apache/storm/pull/2585
STORM-2762 use guava collection where ever it is possible
Searched the code with git grep to find unnecessarily defined collection
functions. I could only find these two.
You can merge this pull
GitHub user ghajos opened a pull request:
https://github.com/apache/storm/pull/2574
STORM-2911 add serialVersionUID to storm-kafka SpoutConfig
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ghajos/storm STORM-2911
GitHub user ghajos opened a pull request:
https://github.com/apache/storm/pull/2583
STORM-2649 More detailed check of config serialization
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ghajos/storm STORM-2649
Alternatively
17 matches
Mail list logo
