Merge/clean up SAEA and ABJEA, and remove the promises-of-results, futures-of-handles, etc.

[kshakir]

AsyncBackendJobExecutionActor (ABJEA) uses a completionPromise: Promise to tell its parent actor, the BackendJobExecutionActor (BJEA), when the async job is done.

I doesn't seem obvious why we're passing around references to scala.concurrent.Promises when akka has a perfectly good message system already.

Worst case, if one needed two different states and didn't want the framework to use an FSM, the BJEA could context.become(initializing), start the async job, then context.become(asyncRunning), and wait for the message from the ABJEA.

[katevoss]

This is unblocked and ready for fixing.

[kshakir]

More details that emerged over the past couple weeks:

In the past, the Local and JES backends extended the ABJEA. When the Local and JES backends were merged into Standard, there was a lot of work in the Standard not to mess with the existing ABJEA. This turns out to have not been necessary. The only known extension of the ABJEA is now the Standard implementation, the StandardAsyncExecutionActor (SAEA).

Thus, one is now free to merge the SAEA and ABJEA, and remove the promises-of-results, futures-of-handles, etc. with a simplified actor/fsm.

Similarly, while there is a Standard actor that extends the BackendJobExecutionActor (BJEA), this isn't necessary either! As the actors are untyped, any implementation that receives and responds to correct messages will work. Thus the StandardSyncExecutionActor (SSEA) could be refactored also, and even merging the SSEA and the SAEA into a single actor/fsm.

Also, when considering rewrites, it was also noted that the term "sync/async" in the SSEA/SAEA names were confusing. Possible alternatives were StandardFutureExecutionActor / StandardMessagingExecutionActor. Again this may be moot if the actors are merged into a single actor.

[katevoss]

@kshakir Can you give me an idea of the effort involved for this?

[kshakir]

I'd call this a "medium" effort for a developer. It's not a quick fix, while not as much as an effort as "implement CWL". A couple weeks of refactoring, a round of testing and team review, then another two weeks to polish it off.

[katevoss]

As a user developing a backend for Cromwell, I want the execution actor naming and system to be simple and concise, so that I can more easily work with Cromwell, and don't add unnecessary code.

• Effort: Medium
• Risk: Small
• Business value: Small
  • Not to devalue cleaning up tech debt, but there are higher value items on our docket.

[geoffjentry]

Closing this as it's a year and a half old

@kshakir - if you'd like something to change in this regard, put together a tech doc of what you'd like to see happen.