----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/52420/#review151049 -----------------------------------------------------------
So we are still slowing down heartbeat status by 5 seconds and two of such commands would still cause queue overload since same aprent thread is whitelisting and blacklisting. Shouldn't we do the del on the hanging command only the next retry on a separate thread not affecting other status commands? ambari-agent/src/main/python/ambari_agent/ActionQueue.py (line 90) <https://reviews.apache.org/r/52420/#comment219170> 5 seconds seems too long since we execute them serially. IMO, 2 seconds should suffice. ambari-agent/src/main/python/ambari_agent/ActionQueue.py (line 243) <https://reviews.apache.org/r/52420/#comment219172> Can you add more comments on what this does and why it is needed? - Sid Wagle On Sept. 30, 2016, 9:24 a.m., Andrew Onischuk wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/52420/ > ----------------------------------------------------------- > > (Updated Sept. 30, 2016, 9:24 a.m.) > > > Review request for Ambari and Dmitro Lisnichenko. > > > Bugs: AMBARI-18505 > https://issues.apache.org/jira/browse/AMBARI-18505 > > > Repository: ambari > > > Description > ------- > > SmartSense status command does an http call without timeout in 1.2 version of > SS. > > Ambari agent queues STATUS commands until we end up with HB lost state with > ton of commands queued up. > > This should just never happen is commands are getting queued by by the agent > every HB. > > > Diffs > ----- > > ambari-agent/conf/unix/ambari-agent.ini 914e09a > ambari-agent/src/main/python/ambari_agent/ActionQueue.py f104939 > ambari-agent/src/main/python/ambari_agent/PythonReflectiveExecutor.py > 655b2fc > > Diff: https://reviews.apache.org/r/52420/diff/ > > > Testing > ------- > > mvn clean test > > > Thanks, > > Andrew Onischuk > >
