`pep_api_data_obj_close_post` invoked more than one

[mstfdkmn]

We have a PEP rule that should be triggered by the globus writes in order to implement a policy (extract metadata and attach them to the object with/in a specific schema). What I observe is that pep_api_data_obj_close_post is triggered 2 times when a 3,2 Gb file is transferred to irods. We have a flat resource hierarchy btw.

Looks like related to this. So the close pep is somehow called two times.

[trel]

The original logs in that thread (#84 (comment)) do show two CLOSEs for the same PID... which is surprising.

[mstfdkmn]

Tested this again...I am observing that pep_api_data_obj_close_post is invoked only once for the transfers that are done without checksum enabled. For the transfers with the checksum enabled pep_api_data_obj_close_post is first fired after the data is written/closed in irods and the second time fired when the Globus connection completed (checksum completed). So hypothetically thinking; might it be the case that for checksuming it could be opening/closing the object again?

[alanking]

Ah, good observation. I think your assessment is correct. Checksums are calculated in this project via open/read/close, as seen here:

irods_client_globus_connector/DSI/globus_gridftp_server_iRODS.cpp

Lines 1647 to 1683 in 6be085c

	constexpr unsigned int HASH_BUF_SZ = 1024*1024;
	dataObjInp_t inp_obj{};
	inp_obj.createMode = 0600;
	inp_obj.openFlags = O_RDONLY;
	rstrcpy(inp_obj.objPath, collection, MAX_NAME_LEN);
	int fd = rcDataObjOpen(iRODS_handle->conn, &inp_obj);
	if (fd < 3) {
	status = -1;
	globus_gfs_log_message(GLOBUS_GFS_LOG_INFO,"iRODS: rcDataObjOpen returned invalid file descriptor = %d\n", fd);
	break;
	}
	char buffer_read[HASH_BUF_SZ] = {0};
	openedDataObjInp_t input{};
	input.l1descInx = fd;
	input.len = HASH_BUF_SZ;
	bytesBuf_t output{};
	output.len = input.len;
	output.buf = buffer_read;
	int length_read = 0;
	while ((length_read = rcDataObjRead(iRODS_handle->conn, &input, &output)) > 0) {
	{
	pthread_mutex_lock(&mutex);
	irods::at_scope_exit unlock_mutex{[&mutex] { pthread_mutex_unlock(&mutex); }};
	checksum_bytes_processed += length_read;
	}
	std::string s(static_cast<char*>(output.buf), length_read);
	hasher.update(s);
	}
	rcDataObjClose(iRODS_handle->conn, &input);

Took that snippet from this issue, which is related: #102

Does that fully explain this, then?

[trel]

This explains the additional OPEN as well. Yes?

[alanking]

I think it does, yes. I defer to @JustinKyleJames

[JustinKyleJames]

pep_api_data_obj_close_post

Yes, that would explain it.

[alanking]

Excellent. Should we link this issue in the README update in #107 as well? Feels like it is explained in there.

[trel]

I think so.