Paramiko / SSHTunnel hang #594
Labels
Comments
|
Thanks, @markfinn. This documentation will tell you which ODPI-C calls may generate a round trip (and therefore should have the GIL released). I'll have this one fixed. I will also put the call to dpiStmt_release() inside the block where the GIL is released -- not because it is necessary but just because the GIL isn't needed anyway! |
|
Thanks! I assume my chances of getting this fixed in a 7.3.x are roughly zero? Some day I'll have the time to get to python 3... Some day. |
|
Hmm, the ODPI-C documentation I referenced suggests that dpiStmt_close() does NOT require a round-trip! That suggests there may be something more in play here. Do you have a sample that demonstrates the problem? As for patching 7.3, yeah, that ship sailed a while ago! Well over 90% of the downloads are now for cx_Oracle 8. It looks like you have made your own patch anyway. Hopefully you can join the Python 3 party relatively soon anyway! ;-) |
|
Now that you say that, I can see it isn't in a round trip, but it is instead waiting on a lock. My guess is that that lock is held by a different thread that IS in a round trip. I hate to say it, but everything that can ever even wait on a non-python-managed lock should probably release the GIL. Boiling down the code to something to reproduce it as a race condition might be really hard but I can reproduce the deadlock in about 3 seconds every time. Are there debug any capabilities that will show what locks are held or waiting by the layers under cx_Oracle? Here are the threads involved. I would guess one of the two in "read" (cxoConnection_init or cxoCursor_execute) is holding a lock that blocks dpiStmt_close(), and that the the read can't complete because SSHTunnel needs the GIL. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm on version 7.3, dealing with an issue similar to #158 that seems to have a similar solution.
When using a pure python ssh tunnel with a cx_oracle pool still hangs for me. Using an external tunnel is fine.
Based on the fix in #158 (releasing the GIL) I checked out what threads where waiting inside the cx_Oracle*.so and think that the call to dpiStmt_close() inside cxoCursor_close() might also need the GIL released while waiting. Doing that seems to fix my hang. I don't really have any understanding of which dpi* functions make external calls, so I don't know if this also should have included the dpiStmt_release() call.
static PyObject *cxoCursor_close(cxoCursor *cursor, PyObject *args) { + int status; if (cxoCursor_isOpen(cursor) < 0) return NULL; Py_CLEAR(cursor->bindVariables); Py_CLEAR(cursor->fetchVariables); if (cursor->handle) { - if (dpiStmt_close(cursor->handle, NULL, 0) < 0) + Py_BEGIN_ALLOW_THREADS + status = dpiStmt_close(cursor->handle, NULL, 0); + Py_END_ALLOW_THREADS + if (status < 0) return cxoError_raiseAndReturnNull(); dpiStmt_release(cursor->handle); cursor->handle = NULL; } cursor->isOpen = 0; Py_RETURN_NONE; }The text was updated successfully, but these errors were encountered: