I configured Windows 2012R2 with IIS 8.5 and turned on the new suspend option.
According to the documentation the state is written to disk and resources freed up.
I have a site that is strong on SignalR, when the site is started there is always a never-exiting thread that keeps track of parameters of a game, users come to the site, play the game and the state is saved in the database.
Before when the site terminated it would load everything from database to restore the game-state, which worked fine but it took a REAL long time before the site would start (sometimes up to 5 minutes).
Now I configured the suspend option and it looks to work fine, site starts up in matter of seconds, BUT the never-ending thread.. has ended.
What could be the culprit? Is there an event that is called when the site goes into suspend or comes out of suspend instead of a cold startup?
It's not a good idea to run background threads within IIS. See http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in-asp-net.aspx/
Possible solution is to have a Windows Service (I recommend TopShelf for easy bootstrap) that runs your background operations and communicates with your ASP.NET via API.
See this question: IIS Background thread and SignalR
Related
I am working on an (console) application, which should be executed on startup and keeps running all the time in the background (executing something every 30 minutes).
How can I, in another (device) application, check if my console application is running (and start it if its not)?I am using VB.NET CF 2.0 and everything is being deployed on a device running WM 6.5
All the code examples I found where only available on the "standard" .NET.
There are several ways your "monitoring" app could work (and certainly more than I list here).
Use a named mutex (you'll have to P/Invoke it). The monitored app would create and hold it, and the monitoring app would periodically check to make sure it's held. If it's not held, the monitored app is no longer running.
Use the Toolhelp APIs. Have the monitoring app use the Toolhelp APIs to periodically enumerate the running processes. If the monitored app is not in the process list, it is not running.
Use a named event. The monitored app would have a background thread that periodically sets a named (watchdog) event. The monitoring app would wait on that event and if it fails to get the event in a certain time bound, the other app is either not running or has locked up.
Use a socket. Have the monitored app open a socket and listen on it. The monitor app would send a "ping" periodically to the monitored app. The monitored app would respond to the ping with an ack. If the monitoring app doesn't get an ack, the monitored app is either not running or is locked up
Use a window handle. The monitor app periodically P/Invokes GetWindow of FindWindow to find an always-present window in the monitored app - often by Form text. If the monitoring app can't find the Window, the monitored app is not running.
I have an XNA client which communicates with a WCF service to operate.
The XNA application is actually a multiplayer pokergame.
When I run the WCF service locally, everything works well.
However, I lately deployed my WCF service into Azure. Now when I launch the client,
it starts OK, buttons are responsive and clickable.
The same is when I launch another client, and there is now an option to start a game
(as there are 2 players).
Again, the StartGame button is clickable for both clients.
However, once the game commences, the UI hangs and becomes unresponsive.
I can't reproduce this locally. This only happens while using the Azure service.
Note I'm not using any callbacks from the server back to the client, my client continuously polls the server and operates according that information.
Any ideas?
Solved. Problem was I had another service function being called continuously, not on a new thread. While executing locally, traffic was fast enough to overcome this.
However, running remotely caused application to hang due to the synchronous calls.
I would like to start a new instance of a wcf service host from another (UI) application. I need the service to be out of process because I want to make use of the entire 1.4GB memory limit for a 32bit .NET process.
The obvious method is to use System.Diagnostics.Process.Start(processStartInfo) but I would like to find out whether it is a good way or not. I am planning on bundling the service host exe with the UI application. When I start the process, I will pass in key parameters for the WCF service (like ports and addresses etc). The UI application (or other applications) will then connect to this new process to interact with the service. Once the service has no activity for a while, it will shut itself down or the UI can explicitly make a call to shut the service down.
You can definitely do this:
create a console app which hosts your ServiceHost
make that console app aware of a bunch of command line parameters (or configure them in the console app's app.config)
launch the console app using Process.Start() from your UI app
That should be fairly easy to do, I'd say.
Perhaps I'm completely offbase here, but I don't think there is a 1.4 GB memory limit for .NET processes. The memory allocated for each process is managed by the OS. For 32-bit opeating systems, there is a 4 GB memory space available, but that is shared among all of the processes. So while it may appear that there is only 1.4 GB available, it's not technically true.
The only reason I bring that up is to say that the other way to approach this would be to load your WCF service inside a separate AppDomain within your UI application. The System.AppDomain class can be thought of as a lightweight process within a process. AppDomains can also be unloaded when you are finished with them. And since WCF can cross AppDomain boundaries as well as process boundaries, it's simply another consideration.
If you are not familiar with AppDomains, the approach that #marc_s recommended is the most straightforward. However, if you are looking for an excuse to learn about AppDomains, this would be a great opportunity to do so.
We have a program that uses QoS-sockets, our softphone application uses QoS for the RTP.
That application is normally left running, sometimes however it is restarted. (Stop, wait 300ms, start.)
We have found that when the softphone-application is stopped that the last one useing QoS on the server, so the RSVP QoS-service on windows is stopped as well.
When we restart our application the RSCP QoS-service normally starts really fast, however sometimes the service start takes a full 30 seconds, causing our application to start slowly as well.
Anyone know if I can configure the service not to stop each time?
The computer is Windows XP SP3, with Windows Firewall turned on. (Our application do have an exception in the firewall.)
Regards
Leif
In the end this was solved with a workaround.
In the main-application we now open a QoS-socket, which we keep open until the main-application ends. That way the RSVP service cannot be closed, since it's in use.
(I found that opening the socket without bind()-ing works, so we don't need any port.)
I have several different c# worker applications that run various continuous tasks: sending emails from queue, importing new orders from website database to orders database, making database backups and restores, running data processing for OLTP -> OLAP, and other related tasks. Before, I released these as windows services, but currently I release them as regular console applications. They are all based on a common task runner framework I created, and I am happy with that, however I am not sure what is the best way to deploy these types of applications. I like the console version because it is quick and easy, and it is possible to quickly see program activity and output. The downside is that the worker computer has several console screens running and it gets messy. On the other hand the service method seems to take to long to deploy and I have to go through event logs to see messages. What are some experiences/comments on this?
I like the console app approach. I typically have things set up so I can pass a switch like -unattended that suppresses the console screen.
Windows Service would be a good choice, it runs in the background no matter if you close current session, also you can configure it to start automatically after windows restart when performing a patches update on the server. You can log important messages to event viewer or database table.
For a thing like this, the standard way of doing it is with Windows services. You want the service to run on the network account so it won't require a logged in user.
I worked on something a few years ago that had similar issues. Logically I needed a service, but sometimes I needed to see what was going on and generally I wanted a history. So I developed a service which did the work, any time it wanted to log, it called to it's subscribers (implemented as an observer pattern).
The service registered it's own data logger (writing to a database) and at run time, the user could run a GUI which connected to the service using remoting to become a live listener!
I'm going to vote for Windows Services. It's going to get to be a real pain managing those console applications.
Windows Service deployment is easy: after the initial install, you just turn them off and do an XCOPY. No need to run any complicated installers. It's only semi-complicated the first time, and even then it's just
installutil MyApp.exe
Configre the services to run under a domain account for the best security and easiest interop with other machines.
Use a combination of event logs (with Error, Warning, and Information) for important notifications, and just dump verbose logging to a text file.
Why not get the best of all worlds and use something like:
http://topshelf-project.com/
It will allow you to run your program as command line or a windows service.
I'm not sure if this applies to your applications or not, but when I have some console applications that are not dependent on user input or they are the kind of applications that just do their job and quit, I run such programs on a virtual server, this way I don't see a screen popping up when I'm working, and virtual servers are easy to create and restart.
We regularly use windows services as the background processes. I don't like command-line apps as you need to be logged into the server for them to run. Services run in the background all the time (assuming they're auto-start). They're also trivial to install w/the sc.exe command-line tool that's in windows. I like it better than the bloat-ware that is installutil.exe. Of course installutil does more, but I don't need what it does. I just want to register my service.
We've also created a infrastructure where we have a generic service .exe that loads .DLLs based on an interface definition, so adding a new "service" is as simple as dropping in a new DLL and restarting the service host.
However, we started to move away from services. The problem we have with them is that they lock up the DLLs (for obvious reasons) so it's a pain to upgrade them. We need to stop, upgrade and then restart. Not hard, but additional steps. Instead we're moving to special "pages" in our asp.net apps that run the actual background jobs we need done. There's still a service, but all it does it invoke the asp.net pages so it doesn't lock up any of our DLLs. Then we can replace the DLLs in the asp.net bin directory and normal asp.net rules for app-domain restart kick in.