1605584 - Support connecting to remote replaying processes

Status: RESOLVED FIXED

(Core Graveyard :: Web Replay, enhancement)

Description

[Brian Hackett [Laid off!]]

Right now, middleman processes can only connect to replaying processes which were spawned on the local machine by their own ContentParent. In order to use replaying processes in the cloud, we need to be able to connect to remote processes over a network connection. The attached patch does this; it works and is pretty much done, but I'm going to hold off on reviews until cloud support is further along.

Because communication with a replaying process is done using a single duplex channel, this is pretty straightforward to implement. We create that channel as normal in the middleman, but instead of placing the other channel endpoint in a local replaying process, we place the endpoint in the parent process, and wire it up to some JS that creates a WebSocket for communicating with the remote server (specified as a preference for now). The JS forwards data in both directions between the channel with the middleman and the socket with the remote process. So far I've tested this with a simple echoing websocket server, and the next step will be to use a websocket server that can create its own replaying processes.

There is some trickiness here in terms of where the JS owning the websocket is located. This patch puts the JS in the parent process; it would be nicer to put the JS in the middleman process since each websocket will be associated with a specific middleman. Using the middleman doesn't work, however, because we need to be able to synchronously communicate over the channel without spinning the main thread's event loop (this is needed to preserve run-to-completion semantics when calling debugger methods that require communicating with a replaying process), and using a websocket in a content process involves main thread runnables, even when the socket is owned by a worker thread (all the websocket communication happens in the parent process anyways, and happens via IPDL messages that must be sent/received on the content process' main thread). In any case, given these constraints I think that what this patch is doing is the most appropriate approach.

Comment 1

[Brian Hackett [Laid off!]]

Attachment: WIP

Comment 2

[Brian Hackett [Laid off!]]

Attachment: WIP

This patch fixes a number of issues with connecting to remote replaying processes, as well as getting replaying macOS recordings on linux to work more reliably. With this patch and the current state of the ReplayLinker repository (https://github.com/bhackett1024/ReplayLinker), I can use web replay on a simple page, connect to a remote replaying process on an AWS instance, and core functionality like scanning the recording, seeking to breakpoint hits in the past, and updating the UI/gfx all work. Web replay is in the cloud!

Comment 3

[Brian Hackett [Laid off!]]

Attachment: Bug 1605584 - Create replaying processes in the cloud when requested, r=mccr8.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/af6e8b6be574
Create replaying processes in the cloud when requested, r=mccr8.

Comment 5

[Dorel Luca [:dluca]]

Backed out 5 changesets (bug 1603856, bug 1606447, bug 1605584, bug 1598951) for build bustages. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=283361477&repo=autoland&lineNumber=51406

Push with failure:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=cf403935cf9bc721f22f808a539a79fc9aa13720

Backout:
https://hg.mozilla.org/integration/autoland/rev/eb5a66c10085c83f5a341a7ba302c98bd6c43a2a

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c7701962744c
Create replaying processes in the cloud when requested, r=mccr8.

Comment 7

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/c7701962744c