replication from compound using python about irods_rule_engine_plugin_python

[trel]

I am not sure the functionality/quality of the backupRescName keyWd (it should probably be deprecated)...
try using destRescName instead to define the target of the replication operation.

https://docs.irods.org/4.2.11/doxygen/reDataObjOpr_8cpp.html#a957a06d93d1100dceb5a497bb9d1253f

It's possible you've found a similar issue to #54 - but this sounds a bit different.

[ciklysta]

I"ve just tried destRescName. There is no difference.

The linked bug arises only in case more threads are used. However this one indeed has different cause as it occurs even with numThreds=1.

[trel]

Upon further reading/consultation.... we think this is definitely the same as #54.

#54 was reported against 4.2.6 and 4.2.7, before we introduced logical locking in 4.2.9, which makes all data movement create a placeholder in the catalog first... like only parallel transfer did in 4.2.8 and before. This matches the scenario you're seeing above.

Pretty sure this is the reason... #1

• a PREP-wide mutex getting wedged waiting on a child waiting on its parent.

Also explains why it works fine without coming through the Python rule engine plugin.

We'll test if whether that lock is still required/essential.

[ciklysta]

Thank you for investigation. In that case this ticket is a duplicate.

[dworkin]

@trel @ciklysta This may be a duplicate of irods/irods#6622 instead of #54: the problem occurs when numThreads=1 and msiExecCmd is used with a python rule on the call stack.

[trel]

Oh, interesting...

Any chance you think that irods/irods#6622 is actually, itself, the same as #54?

In other words, should we now re-test #54 to see if it is still a deadlock with the new irods/irods#6622 codefix in place?

[dworkin]

Both issues deadlock on the same lock, both require a python rule on the call stack, but they are distinct. #54 deadlocks without using msiExecCmd.

[trel]

Got it - right.