Closed d-w-moore closed 4 months ago
Minimal script to reproduce (on single node running both server & client). confirmed to reproduce issue on main branch commit 71d787fe1f79d81775d892c59f3e9a9f60262c78 (v2.0.1, latest current release as of now):
# before running:
# iadmin mkresc a1 unixfilesystem localhost:/tmp/a1
import irods.keywords as kw
import irods.test.helpers
s = (irods.test.helpers).make_session()
print ('BEFORE -- active = ',len(s.pool.active),'; idle = ',len(s.pool.idle))
with s.data_objects.open('/tempZone/home/rods/abc.dat', 'w',#allow_redirect = False,
**{kw.DEST_RESC_NAME_KW: 'a1'}) as f:
pass
print ('AFTER -- active = ',len(s.pool.active),'; idle = ',len(s.pool.idle))
compare output with and without uncommenting extra allow_redirect = False
parameter in open()
@d-w-moore - Please close if https://github.com/irods/python-irodsclient/pull/563 resolves this issue. Thanks!
consider
open_and_close_lots_of_data_objects_serially.py
:Ideally this opens data objects in serial fashion, writing a few bytes to, and then closing, each handle f implicitly (at the end of the with-block); and in so doing should also leave the data object's associated server connection (an
irods.connection
object) in a reusable disposition by moving it into the session's idle pool . Normal output is as follows:However, in commit d44a47ac026773daa880636caf425e546281a9f0, presently part of https://github.com/d-w-moore/python-irodsclient/tree/ghrunner-nohealthcheck-562.m-FREEZE this is the output we see (This is with the script above running in the python client container , after
run_tests.sh
has setupuser
's client environment) :In both cases above, I'm running with essentially PRC v2.0.0 and a 4.3.1 iRODS server on separate nodes. (In the latter case, where the issue and errors are seen, it's a docker-compose network connecting the two nodes, ie containers).
PRC should , according to a reasonable understanding, be running the same exact instructions, But in the error case, it seems connections are not finding their way back to the idle pool as they should.. They stay in the active category, and do not get re-used for data object "n+1" once data object "n" has been written finalized (ie closed).