irods
Simple client operations under Python 2 may cause iRODS agent error
Tested under PRC 0.7.0 and 0.8.0 ; under Ubuntu 14 and Ubuntu 16.
The agentError.py script below appears to execute correctly under python 2.7, with all desired client requests fulfilled; except that when the python interpreter exits , the rodsLog records an error code -4000, corresponding to SYS_HEADER_READ_LEN_ERR.
Under python 3.x versions, no such error condition occurs.
The error can be reproduced by running the following script
#!/usr/bin/env python
# ////__ agentError.py __////
from os.path import expanduser
from irods.session import iRODSSession
env_file = expanduser('~/.irods/irods_environment.json' )
session = iRODSSession( irods_env_file = env_file )
parentCollName = '/{}/home/{}' .format (session.zone, session.username)
parentCollObject = session.collections.get(parentCollName)
print ("object: {!r}".format(parentCollObject))
print ("path: {!s}".format(parentCollObject.path))
session = None;
1;
# the log doesn't show an error at this point in script execution, so likely
# the iRODS server agent is registering the error during the part of the python2
# interpreter tear-down in which OS resources are closed out.
Below is a sample of the logged error:
Jun 18 15:51:02 pid:4992 remote addresses: 127.0.0.1 ERROR: [-] /tmp/tmpn18jow/server/core/src/rsApiHandler.cpp:540:int readAndProcClientMsg(rsComm_t *, int) : status [SYS_HEADER_READ_LEN_ERR] errno [] -- message [only read [0] of [4]]
[-] /tmp/tmpn18jow/lib/core/src/sockComm.cpp:201:irods::error readMsgHeader(irods::network_object_ptr, msgHeader_t *, struct timeval *) : status [SYS_HEADER_READ_LEN_ERR] errno [] -- message [only read [0] of [4]]
[-] /tmp/tmpn18jow/plugins/network/tcp/libtcp.cpp:194:irods::error tcp_read_msg_header(irods::plugin_context &, void *, struct timeval *) : status [SYS_HEADER_READ_LEN_ERR] errno [] -- message [only read [0] of [4]]
Jun 18 15:51:02 pid:4992 remote addresses: 127.0.0.1 ERROR: Agent [4992] exiting with status = -4000
Jun 18 15:51:02 pid:1466 ERROR: Agent process [4992] exited with status [96]
After some discussion with Hao this afternoon, it seems apparent that iRODSSession instances are meant for quick use -- and then disposal -- in the python "with-object-as-context" idiom:
with iRODSSession( ... ) as session:
# session serves its purpose in this clause, after which
# it and the connection to the server are closed
which leaves me to wonder if an instance of the irods.session.iRODSSession class should ever be used in a Python application to hold a persistent connection to an iRODS server. The prescribed use of the class in the README, and the emergence of this problem, both indicate to me the class wasn't intended to serve such a purpose. Or, perhaps, that the class's designer assumed a python object's destructor __del__ should chain in a call to __exit__ method as part of the destruction process, if doing so served to balance out previous calls to __enter__ which might be chained automatically into the objects's initialization sequence. Is it possible all of this is implicitly so-handled in Python3 ?
At any rate, the solution to the above appears to be this: When used in Python2 in anything but a with clause, an iRODSSession instance should have the cleanup() method called on it before it is about to be disposed.
I figured this out some time back when I wrote the session autocleanup. (This most likely got cleared up in the process. ) Python3 has more thorough garbage collection than Python2. But as we've said, #480 ... it's moot now. Probably best to close this. I can give it a quick bench test, of course.
Under python 3.x versions, no such error condition occurs.
If that's already asserted... and is still true, yes, please close.
Under python 3.x versions, no such error condition occurs.
If that's already asserted... and is still true, yes, please close.
It's not asserted in a test yet ... but should we?
You wrote it above in the initial comment. If it's still true at the bench, I say we close it here.
Python3 does not cause the premature agent deaths under any version I've seen. So, yes, I'll close now.