I read again Jamie Lennox's article about Sessions: http://www.jamielennox.net/blog/2014/02/24/client-session-objects/
As well as Python requests module doc: http://docs.python-requests.org/en/latest/user/advanced/ FWIU, keystoneclient.session.Session and requests.Session objetcs are not meant to be shared between different users. Instances of these classes store information related to a single user (for instance a user's token). Therefore, we shouldn't have one unique Session instance shared amongst all users. However, it would make sense to have a global connection pool inside Horizon. Looks like the requests.adapters.HTTPAdapater would be a good candidate for such http connections pool. Well, I think that's also what was saying Dean Troyer there (Feb 19): https://review.openstack.org/#/c/74720/ IMHO, keystoneclient.session.Session cannot be mapped on a user session properly by Horizon, since Horizon doesn't know when a user's session is terminated (unless he explicitly clicks on the logout button), and can't "close" the session. Therefore, with Horizon, we can at best use one keystoneclient.session.Session per request. And this session should be closed (to release the connections used during this session) without relying on the GC, which apparently isn't efficient enough to avoid the current bug. >From the tests I've been doing, I think that most connections leakage come from django_openstack_auth module. python-keystoneclient is used in Horizon too. The api/keystone.py module will need to be fixed too. I've started to implement a connections pool in django_openstack_auth, but it looks that python-keystoneclient doesn't like when Clients are instanciated with an unauthenticated Session object as argument -> Further investigating. ** Also affects: django-openstack-auth Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1282089 Title: keystone client is leaving hanging connections to the server Status in Django OpenStack Auth: New Status in OpenStack Dashboard (Horizon): New Status in Python client library for Keystone: In Progress Bug description: This is remarkable noticeable from Horizon which use keystoneclient to connect to the keystone server and at each request this later is left hanged there which consume the keystone server and at one point this will result to having keystone server process exceeding the limit of connection that is allowed to handle (ulimit of open filed). ## How to check: If you have horizon installed so just keep using it normally (creating instances ....) while keeping an eye on the server number of opened files "lsof -p <keystone-pid>" you can see that the number increment pretty quickly. To reproduce this bug very fast try launching 40 instances at the same time for example using "Instance Count" field. ## Why: This because keystone client doesn't reuse the http connection pool, so in a long running service (e.g. horizon) the effect will be a new connections created for each request no connection reuse. Patch coming soon with more details. To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1282089/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
