----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25490/#review52815 -----------------------------------------------------------
Ship it! Ship It! - Sid Wagle On Sept. 10, 2014, 3:15 a.m., Jonathan Hurley wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/25490/ > ----------------------------------------------------------- > > (Updated Sept. 10, 2014, 3:15 a.m.) > > > Review request for Ambari, Sid Wagle and Yusaku Sako. > > > Bugs: AMBARI-7221 > https://issues.apache.org/jira/browse/AMBARI-7221 > > > Repository: ambari > > > Description > ------- > > There is a memory leak for Jetty HashedSession instances created by Spring > Security for requests to the REST endpoints that do not use AMBARISESSIONID > to manage credentials. The web client does not see this memory leak since > they use AMBARISESSIONID and Spring recognizes this token and re-uses an > existing session instance. > > However, pure stateless REST requests will create a brand new session for > each request. These sessions are never cleaned up by the HashSessionManager. > > The best solution here is to have Spring only create a session when > AMBARISESSIONID is used, but there's no way to know that since an initial > request is not required to contain a random ID. Setting the inactive timeout > value for sessions alleviates the problem. Although sessions are created for > pure stateless REST calls, they are reaped correctly. > > > Diffs > ----- > > ambari-server/conf/unix/ambari.properties > b77ae320507aa5fd0a8b86bcf59841841bdf5690 > > ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java > a21f98c59d68346f4f8878ee813299049b399e61 > > ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariServer.java > fc74e000b9b189ae7623712db05872efa10a540c > > Diff: https://reviews.apache.org/r/25490/diff/ > > > Testing > ------- > > Measured JVM heap usage with jconsole with REST endpoints under stress > testing in addition to normal web client stress. The heap climbed slowly for > new sessions but as sessions became invalidated, they were moved to > WeakReferences and then eventually garbage collected. > > [INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0 > approved: 35 licence. > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] Ambari Main ........................................ SUCCESS [ 3.665 > s] > [INFO] Apache Ambari Project POM .......................... SUCCESS [ 0.325 > s] > [INFO] Ambari Web ......................................... SUCCESS [ 24.192 > s] > [INFO] Ambari Views ....................................... SUCCESS [ 1.700 > s] > [INFO] Ambari Admin View .................................. SUCCESS [ 9.078 > s] > [INFO] Ambari Server ...................................... SUCCESS [16:58 > min] > [INFO] Ambari Agent ....................................... SUCCESS [ 7.617 > s] > [INFO] Ambari Client ...................................... SUCCESS [ 0.031 > s] > [INFO] Ambari Python Client ............................... SUCCESS [ 0.368 > s] > [INFO] Ambari Groovy Client ............................... SUCCESS [ 9.322 > s] > [INFO] Ambari Shell ....................................... SUCCESS [ 0.032 > s] > [INFO] Ambari Python Shell ................................ SUCCESS [ 0.040 > s] > [INFO] Ambari Groovy Shell ................................ SUCCESS [ 5.153 > s] > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 18:00 min > [INFO] Finished at: 2014-09-09T22:43:56-04:00 > [INFO] Final Memory: 44M/236M > [INFO] > ------------------------------------------------------------------------ > > > Thanks, > > Jonathan Hurley > >
