> still busy doing some gump profiling. I'm seeing this: I really appreciate that -- thank you!
> > [EMAIL PROTECTED]:/root# ps aux | grep gump | grep -v tomcat > gump 23233 0.0 0.0 8568 1692 ? S Jun25 0:57 > /usr/bin/python2.3 /usr/bin/pydoc -p 1243 Ok, the Python Documentation. A beautiful thing. > root 12593 0.0 0.0 4928 744 ? S Jun29 0:00 sshd: > gumpus d > gump 8881 0.0 0.0 2268 1016 ? Ss 00:00 0:00 /bin/sh > -c cd /usr/local/gump/public/gump; /bin/bash gumpy.sh all --xdocs > gump 8883 0.0 0.0 2268 1060 ? S 00:00 0:00 /bin/bash > gumpy.sh all --xdocs > gump 8886 0.0 0.1 6312 4024 ? S 00:00 0:00 python > gumpy.py all --xdocs > gump 8902 0.0 0.0 2268 1008 ? S 00:00 0:00 sh -c > python gump/integrate.py -w ../brutus.xml all --xdocs >out.txt 2>&1 > gump 8903 38.2 2.1 49492 44504 ? S 00:00 42:19 python > gump/integrate.py -w ../brutus.xml all --xdocs > gump 9054 0.0 2.1 49492 44504 ? S 00:00 0:00 python > gump/integrate.py -w ../brutus.xml all --xdocs > gump 14594 0.1 2.1 49492 44504 ? S 01:49 0:00 python > gump/integrate.py -w ../brutus.xml all --xdocs That out.txt in there looks like a human. So, we have some crons and some humans running gumps, I *think*. Note: gumpy.sh [thin thin thin, to import local-env-py.sh] runs gumpy.py [doing CVS updates and such] which then launches gump/integrate.py (on the updates Python code) so one ought expect 3 processes per gump run. > org.apache.tools.ant.Main > -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml > -Dbuild.sysclasspath=only dom3-gump > gump 14597 0.0 1.7 225692 35500 ? S 01:49 0:00 java > -Djava.awt.headless=true > -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/ xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-a pis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundle d.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-a pis.jar > org.apache.tools.ant.Main > -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml > -Dbuild.sysclasspath=only dom3-gump > root 14777 0.0 0.0 1548 516 pts/1 S+ 01:50 0:00 grep gump > > why does every build command show up as 10 processes? Is that > multithreading at work or somethin'? Nope, it isn't Python multithreading 'cos I turned that off. Hmm, that said -- there is (or was with Python 2.2) a separate process showing up when I started a timer to try to capture/kill errant builds. I think that went away w/ Python 2.3. Either this is just the DOM3 test working, or they are hanging & not being killed. I'd have to look closer to really tell, but first I figure I'll ask... Stefan, can you tell us about these tests (if you know details). Do you know if they multi-thread -- or multi-process or something? Are they long lived. Do you think they could hang? BTW: We aren't using 'timeout' (that C program wrapper that more completely times things out). Even though the OS complains it isn't thread safe (especially on multi-CPU machine, I think.) I suspect we ought find it, compile it, and install it. http://brutus.apache.org/gump/public/environment.html#Tail+of+CheckEnvironment+%3A+check_timeout regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
