Uh oh!
There was an error while loading. Please reload this page.
SPARK-1365 [HOTFIX] Fix RateLimitedOutputStream test - #277
Conversation
rxin
commented
Mar 31, 2014
How about just making sure it has a lower bound of 4? |
AmplabJenkins
commented
Mar 31, 2014
Merged build triggered. Build is starting -or- tests failed to complete. |
AmplabJenkins
commented
Mar 31, 2014
Merged build started. Build is starting -or- tests failed to complete. |
pwendell
commented
Mar 31, 2014
rxin
commented
Mar 31, 2014
rate limiting was about setting an upper bound in throughput, and thus lower bound in time. |
AmplabJenkins
commented
Mar 31, 2014
Merged build finished. Build is starting -or- tests failed to complete. |
AmplabJenkins
commented
Mar 31, 2014
Build is starting -or- tests failed to complete. |
pwendell
commented
Mar 31, 2014
@rxin true, but that's like saying an eventual consistency implementation that never converges is okay. I.e. we want to test that it isn't just a no-op stream that never passes data through. |
pwendell
commented
Mar 31, 2014
@rxin I'll just add a conservative upper bound also to make sure it does eventually get through. |
This test needs to be fixed. It currently depends on Thread.sleep() having exact-timing semantics, which is not a valid assumption.
AmplabJenkins
commented
Mar 31, 2014
Merged build triggered. Build is starting -or- tests failed to complete. |
AmplabJenkins
commented
Mar 31, 2014
Merged build started. Build is starting -or- tests failed to complete. |
AmplabJenkins
commented
Mar 31, 2014
Merged build finished. All automated tests passed. |
AmplabJenkins
commented
Mar 31, 2014
All automated tests passed. |
This test needs to be fixed. It currently depends on Thread.sleep() having exact-timing semantics, which is not a valid assumption. Author: Patrick Wendell <pwendell@gmail.com> Closesapache#277 from pwendell/rate-limited-stream and squashes the following commits: 6c0ff81 [Patrick Wendell] SPARK-1365: Fix RateLimitedOutputStream test
* MapR [SPARK-226] Spark - pySpark Security Vulnerability
This test needs to be fixed. It currently depends on Thread.sleep() having exact-timing
semantics, which is not a valid assumption.