> On July 5, 2016, 1:22 p.m., Jonathan Hurley wrote:
> > I don't see how this actually fixes the problem; importing gc from 
> > subprocess would be the same as importing it normally, no? There isn't a 
> > different gc module that subprocess uses. Also, after you patch it, you 
> > then re-import it - wouldn't that break the existing patching?
> 
> Andrew Onischuk wrote:
>     "I don't see how this actually fixes the problem" - this was tested on 
> the instance where I could reproduce this and is a sure fix.
> 
> Jonathan Hurley wrote:
>     So, let's say that it does fix the issue by always reporting that GC is 
> enabled. Wouldn't this then cause side effects since Popen is specifically 
> disabling it for a reason?
> 
> Andrew Onischuk wrote:
>     popen disables gc anyway no matter if it is enabled or not.
> 
> Andrew Onischuk wrote:
>     And even with fix it still disables it. The fix the for the race 
> condition, when it doesn't re-enable it again after the work is done.
> 
> Jonathan Hurley wrote:
>     OK, so `subprocess` doesn't check before it disables it; I can see that. 
> However, we're changing the behavior of a function provided by the gc and we 
> don't know what kinds of issues this could cause on other distributions of 
> Python. There could be other versions which check this function and/or 
> turning on the gc when it's already on could cause a problem.

We support python2.6.* and python2.7.* Both have the same code there. Any other 
python disributions are not suported by us.


- Andrew


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/49535/#review140761
-----------------------------------------------------------


On July 4, 2016, 8:45 a.m., Andrew Onischuk wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/49535/
> -----------------------------------------------------------
> 
> (Updated July 4, 2016, 8:45 a.m.)
> 
> 
> Review request for Ambari and Dmitro Lisnichenko.
> 
> 
> Bugs: AMBARI-17539
>     https://issues.apache.org/jira/browse/AMBARI-17539
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> *Reason of memory leak:*
> Race condition in subprocess python module. 
> Due to this race condition at some unlucky cases python garbage collection 
> was disabled. 
> This usually happened when running alerts, as a bunch of our alerts run shell 
> commands and they do it in a different threads.
> 
> *Fix for the issue:*
> Synchronizing subprocess is not the best option. Since some people can still 
> use it without synchronization not knowing about the issue. 
> Also synchronizing will provide some unnecessary slowdown. So for this issue 
> the proposed fix is to monkey patch subprocess.gc.isenabled.
> 
> 
> Diffs
> -----
> 
>   ambari-agent/src/main/python/ambari_agent/main.py 4db89f8 
> 
> Diff: https://reviews.apache.org/r/49535/diff/
> 
> 
> Testing
> -------
> 
> mvn clean test
> 
> 
> Thanks,
> 
> Andrew Onischuk
> 
>

Reply via email to