Ok, so i have Call1 in a webservice that will start a bacground worker thread to start doing some processing, but would like to have another call (Call2) that will monitor the original Worker Thread via a reference?
Any suggestions on how to do this? I'd really like to stay away from a WinService to do my processing. As i need it to be more realtime.
I don't see why using a Service application should be a problem. Services run all the time and monitoring them can be done it real time.
But, if you really don't want to go that way then there are other options. It is possible to start a new thread, using the ThreadPool or by starting a new Thread manually, and that thread will run in the background of the application pool where your web service runs.
You may want to use a task scheduler library for this. Check out Quartz.net for this.
Be aware that the app domain where your web service runs may be killed at any time if IIS decides it is necessary, so there is no guarantee that the job will complete. Using a Service application will fix this.
Related
I'm building a web application in Asp.net. I have long-running tasks that may or may not get finished, as IIS tends to kill long running tasks.
Problem? Nope. I use quartz to periodically restart tasks that die (as changes get saved in the DB, so all we need to do is restart the thread).
But now I'm trying to build my web-application to support scaling out. I'd like to run multiple instances.
So, to handle my long running tasks, I'm thinking of adding a column to my database to note which instance has 'checked out' a given task. However, I'll need to know when the thread dies so that I can make sure it's 'checked in'.
So how do I check when a thread dies?
IIS does not kill threads, it kills AppDomains. The only way I know would be have it write a entry as a heartbeat signal while it is running. If the heartbeat has stopped the thread died.
What should I use to make an application that will:
Ask the user for username and password
Authorize
Run an infinite loop in which it will fetch some data from the website every 10 seconds or so.
I want to be able to do some basic tasks in the meantime, or lock my screen without the thread getting killed. I don't want the service to continue running after I close the application, I just want to be sure the thread is never killed while it's running for a long time.
I also wanted to ask: Are services as easy to interact with as threads? Can I just pass a CancellationToken in it and cancel it when the user presses the stop button?
I also found the setThreadPriority, will it help in my case?
Services and Threads are totally different concepts. A Thread is a separate process that executes in parallel. A Service is a component of an app that doesn't have a UI and runs with a separate life cycle. A service does not run on its own thread, it runs on the UI thread (although it can launch a Thread if it wishes).
You use a Service if you want to do some task but not be bound to the Android Activity lifecycle. You use a Thread if you want to run in parallel. If you want both, then you use a Service that launches a Thread.
From what I'm reading (you don't want the Thread to continue after the Activity is finished), you want a Thread and not a Service.
A service can run in isolation (while your app is not necessarily running). A thread can be spun off from either your app itself, or a service.
I have IIS server which runs few WCF REST services I created.
Now I need to add some kind of process that will run on the server and do some work for me once in a while.
I guess the IIS should initiate some kind of a background process or something, but I'm not sure what is the technology I should use in this case?
After reading at least three other similar questions, it appears the best practice is to avoid running background threads and allow a windows service app to do the processing. You could drop rows into a database table or append a line to a file to start the windows service work.
See any of these threads...
Can I use threads to carry out long-running jobs on IIS?
What are some best practices for managing background threads in IIS?
As an alternative to Windows Task Scheduler, as mentioned by others, you could also:
In your global.asax file, in your application_start() method, you can spin up a new Thread to do whatever you want, and shut it down in the application_end() method.
Check out the window task scheduler
You can schedule a process to come to life and then check to see if any component has queued up work for it to do. The work could be stored in a file (which would need to be locked) or a database table (that's my preference).
Windows Scheduled Tasks would typically be the way to do this.
I want to load data to my application domain using a thread so it will be executed at all times. How can I achieve this? I want the thread will start when iis starts and terminate when iis exits.
Note:
I want to do this so I can use disconnected architecture in my asp.net application.
Thanks in advance,
Kfir
Kfir,
The simplest way to do this is to launch a blocking background-worker during the App_Start() method on Global.asax and then to kill it using App_Stop() in Global.asax.
Have the thread sit on a WaitHandle until it's ready for more data and then signal it to wait back up. Or if you really wanted to code something ghetto, you could just have it poll on a fixed interval using a timer.
I need a block of code which run a job in background. Suppose the user click on the Submit button, then a job starts in background, in the mean time the user closes that window and run a different job, and the job should keep running.
Please provide some help in ASP.NET and VB.NET.
Thank You Very Much For Your Help
You may take a look at the ThreadPool.QueueUserWorkItem method which allows you to run some some method on a thread drawn from the thread pool. As an alternative you could use the Thread class to spawn a new thread manually if it is a long running task to avoid jeopardizing a thread from the pool which contains a limited number of threads and which are also used to service requests in ASP.NET applications.
You can do this by creating a windows service that host a wcf service, when the user click on the submit button you can send the request to the windows service and the windows service will run in the background event the user closes the window.
A BackgroundWorker may be the easiest place to start. Put your code in the DoWork event.
You might use the BackgroundWorker, depending on your context.
BackgroundWorker will run in the background and can be easily used to sync back updates to your GUI if needed.
Or use the Task Parallel Library...