I've got an application that needs to have multiple app domains to isolate potentially unsafe modules, and also provide a level of isolation for non-thread-safe code. Each module implements a common interface but will also include long-lived method calls (minutes).
In the distant past, when I did something similar, I used MarshalByRefObject
but I've since read that WCF is now the preferred mechanism for communicating across the AppDomain boundary.
Since I want multiple app domains and each request may be long-lived, I see a couple of issues:
- I explicitly need only a single thread to be executing "work" code at a given time (so WCF's default approach of instantiating a new host class for each request is an issue)
- How to manage a list of appdomains/the appropriate endpoints to make the calls to (how to inform each AD what endpoint to use/how it should report the endpoint it chooses at random)
I'd initially planned to make the calls into the AppDomain asynchronous and have some form of queueing system internally that allowed me to monitor/retrieve results but in light of using WCF and the hassle of overriding enough to control instantiation of the service host object (to allow subsequent calls to be made to the same object), I'm starting to wonder if I should make all the calls blocking and allow the parent process to handle all the thread problems. of course, then I'd also need to make sure I've never got more than 1 call pending to a given app domain and perform queueing in the parent process.
Does anyone have any experience with a similar scenario/advice on a good architecture/link to a decent article?