blueprint dependency graph rendering should not run graphviz as a subprocess

[Curtis Hovey]

The renderGraphvizGraph() method should use python bindings to create the
image map and PNG images. The subprocess.Popen approach used is
susceptible to OSErrors as seen in bug 208228.

[Curtis Hovey (sinzui)]

I'm setting this importance to low because I don't think there are
good options for binding at this time. I am implementing a work-around
for the OSErrors.

[James Henstridge (jamesh)]

If the app server can't allocate memory to fork a process, then something is very wrong with the app server. Once we've identified and fixed the memory leak, if we still see the that OOPS then it might be worth considering this.

Bringing things like this in process has the risk of introducing memory leaks or crashes into the app server (see the problems with the lxml dependency of hwdb, for instance), so it isn't always obvious that in process is better.

[Curtis Hovey (sinzui)]

On Fri, 2008-04-04 at 02:26 +0000, James Henstridge wrote:
> Bringing things like this in process has the risk of introducing memory
> leaks or crashes into the app server (see the problems with the lxml
> dependency of hwdb, for instance), so it isn't always obvious that in
> process is better.

Good argument.

--

__C U R T I S C. H O V E Y_______
Guilty of stealing everything I am.

[Robert Collins (lifeless)]

An alternative is a graph *rendering* service which can be isolated (making it easier to detect memory leaks) and load balanced (so that if it leaks only one very specific backend will be interrupted).