Open Stack

>> How is MySQL access handled in eventlet? Presumably it's external C
>> library so it's not going to be monkey patched. Does that make every
>> db access call a blocking call? Thanks,

> Nope, it goes through a thread pool.

I feel like this might be an over-simplification. If the question is:

"How is MySQL access handled in nova?"

The answer would be that we use SQLAlchemy which can load any number of SQL-drivers. These drivers can be either pure Python or C-based drivers. In the case of pure Python drivers, monkey patching can occur and db calls are non-blocking. In the case of drivers which contain C code (or perhaps other blocking calls), db calls will most likely be blocking.

If the question is "How is MySQL access handled in eventlet?" the answer would be to use the eventlet.db_pool module to allow db access using thread pools.

B

-----Original Message-----
From: "Adam Young" <ayoung at redhat.com>
Sent: Thursday, March 1, 2012 3:27pm
To: openstack at lists.launchpad.net
Subject: Re: [Openstack] eventlet weirdness

On 03/01/2012 02:45 PM, Yun Mao wrote:
> There are plenty eventlet discussion recently but I'll stick my
> question to this thread, although it's pretty much a separate
> question. :)
>
> How is MySQL access handled in eventlet? Presumably it's external C
> library so it's not going to be monkey patched. Does that make every
> db access call a blocking call? Thanks,

Nope, it goes through a thread pool.
>
> Yun
>
> On Wed, Feb 29, 2012 at 9:18 PM, Johannes Erdfelt<johannes at erdfelt.com>  wrote:
>> On Wed, Feb 29, 2012, Yun Mao<yunmao at gmail.com>  wrote:
>>> Thanks for the explanation. Let me see if I understand this.
>>>
>>> 1. Eventlet will never have this problem if there is only 1 OS thread
>>> -- let's call it main thread.
>> In fact, that's exactly what Python calls it :)
>>
>>> 2. In Nova, there is only 1 OS thread unless you use xenapi and/or the
>>> virt/firewall driver.
>>> 3. The python logging module uses locks. Because of the monkey patch,
>>> those locks are actually eventlet or "green" locks and may trigger a
>>> green thread context switch.
>>>
>>> Based on 1-3, does it make sense to say that in the other OS threads
>>> (i.e. not main thread), if logging (plus other pure python library
>>> code involving locking) is never used, and we do not run a eventlet
>>> hub at all, we should never see this problem?
>> That should be correct. I'd have to double check all of the monkey
>> patching that eventlet does to make sure there aren't other cases where
>> you may inadvertently use eventlet primitives across real threads.
>>
>> JE
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp