<div dir="ltr"><div><div><div><div>Carl, Yingjun,<br><br></div>I'm still getting the 2006 error even by configuring idle_interval to 1.<br><br></div>I applied the patch to the RDO havana dist on centos 6.4.<br><br></div>
Are there any other options I should be considering such as min/max pool size or use_tpool?<br><br></div>Thanks.<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 7, 2013 at 3:33 AM, Baldwin, Carl (HPCS Neutron) <span dir="ltr"><<a href="mailto:carl.baldwin@hp.com" target="_blank">carl.baldwin@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This pool_recycle parameter is already configurable using the idle_timeout<br>
configuration variable in neutron.conf.  I tested this with a value of 1<br>
as suggested and it did get rid of the mysql server gone away messages.<br>
<br>
This is a great clue but I think I would like a long-term solution that<br>
allows the end-user to still configure this like they were before.<br>
<br>
I'm currently thinking along the lines of calling something like<br>
pool.dispose() in each child immediately after it is spawned.  I think<br>
this should invalidate all of the existing connections so that when a<br>
connection is checked out of the pool a new one will be created fresh.<br>
<br>
Thoughts?  I'll be testing.  Hopefully, I'll have a fixed patch up soon.<br>
<br>
Cheers,<br>
<div class="im">Carl<br>
<br>
From:  Yingjun Li <<a href="mailto:liyingjun1988@gmail.com">liyingjun1988@gmail.com</a>><br>
Reply-To:  OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Date:  Thursday, September 5, 2013 8:28 PM<br>
To:  OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
</div>Subject:  Re: [openstack-dev] [Neutron] The three API server multi-worker<br>
<div class="HOEnZb"><div class="h5">process patches.<br>
<br>
<br>
+1 for Carl's patch, and i have abandoned my patch..<br>
<br>
About the `MySQL server gone away` problem, I fixed it by set<br>
'pool_recycle' to 1 in db/api.py.<br>
<br>
在 2013年9月6日星期五，Nachi Ueno 写道：<br>
<br>
Hi Folks<br>
<br>
We choose <a href="https://review.openstack.org/#/c/37131/" target="_blank">https://review.openstack.org/#/c/37131/</a> <-- This patch to go on.<br>
We are also discussing in this patch.<br>
<br>
Best<br>
Nachi<br>
<br>
<br>
<br>
2013/9/5 Baldwin, Carl (HPCS Neutron) <<a href="mailto:carl.baldwin@hp.com">carl.baldwin@hp.com</a>>:<br>
> Brian,<br>
><br>
> As far as I know, no consensus was reached.<br>
><br>
> A problem was discovered that happens when spawning multiple processes.<br>
> The mysql connection seems to "go away" after between 10-60 seconds in my<br>
> testing causing a seemingly random API call to fail.  After that, it is<br>
> okay.  This must be due to some interaction between forking the process<br>
> and the mysql connection pool.  This needs to be solved but I haven't had<br>
> the time to look in to it this week.<br>
><br>
> I'm not sure if the other proposal suffers from this problem.<br>
><br>
> Carl<br>
><br>
> On 9/4/13 3:34 PM, "Brian Cline" <<a href="mailto:bcline@softlayer.com">bcline@softlayer.com</a>> wrote:<br>
><br>
>>Was any consensus on this ever reached? It appears both reviews are still<br>
>>open. I'm partial to review 37131 as it attacks the problem a more<br>
>>concisely, and, as mentioned, combined the efforts of the two more<br>
>>effective patches. I would echo Carl's sentiments that it's an easy<br>
>>review minus the few minor behaviors discussed on the review thread<br>
>>today.<br>
>><br>
>>We feel very strongly about these making it into Havana -- being confined<br>
>>to a single neutron-server instance per cluster or region is a huge<br>
>>bottleneck--essentially the only controller process with massive CPU<br>
>>churn in environments with constant instance churn, or sudden large<br>
>>batches of new instance requests.<br>
>><br>
>>In Grizzly, this behavior caused addresses not to be issued to some<br>
>>instances during boot, due to quantum-server thinking the DHCP agents<br>
>>timed out and were no longer available, when in reality they were just<br>
>>backlogged (waiting on quantum-server, it seemed).<br>
>><br>
>>Is it realistically looking like this patch will be cut for h3?<br>
>><br>
>>--<br>
>>Brian Cline<br>
>>Software Engineer III, Product Innovation<br>
>><br>
>>SoftLayer, an IBM Company<br>
>>4849 Alpha Rd, Dallas, TX 75244<br>
>><a href="tel:214.782.7876" value="+12147827876">214.782.7876</a> direct  |  <a href="mailto:bcline@softlayer.com">bcline@softlayer.com</a><br>
>><br>
>><br>
>>-----Original Message-----<br>
>>From: Baldwin, Carl (HPCS Neutron) [mailto:<a href="mailto:carl.baldwin@hp.com">carl.baldwin@hp.com</a>]<br>
>>Sent: Wednesday, August 28, 2013 3:04 PM<br>
>>To: Mark McClain<br>
>>Cc: OpenStack Development Mailing List<br>
>>Subject: [openstack-dev] [Neutron] The three API server multi-worker<br>
>>process patches.<br>
>><br>
>>All,<br>
>><br>
>>We've known for a while now that some duplication of work happened with<br>
>>respect to adding multiple worker processes to the neutron-server.  There<br>
>>were a few mistakes made which led to three patches being done<br>
>>independently of each other.<br>
>><br>
>>Can we settle on one and accept it?<br>
>><br>
>>I have changed my patch at the suggestion of one of the other 2 authors,<br>
>>Peter Feiner, in attempt to find common ground.  It now uses openstack<br>
>>common code and therefore it is more concise than any of the original<br>
>>three and should be pretty easy to review.  I'll admit to some bias<br>
>>toward<br>
>>my own implementation but most importantly, I would like for one of these<br>
>>implementations to land and start seeing broad usage in the community<br>
>>earlier than later.<br>
>><br>
>>Carl Baldwin<br>
>><br>
>>PS Here are the two remaining patches.  The third has been abandoned.<br>
>><br>
>><a href="https://review.openstack.org/#/c/37131/" target="_blank">https://review.openstack.org/#/c/37131/</a><br>
>><a href="https://review.openstack.org/#/c/36487/" target="_blank">https://review.openstack.org/#/c/36487/</a><br>
>><br>
>><br>
>>_______________________________________________<br>
>>OpenStack-dev mailing list<br>
>><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div><b>Intel SSG/STO/DCST/CIT</b></div>
<div>880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, 
China<br></div>
<div>+862161166500</div></div>
</div>