views:

53

answers:

2

We use Robot Framework for test automation, and our jython test code spawns a java subprocess using subprocess.Popen():

    cmd = "java -jar program.jar"
    process = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
    process.wait()

Java code utilizes a JDBC connection to Oracle database, and the same program needs to be executed several times successively.

Our issue is, that after the java program exits the database connection to Oracle is not closed - and after several executions the tests start to fail because Oracle won't accept more connections.

netstat shows, that the stale TCP connections to Oracle are owned by jython's PID (=parent process).

Why aren't the connections closed when the java program (=subprocess) exits?

+2  A: 

I'm not sure but it's possible that because you're using Jython, the interpreter is given ownership of the connections (and hence they survive until that process dies). Have you tried using process.terminate() after the process.wait()?

Wayne Werner
I would also wonder if the process is not running in the same memory space - i.e. it is a thread and not a completely separate process. That would mean that the connection will not be closed by the OS until the whole memory space is cleaned up - i.e. the entire process dies.
aperkins
I forgot to mention, that we use python 2.5 and it does not have process.terminate()
tputkonen
You may try `del(process)` though I don't know if that will help.
Wayne Werner
+1  A: 

Consider using os.kill (which is used by process.terminate in >= 2.6).

If that doesn't work, given your unusual setup - JVMs invoking JVMs, not usually necessary - you may want to use something like execnet (http://codespeak.net/execnet/) to start a CPython process to control this. CPython has more functionality for accessing host operating system services than what we have provided in Jython. Using execnet is a good way to combine these strengths together.

Jim Baker
When JVM subprocess is executed under Jython, process.pid() returns None. When execnet is used to launch Python-interpreter which in turn executes a second JVM (unnecessary complicated, I know), all sockets still belong to the first JVM. Well, the real problem is that the sockets are not closed in the first place. Using only one JVM would then be the best solution.
tputkonen