Transferring an object to/in iRODS throws `-808000` and `-358000` about irods_client_globus_connector

[korydraughn]

Yes, we'll put eyes on it.

[mstfdkmn]

Yes. But what I dont understand is something else I guess: that is, I do still see the same errors for some transfers that I didn't initiate and I am guessing these are old transfers. If I know more, I will let you know.

[alanking]

I don't know anything about Globus, but I'll add that the error message appearing in the log is coming from these lines:
https://github.com/irods/irods/blob/f6eb6c72786288878706e2562a370b91b7d0802e/server/api/src/rsDataObjOpen.cpp#L767-L783

Something happened when attempting to resolve a resource hierarchy for the given operation. It seems like the Globus connector may not be using the right open flags or something for certain situations. Probably warrants investigation.

[mstfdkmn]

Hi @JustinKyleJames, would it be possible to prioritize this? Because we do a lot of transfers to irods via the connector and due to this hard to see a clean irods log - (any file transfer to irods throws that error). Thanks.

[JustinKyleJames]

I have no been able to reproduce this problem using globus-url-copy nor with ftp. However, I think I know the root of the problem.

When the plugin's globus_l_gfs_iRODS_recv method gets called the open flag is first set to O_WRONLY. Then if the truncate option is set the flags for O_CREAT and O_TRUNC are set.

With the ways I know to test transfers, the truncate flag is always set so the O_CREAT flag is always set. I am guessing that when this error occurs the truncate flag is not set so O_CREAT does not get set. If the file does not exist we get an error.

I did verify that the error is generated if I update the code to not set the O_CREAT.

I think the solution is to set the open mode for the first thread to both O_CREAT and O_WRONLY. I may have to get @mstfdkmn to help test this.

[korydraughn]

@mstfdkmn Are you open to testing the solution in PR #99 (in a testing environment)?

[mstfdkmn]

Yes, we are thinking to test it soon (we don't have a test endpoint for the globus connector so might require time for possible challenges).

[korydraughn]

No problem. Let us know how it goes.

[trel]

@mstfdkmn a fix has been merged. closing so we can get this into the next release.

if it's a problem still / again, please open a new issue and reference this one.

[mstfdkmn]

Great! Thanks. We definitely let you know if needed.

[mstfdkmn]

Seems this fix didnt resolve the issue. We built the connector from its source and integrated to our production end-points and I should say that we do still see errors mentioned above in our irods logs.

[mstfdkmn]

Sorry was an early alarm! I tested against different zones' endpoints and I dont see any error anymore. My initial test transfer seem to have coincidentally resulted in at the same time with an ongoing transfer (I guess old processes are not refreshed/cleaned when the connector built version is changed) and I guess that is why I supposed that I saw again the same errors.

[korydraughn]

So you're saying the change seems to have resolved the issue?