[
https://issues.apache.org/jira/browse/HBASE-19715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321720#comment-16321720
]
Chia-Ping Tsai commented on HBASE-19715:
----------------------------------------
bq. It just feels like it was bad design to use an exception object (with
class name, message, stack trace, and so much byte/char copying) to return all
kinds of non-Result status of the request. A simple boolean flag would have
been better.
The class name of exception is necessary since the client may take different
follow-up for different exception. For example, DoNotRetryIOException. The
message and stack trace are useful information to debug. Hence, I'm having
doubts about whether we can replace the exception object by a simple boolean
flag.
> Fix timing out test TestMultiRespectsLimits
> -------------------------------------------
>
> Key: HBASE-19715
> URL: https://issues.apache.org/jira/browse/HBASE-19715
> Project: HBase
> Issue Type: Bug
> Reporter: Appy
> Assignee: Appy
> Attachments: HBASE-19715.test.patch, HBASE-19715.test.v2.patch,
> failued.txt, passed.txt, screenshot-1.png, screenshot-2.png,
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> !screenshot-1.png|width=800px!
> Attached logs for both cases, when it passes and fails.
> Link (temporary) to logs:
> passed:
> http://104.198.223.121:8080/job/HBase-Flaky-Tests/33449/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMultiRespectsLimits-output.txt/*view*/
> failed:
> http://104.198.223.121:8080/job/HBase-Flaky-Tests/33455/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMultiRespectsLimits-output.txt/*view*/
> Correlating across more runs, whenever the tests passes, it does so within
> 10-30sec of 3min deadline for medium tests.
> So i think we can make it pass by just increasing the timeout.
> But I'm a bit skeptical after seeing all those long GC pauses (10sec +) in
> the log. Test code doesn't seem to be doing anything that intensive. Are we
> mismanaging the memory somewhere?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
