Hi @andreas ,   The jira is internally to Cloudera so you can raise a question in community to ask for an update.   Thanks, Li ... View more

Hi @Hail2Ichi ,   Hue does not close the connection to Impala until the results page is clicked on. Clicking the results page in Hue executes the fetchresults call to Impala.   Since Impala queries are client driven ( for example, until client calls fetch to complete fetching entire result set), the query still remains in a running state. And when a query has not been closed/unregistered, Impala shows it in the In Flight section in its web UI. Cloudera Manager shows all In Flight queries as Executing.   To mitigate this problem, we need to ask Impala to kill any idle sessions if not used, so that resources will be released. In order to do this, we need to set the timeout value for the idle sessions. When a session ends, all its sessions are closed. Follow below steps:   From Cloudera Manager UI, navigate to Impala > Configuration > Service-Wide > Advanced > Impala Command Line Argument Advanced Configuration Snippet (Safety Valve). Set session timeout parameter (value is in seconds).  --idle_session_timeout=<the maximum lifetime of your queries> Note: How long to timeout the session will depend on end users' usage. Ideally to be at least 1-2 hours so that Hue user does not have to keep refreshing the Impala Editor page. Example:  --idle_session_timeout=3600 We also document above in more detail in below knowledge article: Finished Queries show as Executing in the Cloudera Manager Impala Queries Page: https://my.cloudera.com/knowledge/Finished-Queries-show-as-Executing-in-the-Cloudera-Manager?id=71576   Thanks and hope this helps, Li ... View more

Hi @Reavidence ,   Can you please confirm that httpfs is up and running? Please check the log to confirm that it is running fine. The default log location is: var/log/hadoop-httpfs/hadoop-cmf-<hdfs-service-name>-HTTPFS-gateway1.rev.com.log.out   Maybe also try to restart httpfs and see if that helps.   Thanks, Li ... View more

Hi @Cloudman ,   Thanks for your detail explaination. I have checked with expert in house and it looks like this could be a API limitation/design? Basically the /commands/ for the replication doesn't expose info for the sub-commands in the API.    For example, If you run an HDFS replication you'd see the parent command=id = "969" and for each child command_id = parent. But for restarting a service you'd get a parent and child commands.   # For example replication http://cm-host:7180/api/v19/commands/969/ { "id": 969, "name": "HdfsReplicationCommand", "startTime": "2019-06-05T22:25:11.248Z", "endTime": "2019-06-05T22:29:58.629Z", "active": false, "success": true, "resultMessage": "HDFS replication command succeeded.", "resultDataUrl": "http://cm-host:7180/cmf/command/969/download", "serviceRef": { "clusterName": "Cluster 1", "serviceName": "hdfs" }, "children": { "items": [ ] <<<<<===== no child, although the child tasks are visible in UI CM> All Recent Commands or replication history. }, "canRetry": false }   # For example restart service http://cm-host:7180/api/v19/commands/950/ { "id": 950, "name": "Restart", "startTime": "2019-05-30T23:02:18.071Z", "endTime": "2019-05-30T23:02:43.880Z", "active": false, "success": true, "resultMessage": "Successfully restarted service.", "serviceRef": { "serviceName": "mgmt" }, "children": { <<<<<<<<========== CHILD COMMANDS "items": [ { "id": 951, <<<<<<<< CHILD COMMANDS "name": "Stop", "startTime": "2019-05-30T23:02:18.072Z", "endTime": "2019-05-30T23:02:20.310Z", "active": false, "success": true, "resultMessage": "Successfully stopped service.", "serviceRef": { "serviceName": "mgmt" } }, { "id": 953, <<<<<<<< CHILD COMMANDS "name": "Start", "startTime": "2019-05-30T23:02:20.319Z", "endTime": "2019-05-30T23:02:43.879Z", "active": false, "success": true, "resultMessage": "Successfully started service.", "serviceRef": { "serviceName": "mgmt" } } ] }, "canRetry": false } I have opened an internal jira #OPSAPS-51023 to see whether we can enhance this in future releases.   Thanks and hope this helps, Li ... View more

Hi @wert_1311 ,   Thanks for posting the logs. As we can see from the JVM pause messages in the log snippet:   5:48:49.569 AM INFO JvmPauseMonitor Detected pause in JVM or host machine (e.g. a stop the world GC, or JVM not scheduled): paused approximately 2448ms: GC pool 'ParNew' had collection(s): count=1 time=0ms, GC pool 'ConcurrentMarkSweep' had collection(s): count=1 time=2534ms   Depends on how big your cluster is, you may need to increase the memory assigned to Service Monitor (SMON) role. Please see the documentation talking about the HMON and SMON memory configuration: https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_storage.html#concept_ixl_hrk_nn   Also, you can think of tuning garbage collection by enabling G1GC for SMON: From Cloudera Manager UI > Cloudera Management Services > Configuration > under SCOPE select “Service Monitor” > under CATEGORY select Advanced > in the "Java Configuration Options for Service Monitor" set the following: -XX:+UseG1GC -XX:-UseConcMarkSweepGC -XX:-UseParNewGC Then restart SMON.   For more information about tuning G1, see the Oracle documentation on tuning garbage collection: https://docs.oracle.com/cd/E40972_01/doc.70/e40973/cnf_jvmgc.htm#autoId0   Thanks and hope this helps, Li ... View more