envoy-mobile icon indicating copy to clipboard operation
envoy-mobile copied to clipboard

core: add multiple engine support

Open goaway opened this issue 5 years ago • 5 comments

The skeleton for this is in place, but it needs to be implemented.

Most of the library has been designed with the assumption that the EnvoyEngine will be instantiated (potentially multiple times) within the process. However, the Engine itself currently is held in a static weak pointer. We have a method to return an engine identifier, that currently is stubbed to simply return 1.

In an earlier change, I made this type pointer width, and my plan for when we fully switch over will be to actually store the memory location of the Engine as the identifier. (This id is opaque and never actually exposed above the bridge layer.)

Because of this, we won't actually need a collection to hold Engine instances. Instead we can create an Engine with new, and store it until the platform engine wrapper is deallocated. At this point, we can drain and then ultimately delete the Engine instance.

With https://github.com/lyft/envoy-mobile/pull/923 resolving the last major category of shutdown crashes, the door should be open to make this change. There are a handful of locations in code where we intentionally currently leak memory as a shortcut since the Engine itself has been static anyways. These are commented, and I'll subsequently update those comments with a reference to this issue so we can be sure to clean them up.

goaway avatar Aug 15 '19 22:08 goaway

Note that when we have support for this, we should consolidate some of the iOS integration tests into one file/case to exercise this functionality: https://github.com/envoyproxy/envoy-mobile/pull/1298

rebello95 avatar Mar 17 '21 01:03 rebello95

Moving context from #2003:

Per @carloseltuerto:

Today, due to some EnvoyProxy limitations, Envoy-Mobile can not run more than one Engine at a given moment. For the YouTube App, only one Engine is not viable - it needs at least two concurrent Engines.

TODO: upstream tests with tear down of A first, tear down of B first, different logging paths.

junr03 avatar Mar 04 '22 22:03 junr03

Per @alyssawilk's comment:

Ok @goaway @junr03 the upstream part is "done enough" insofar as if you bump main it should work (and if not, it definitely works with envoy.restart_features.no_runtime_singleton = true, as that's what is regression tested)

junr03 avatar Mar 04 '22 22:03 junr03

This PR https://github.com/envoyproxy/envoy-mobile/pull/2085 pulls in all of @alyssawilk's upstream changes.

junr03 avatar Mar 07 '22 07:03 junr03

Oh nice, this one has the details of what needs to be done. Thanks for filing it @goaway and digging it up, @junr03

alyssawilk avatar Mar 07 '22 14:03 alyssawilk