I have a program that executes for 24 hours, then restarts.
How can I shift main() from into a separate application domain, which is torn down and refreshed every 24 hours, in order to completely eliminate any potential memory leaks?
You had me right up until you said:
in order to completely eliminate any potential memory leaks?
If you want to run code in another app domain then there are plenty of resources on how to do this, for example Executing Code in Another Application Domain (C# and Visual Basic). The basic principle is to create a class that inherits from MarshalByRefObject. You then create your new app domain and instruct it to create an instance of that object - this object is then your "entry point" into your app domain:
AppDomain newAppDomain = AppDomain.CreateDomain("NewApplicationDomain");
ProxyObject proxy = (ProxyObject)newAppDomain.CreateInstanceAndUnwrap("MyAssembly", "MyNamespace.MyProxy");
However in C# there isn't really any such thing as a "memory leak", at best you just have objects which are inadvertantly kept in scope. If this is the case then an app domain is just overkill - all you really need to do is remove references to managed objects that are no longer needed and the Garbage Collector will tidy them up for you.
If you have a true memory leak in unmanaged code an app domain won't help you either. Unmanaged types aren't bounded by app domains and so any unmanaged memory allocated "inside" the app domain won't be freed when the app domain is destroyed. In this case you would be better off using separate processes instead.
I've created a class that allows you to execute code in a separate application domain which would allow you to dispose the application domain and recreate it: Executing Code in a Separate Application Domain Using C#
You can't. A process is isolated and independent and you can't transfer a thread from one process into another process.
What you could do, however, if you absolutely can't fix the memory leaks internally, is create a watchdog program which launches the app whenever it stops running, and set up your app to only be run in single execution mode.
Related
We have very old legacy vb6 application, that has one global object that serves as Application Core, that stores different application settings, invokes database operations and so on. Multiple modules with different progid use this global object and have no problem with it due to single-thread apartment.
Not long ago new WPF application was created, that provide us transition from vb6, however it is still limited by vb6 legacy due to some architectural mistakes. It is able to connect to only one database per app instance. It hold static instance of vb6 global object in wrapper class, that serves as bridge to reach legacy functionality.
Now, we are developing new application that should not be limited by old legacy code, in particular it new application should be able to connect to several databases at once, but there is a catch: vb6 code limited to single database, so there should be several instances of vb6 global objects, one per each database.
So the question is: is it possible, and if it is, how is it possible to use several separated intstances of global vb6 objects in same C# application?
I presume that each instance of such object should live in it's own STA-Thread, but i don't know how to create such threads, that are kept alive for entire application runtime and that have assotiated wrappers, containing instances of global vb6 objects and supporting invocation of some functions from GUI thread (and how to organize such cross-thread communication, there is no thread.invoke(...)). I thinked about using wpf dispatcherization model ( wrapper class is DispatcherObject, each instance has it's own Dispatcher with it's own STA-Thread), but i cannot see how to implement such thing. Also I think it could be imlemented by loading each instance of wrapper class (static) in different AppDomains, but i don't know if it resolves STA problem for COM.
It is possible, using what is referred to as unmanaged code. Check out this:
http://www.codeproject.com/Articles/154144/Using-Unmanaged-VB6-Code-in-NET
You might get away with running one instance of the global object per AppDomain.
To be safe, you should run them each in its own process, since that's the assumption they were created with. I guarantee you that horrible things can happen when you violate the assumptions of ancient code - especially when you introduce them to things which simply did not exist when they were written.
I'm just getting my feet wet with the Ninject.Mvc3 NuGet package, and I'm wondering about how long the created objects last.
InRequestScope is pretty each to understand: each object created in this scope lives as long as the webserver is handling a particular web request. (To be pedantic, the objects live as long as the HttpContext.Current object does)
But how long so the InSingletonScope objects last? The documentation says as long as the Ninject Kernel itself does--which is wrapped up the the NinjectWebCommon static class. The best guess I've made so far is that the kernel lives as long as the server is running the webapp--as long as the server is up, until the app is manually restarted in IIS or updated, the objects are in scope.
I'm curious because I'm tempted to have some Data Accessors containing read-only data dictionaries as Singleton Scope, and I'm wondering if this is a good idea, or a memory leak in planning.
It would last as long as your ASP.NET application pool lasts.
When will your application pool recycle? There are many settings which govern this: have a read of Configuring Recycling Settings for an Application Pool (IIS 7).
Basically, though, it ain't gonna be forever: if you want to store read-only data in there, just make sure you load it all up in Application_Start() so it's ready when requests come in, and you should be good to go.
You are correct. As long as the app pool is running your singletons will live. Why you might want to turn off application pool recycling.
For most of my websites I cache settings in static classes (or as singletons using Ninject or StructureMap), and data in thread safe dictionaries. This of course consumes memory, but it is not a memory leak. Working as designed.
I read the concept about Application Domain in .NET. However, I don't know when to use it. A application domain is working as a thread in a process. A process will have more than or equal one application domain. However, I can deploy a process with multi-threading without using application domain.
Anyone can tell some examples to use it in practice. There are source code for examples are good. And I wonder that there are any Microsoft's applications to use this technology.
Thanks.
If you load a dll in your main AppDOmain you can't unlod it. But if you load the .dll in an AppDOmain you can unload the AppDomain and so unload the dll. Like that you can load and unload dll.
And with Addin I saw that you can load plugin in AppDomain with security, in order that the plugin can not compromise the main software security.
I would like to explain the usage of AppDomains in a real world design problem from one of my earlier project.
Basically that project is a port scanner for some information. So we had 6 ports, and we are suppose to scan 6 ports in parallel. Of course we could have used threads, but then isolation would not be possible at all. We wanted every port functionality i.e scanning should be completely isolated and even its data storage and other functionality to be independent.
So what we did was, we used AppDomain concept in loading on of our dll which does this scanning job and few more (proprietary logics) into 6 AppDomains we had created for each port. Infact, this dll spawns more thread internally to do various jobs once you scan the port for some data. Hence we have completely isolated each port scanning and when user wants to stop scanning for one of the port (via UI selection) then we just have to gracefully unload this AppDomain.
Hope it was some help to you :)
MSDN really gives a clear picture here of what AppDomains are actually for: http://msdn.microsoft.com/en-us/library/system.appdomain.aspx
Application domains, which are represented by AppDomain objects, help provide isolation, unloading, and security boundaries for executing managed code.
Use application domains to isolate tasks that might bring down a
process. If the state of the AppDomain that's executing a task becomes
unstable, the AppDomain can be unloaded without affecting the process.
This is important when a process must run for long periods without
restarting. You can also use application domains to isolate tasks that
should not share data.
If an assembly is loaded into the default application domain, it
cannot be unloaded from memory while the process is running. However,
if you open a second application domain to load and execute the
assembly, the assembly is unloaded when that application domain is
unloaded. Use this technique to minimize the working set of
long-running processes that occasionally use large DLLs.
Application domains allow applications to be unloaded separately. My question is how unloading an apllication can crash another application. Any example?
In theory, App Domains are completely isolated from each other (even though you may run several App Domains in one process, they act as separate processes), so this shouldn't be possible.
Are you asking theoretically, or are you actually experiencing crashes?
I assume you mean AppDomain when saying Application.
Pure managed code should unload correctly (but not all finalizers might execute)
But buggy native inter-op can of course still crash the process.
I want to have an application that works as a Host to many other small applications. Each one of those applications should work as kind of plugin to this main application. I call them plugins not in the sense they add something to the main application, but because they can only work with this Host application as they depend on some of its services.
My idea was to have each of those plugins run in a different app domain. The problem seems to be that my host application should have a set of services that my plugins will want to use and from what is my understanding making data flow in and out from different app domains is not that great of a thing.
On one hand I'd like them to behave as stand-alone applications(although, as I said, they need to use lots of times the host application services), but on the other hand I'd like that if any of them crashes, my main application wouldn't suffer from it.
What is the best (.NET) approach to this kind of situation? Make them all run on the same AppDomain but each one in a different Thread? Use different AppDomains? One for each "plugin"? How would I make them communicate with the Host Application? Any other way of doing this?
Although speed is not an issue here, I wouldn't like for function calls to be that much slower than they are when we're working with just a regular .NET application.
Thanks
EDIT: Maybe I really need to use different AppDomains. From what I've been reading, loading assemblies in different AppDomains is the only way to later be able to unload them from the process.
I've implemented something along these lines using the Managed Addin Framework (MAF) in the System.Addin namespace. With MAF you package your addins as separate DLLs, which your host app can discover and launch in its app domain, in a separate domain for all of the addins, or each addin in its own domain. With shadow copy and separate domains you can even update an addin without shutting down your hostapp.
Your host app and the addins communicate through contracts that you derive from MAF interfaces. You can send objects back and forth between the host and the addins. The cotnracts provide a black-box interface between addins and the host, allowing you to change an addin's implementation unbeknownst to the host.
Addins can even communicate between themselves if the host tells them about each other. In my case a logging addin is shared by the others. This lets me drop in different loggers without touching the other addins or the host.
For my app, the addin use simple supervisor classes that in launch worker classes on their own threads that do all of the processing. Workers catch their own exceptions, which they return to their supervisor through callback methods. Supervisors can restart workers or take other action. The host controls the supervisors through a command contract, which instructs them to start and stop workers and return data.
My host app is a Windows service. The worker threads have thrown exceptions for all the usual reasons (including bugs!), but the host app has never crashed in any of our installations. Since debugging services is inconvenient, addins allow me to build test apps that use the same contracts, with added assurance that I'm testing what I deploy.
Addins can expose UI elements, too. This is very helpful to me as I need to deploy a controller app with the host service, since services do not have UIs. Each plugin includes its own controller interface. The controller app itself is very simple - it loads the addins and displays their UI elements. This allows me to ship an updated addin with an updated interface and not have to ship a new controller.
Even though the controller and the host service use the same addins, they don't step on each other; in fact, they don't even know that another app is using the same addins. The controller and the host talk to each other through a shared database, but you could also use another inter-app mechanism like MSMQ. In the next version the host will be a WCF service with addins on the backend and web services for control.
This is a bit long-winded but I wanted to give you an idea of how versatile MAF is. It's not as complex as it might first look, and you can build rock-solid apps with it.
It depends on how much trust you wish to allow the extensions. I'm working on a similar application and I've chosen to mostly trust the extension code, as this greatly simplifies things. I call into the code from a common thread (in my case, the extensions don't really 'run' in any continuous loop, but rather execute certain tasks that the main application wants to do) and catch exceptions in this thread, so as to provide helpful warnings that loaded extensions are misbehaving.
Currently there's nothing keeping these extensions from launching their own threads that could throw and crash the whole app, but this where I've had to make the trade-off between safety and complexity. My application is not mission-critical (not like a web server or database server), so I consider it an acceptable risk that a buggy extension could bring down my application. I provide safeguards to more politely cover the most common failure cases and leave it to the plugin developers (who will mostly be in-house people for now anyway) to clean up their bugs.
In regards to Unloading, yes, you can only unload the code and metadata for an assembly if you place it in an AppDomain. That said, unless you want to be loading and unloading frequently over the life of your program, the overhead associated with keeping the code in memory is not necessarily an issue. Any actual instances or resources using types from the assembly will still be cleaned up by the GC when you stop 'using' it, so the fact that it's still in memory doesn't imply a memory leak.
If your main use case is a series of plugins that you locate once at startup and then provide an option to instantiate while your app is running, I suggest investigating the real memory footprint associated with loading all of them at start-up and keeping them loaded. If you use AppDomains, there will be additional overhead there as well (for instance, memory for the proxy objects and loaded/JITed code to support AppDomain marshaling). There will also be CPU overhead associated with the marshaling and attendant serialization.
In short, I would only use AppDomains if one of the following were true:
I want to get true isolation for the purposes of code security (i.e. I need to run untrusted code in an isolated way)
My app is mission-critical and I absolutely need to make sure that if a plugin fails, it can't bring down my core app.
I need to load and unload the same plugin repeatedly, in order to support dynamic changes to the DLL. This is mainly if my app can't stop running, but I want to hot-patch plugins while it's still running.
I would not prefer AppDomains for the sole purpose of reducing possible memory footprint by allowing Unload.
This is an interisting question.
My first idea was to simply implement interfaces from your host application in your plugin applications to allow them to communicate through Reflection, but this would only allow communication and would not bring a real "sandbox-like" architecture.
My second thought was to design a service-oriented platform. The host application would be a kind of "plugin broadcaster" which would publish your plugins in a ServiceHost on a different thread. As this need to be really responsive and "no brainer configurated", the host application could communicate with the plugin through named pipes channel (NetNamedPipesBinding for WCF) which means is only communicating with localhost pipes and does not need any network configuration or knowledge at all. I think this could be a good solution to your problem.
Regards.