yahoo-eng-team team mailing list archive

[Florent Flament <florent.flament-ext@xxxxxxxxxxxxx>]

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