Is there a way to stop the worker process by itself? I already coded in console application, which uses REST API to start and stop worker process and delete cloud service deployment. In the latest announcement, stopping worker processes will not cost anything, it is free now.
Can I make the worker process to stop itself? Is there any event in the worker process to stop itself? Please let me know.
So I think you're referring to Worker Roles, right? A worker process would simply be something you run in your app (like a thread, a method, something). Azure Worker Roles are full VMs.
Assuming that's what you meant: The new announcement about stopping VMs does not apply to Web / Worker Role instances; it applies to Virtual Machines. And those can be stopped easily via REST call (or much easier via PowerShell that wraps the REST call). You could make that call from a Virtual Machine, which would effectively shut itself down, but I'm not so sure that's a sound idea. If you take that approach, it will be very hard for you to track the role-stop progress, since you would have just stopped the VM that made the call.
Related
We know about relation between Process and Thread.
Thread comes under Process, we can say Process is a container and Thread is an element of a container.
But what about Service ?
I can say Process and Thread having same genre.
Can we say the same thing for Services?
I found Window Services and Android Services having similarity, say in Android if we want to play Media then we have to get getSystemService(Context.AUDIO_SERVICE) likewise in Windows (8) if you stop Windows Audio (audiosrv.dll) services from services.msc then Media will not play.
What is Service?
Windows
A service is an application type that runs in the system background without a user interface and is similar to a UNIX daemon process.
Android A service is a component which runs in the background, without direct interaction with the user.
A service runs by default in the same process in the main thread as the application.
Services which run in the process of the application are sometimes called local services.
With above definition we can say apparently that Service is also a Process (i am not sure, please make me correct)
Let me start with the statement - Service is not a process. It is an activity without GUI
If you start a thread, it runs parallel with your main activity thread. But a Service is not guaranteed to always run in a new thread. So, you cannot call a service similar to Thread.
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
So When to use of a service in your application ?
If your application tells the system about something it wants to be doing in the background (even when the user is not directly interacting with the application). This corresponds to calls to Context.startService(), which ask the system to schedule work for the service, to be run until the service or someone else explicitly stop it.
Reason - Your application together with all its global variables will not be wiped out as long as there is a Service still running. So if the user is not interacting with your application and some other application in foreground needs more memory and if the OS triggers a low memory warning and your activity is destroyed, still your application is not completely lost as the service is running.
A facility for an application to expose some of its functionality to other applications. This corresponds to calls to Context.bindService(), which allows a long-standing connection to be made to the service in order to interact with it.
How the Application priority is defined based on service ?
If the service is currently executing code in its onCreate(), onStartCommand(), or onDestroy() methods, then the hosting process will be a foreground process to ensure this code can execute without being killed.
If the service has been started, then its hosting process is considered to be less important than any processes that are currently visible to the user on-screen, but more important than any process not visible.
If there are clients bound to the service, then the service's hosting process is never less important than the most important client.
A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory.
Suppose I have an Azure role with three instances running. I ask Azure to change the role count to two either by Management Portal or via Management API.
How will Azure decide which role to take down?
As British Developer mentioned, the Windows Azure Fabric Controller decides which instances to shut down. You cannot control this process. I don't think it is always the last number, because I am not sure whether the fabric controller does not rename the instances after shutting down. So even if it shuts down IN_1, at the end of the process we will still have IN_0 and IN_1, instated of IN_0 and IN_2 for example.
You can use the RoleEnvironment.Stopping event to handle the proper stopping (clean shutdown) of your Instance. This event is being raised after the VM was taken out of Load Balancer rotation and before the OnStop Method of your RoleEntryPoint class being called.
I am not sure where I noted, but I know that there is a hard time limit in which you have to complete your cleaning, i.e. I think the Instance will be shutdown after 5 minutes of waiting the OnStop or Stopping handler (I can't remember exactly, but the fabrci controller will not wait forever for you to clean up).
It will usually be the last one to be spun up. So you have IN_0 IN_1 and IN_3. I've only ever see IN_3 go down when you remove one so that seems to be the one.
However, this is not documented anywhere by Microsoft so this isn't guaranteed to be the one that goes down... just seems to be in practice.
I need to test how my code will handle the failure of a web role instance in a development environment.
How do I terminate one of the instances? I can't see any option in the UI for this. Seems like a strange ommission
Update
The issue is relating to a distributed cache layer (I know that azure offers their own)
I want to be able to test how the system reacts to a missing or additional node etc
Prehaps my real question is
how up to date is RoleEnvironment.CurrentRoleInstance.Role.Instances
The need to simulate ungraceful exits in the dev emulator usually is done because you are doing something in your web role that is stateful or long running. That is generally discouraged, but sometimes is unavoidable.
I suspect the best way to simulate the a failure is to kill processes. If you open task manager (or better Process Explorer), you will see "WatDebugger" hosting either "WaIISHost" or "WaWorkerHost". If you kill this process, I think it will simulate a failure.
Honestly, it is easier to test this one in the cloud however. You can RDP into one of the instances and kill the 'WaAppAgent' process. That will kill your RoleEntryPoint and fabric controller agent. That will be a true ungraceful failure.
By failure, do you mean becoming unavailable? It should be seamless because the next request would simply be handled by one of the other instances. As long as there is one instance available Azure will route calls to that instance.
This is the nature of a high-available system, requests are handled by the available instances. This is why you have multiple instances in the first place, to handle requests in the case of failure in one or more instances.
This is why you need to always be watchful of how your application handles state. State needs to be maintained outside of the instance, either in queues or in a database. This ensures that any process can pickup a piece of work and execute against it.
There is another question dealing with Session State that should help: How does Microsoft Azure handle Session State?
By terminate an instance do you mean reducing instance count and see which one gets killed? I like Ryan's view about ungraceful exits, but if it's forced kill by the fabric it'll be a different ball game.
As I understood, it's long running process in server. Can it cover long-running program instance like online game server?
You can think of a worker role as a Windows Service or a Unix Daemon. It is, as you say, a perpetually executing process (although it may be in a wait state for a large portion of the time, but that's for you to decide).
Essentially it can run any code you'd like to write.
It can react to outside stimuli e.g. by polling from the Azure Queue service, but can also open communication channels, query databases, etc.
Your help will give me a much better understanding on Windows azure. Thanks in advance.
I understand the worker role like a method(The Run() method in worker role), that is doing some time-consuming opperation. This allows me to have multiple instances of this worker role, to speed things up if traffic surges.
1) can I have a worker role that does more than on thing like:
- a method that creates a PDF;
- a method that creates a chart;
-a method that parses som HTML;
-a method that processes an image
I could easily do all this with 4 worker roles(one RUN() method for each functionality above), but this is very expensive. Can I place this 4 things as methods on the same worker role?
2) What is the disadvantage of hosting a WCF service on a worker role?
3) What is the disadvantage of talking between instances in the same Azure solution trough WCF insteed of queues? Is this slower?
The interface to a worker role is simple... you implement a Run() method that never returns, and we call it. What you do in there can be anything... you can spin up 100 threads doing different things, you can use Process.Start() to launch separate processes, you can start a web server, etc.
I don't know if there are disadvantages to hosting WCF in a worker role. In a web role, you could use IIS as the host, which may help with scalability of the service as compared to running your own host.
One common pattern is to have a worker role pulling work from a queue. The advantage of the queue is that it guarantees each message gets delivered at least once (so you don't lose work). It also distributes the load, because each worker can pull a message from a queue when it's ready for more work. If you use WCF or some other synchronous communication instead, you have to handle how to distribute the work and how to recover from errors (without losing work) yourself. It's certainly possible (and actually probably faster than a roundtrip to a queue), but it's harder to build a reliable, scalable service this way.
Just adding to Smarx - be careful how you slice your functionality - you pay for every worker role you spin up, so unless you have a particularly hotspot in your workflow, and you're already running multiple workers at maximum capacity, you're better off creating a single worker role that can run as multiple instances.