You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@spark.apache.org by GitBox <gi...@apache.org> on 2019/01/28 22:02:37 UTC

[GitHub] dongjoon-hyun edited a comment on issue #23666: [SPARK-26718][SS] Fixed integer overflow in SS kafka rateLimit calculation

dongjoon-hyun edited a comment on issue #23666: [SPARK-26718][SS] Fixed integer overflow in SS kafka rateLimit calculation 
URL: https://github.com/apache/spark/pull/23666#issuecomment-458318555
 
 
   @linehrr . The PR itself and the test case looks correct. The last concern I have is the UT overhead. This single test case costs us almost 6 minutes (3 mins + 3 mins; it runs twice for DSv1 and DSv2) since it works like a kind of end-to-end integration test. It's a little huge since your test case will survive for a long time. I'm wondering if you can minimize the overhead while achieving the same test coverage?
   
   ```
   [info] - SPARK-26718 Rate limit set to Long.Max should not overflow integer during end offset calculation (2 minutes, 57 seconds)
   ```

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org