ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hurley" <jhur...@hortonworks.com>
Subject Review Request 25490: Ambari Server REST API Memory Leak
Date Wed, 10 Sep 2014 03:15:50 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/25490/
-----------------------------------------------------------

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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message