Make CreateWithRemoteFilesOrderedMembersActor thread safe

[mbklein]

Summary: Prevents instance variable collisions in the CreateWithRemoteFilesOrderedMembersActor

Detailed Description: Since ActionDispatch::MiddlewareStack reuses specific middlewares from a pool at runtime, individual middlewares (such as actors) should not count on having mutable instance variables. In this case, that manifested through the @ordered_members accumulator on the CreateWithRemoteFilesOrderedMembersActor actor, which ended up with a jumble of unrelated file sets under heavy ingest load (such as a batch ingest operation).

Changes proposed in this pull request:

• Add thread-safe store and retrieve methods to the environment that gets passed around among actors.
• Use environment storage instead of instance variables in the CreateWithRemoteFilesOrderedMembersActor actor.

Guidance for testing, such as acceptance criteria or new user interface behaviors:

• There isn't a great way to test this live without throwing a few hundred multi-fileset works at it in a single batch. I did add a threaded spec test that fails on the existing master branch and passes on this commit.

@samvera/hyrax-code-reviewers

[no-reply]

@mbklein this looks good to me. I'm frustrated that we need to store so much state in the env, and expand its interface to do so, but I'm not inclined to spend much time engineering a better solution. I think our energy is better spent on deprecating the stack. :|

Is this going to be an issue for other actors that use instance variables? e.g. https://github.com/samvera/hyrax/blob/master/app/actors/hyrax/actors/interpret_visibility_actor.rb#L6

[no-reply]

👍

[no-reply]

Do we want a backport to 2.x?

[mbklein]

I'm frustrated that we need to store so much state in the env, and expand its interface to do so, but I'm not inclined to spend much time engineering a better solution.

Likewise.

Do we want a backport to 2.x?

Yes, I think so.

[mbklein]

Is this going to be an issue for other actors that use instance variables?

Only if 1) the instance variables are part of the Actor class itself (not a contained class, as in the example you provided), and 2) the instance variables are expected to be mutable within the scope of the create/update/delete methods. I couldn't find any other examples of vulnerable instance vars in the existing actor stack.

[no-reply]

Thanks!