[
https://issues.apache.org/jira/browse/AMBARI-13049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14737421#comment-14737421
]
Hadoop QA commented on AMBARI-13049:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12754936/AMBARI-13049.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:red}-1 javac{color:red}. The patch appears to cause the build to
fail.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/3751//console
This message is automatically generated.
> AMS: IOException: maxStamp is smaller than minStamp
> ---------------------------------------------------
>
> Key: AMBARI-13049
> URL: https://issues.apache.org/jira/browse/AMBARI-13049
> Project: Ambari
> Issue Type: Bug
> Components: ambari-metrics
> Affects Versions: 2.1.2
> Reporter: Dmytro Sen
> Assignee: Dmytro Sen
> Priority: Critical
> Fix For: 2.1.2
>
> Attachments: AMBARI-13049.patch
>
>
> AMS responses with exception
> {noformat}
> {
> exception: "RuntimeException"
> message: "java.io.IOException: maxStamp is smaller than minStamp"
> javaClassName: "java.lang.RuntimeException"
> }
> {noformat}
> to the request
> http://ams-host:6188/ws/v1/timeline/metrics?metricNames=cpu_system&appId=HOST&hostname=host1&startTime=1441141200000&endTime=1441142880000
> ambari-metrics-collector.log contains
> {code}
> 20:28:30,860 WARN [2081437567@qtp-24334184-377] GenericExceptionHandler:98
> - INTERNAL_SERVER_ERROR
> java.lang.RuntimeException: java.io.IOException: maxStamp is smaller than
> minStamp
> at org.apache.phoenix.util.ScanUtil.setTimeRange(ScanUtil.java:253)
> at
> org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:188)
> at
> org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:155)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:220)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:211)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:210)
> at
> org.apache.phoenix.jdbc.PhoenixPreparedStatement.executeQuery(PhoenixPreparedStatement.java:183)
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.PhoenixHBaseAccessor.getMetricRecords(PhoenixHBaseAccessor.java:420)
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.metrics.timeline.HBaseTimelineMetricStore.getTimelineMetrics(HBaseTimelineMetricStore.java:154)
> at
> org.apache.hadoop.yarn.server.applicationhistoryservice.webapp.TimelineWebServices.getTimelineMetrics(TimelineWebServices.java:372)
> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> {code}
> 1. AMS should have a check in PhoenixHBaseAccessor.getMetricRecords() if
> maxStamp >= minStamp before running a query
> 2. AMS shouldn't throw an IOException to the response, if the exception
> catched, the response should contain an empty metrics array.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
