<div dir="ltr"><div style>+1 for Carl's patch, and i have abandoned my patch..</div><div style><br></div>About the `MySQL server gone away` problem, I fixed it by set 'pool_recycle' to 1 in db/api.py.<span></span><div>
<br></div><div><br><div>在 2013年9月6日星期五，Nachi Ueno  写道：<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>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>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 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>
>>214.782.7876 direct  |  <a>bcline@softlayer.com</a><br>
>><br>
>><br>
>>-----Original Message-----<br>
>>From: Baldwin, Carl (HPCS Neutron) [mailto:<a>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 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>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>OpenStack-dev@lists.openstack.org</a><br>
</blockquote></div></div>
</div>