I am working on a project where we have lots of separate components are running and my agenda is to cancel the component process in between based on user input.
For example: I have 6 windows service that do all the work and 1 another windows service that is responsible for distribution of work. so once the work is send to worker windows service there is no control over it. this worker windows service do some time consuming task, calling several function, interect with database etc. I want to cancel the task in between of working.
The traditional approch we use for cancelation will no longer work here as...
1. I am not iterating any loop where I can continuosly check for Cancel flag.
2. Since the component is totally separate and once they start working, new instance is created of that component and not able to pass any value to that component.
Thanks in advance.
Related
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 a C# winforms project which has a reference to a library also coming from myself. The winforms app triggers some work to do for the library. Is it possible that the library can finish its work even if the winforms app gets closed?
There are two possible approaches:
create a separate subprocess. Ending the parent process will not end the child, thus, the newly created task will continue when the parent app is closed
make the parent app in such way that closing the main form doesn't end the application, thus, giving the application time to end all worker threads spawned during its lifetime
I am not sure which of the two I would recommend, both seem risky as chances are the long-running background operation will not finish in reasonable time. And then what?
Is it possible that the library can finish its work even if the
winforms app gets closed?
No, not if that library is simply hosted in the main process.
You would need to do something along the lines of create a windows (or web) service and host the library in the service along with a message passing mechanism. Then call into it by having your windows application call a command on the service.
I have a web application and I need a specific process to run in background (all the time) and update the DB from time to time. What's the best way to do it? Create a controller with a method and run it in a thread in background? Any other option?
Your best bet is to create a separate application which you can run as a Windows Service or, if it's only a periodic update, a Scheduled Task.
The benefit of using a Scheduled Task is that you don't have to write the scheduler code - it's all handled for you by the operating system. Your application just consists of the code needed to update the database.
By divorcing it completely from your web application, it makes it more secure and easier to maintain (you can update either the web application or service independently of each other).
This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
windows service vs scheduled task
Windows Service Vs Simple Program
I'm trying to create a program that runs periodically (say every 5 minutes), or have the program running and have it execute the function within it (every 5 minutes).
The program is to obtain data from a database when it's executed and then write this to (for now) say info.txt file (no sensitive stuff is contained in here). each time it writes to the file it should overwrite the existing info within the file.
The program should also be started automatically at windows start up. (thus no need to login on the machine and to execute the .exe [if it's a normal program and not a service])
In between the periods that it executes the program would have nothing to do.
Therefore, should I run this program as a Windows Service, or should I use the Task Scheduler to periodically start the program to do this?
My goal is for this program to run as smooth as possible without clogging up resources. (eg. it shouldn't need more than 5% of the cpu)
I hope my question was clear enough.
I would go with application that is triggered by task scheduler. Only thing that you need to worry about is to run single instance of your application.
You can set task to run under specific user account and to run even if user is not logged on. There are number of events that can trigger task star like "Windows start", "System Idle"...
Other advantage is: If something crashes you can set task scheduler to send you an email or alert you in number of ways. You can control "exit code" of your application and signal to task scheduler what's going on and what to do.
There are a lot of positive features that task scheduler offers but not many people are using them.
I would suggest a Windows Service for this. Might be a good idea to create both and compare what the resource usage is like anyway?
I would actually recommend going for both depending on the requirements of the task you wish to run. I generally build most functionality for scheduled services into a single class library and then wrap it in a console application to start with and for debugging. When satisfied I wrap it in a windows service and forget about it.
Considerations of using a console app:
Make sure you run it under system account if possible or you can put in a specific login under Run as in scheduler. This will ensure an interactive login is not required.
If having 2 instances of it running at the same time is a problem, make sure you name it clearly and check for an instance of it running in your main method and exit if it is. A windows service will avoid this issue.
Considerations of using a window service
Make sure you're educated on thread usage. Windows services will use less resources if managed properly, but can be tricky if it's new to you and end up leaking memory in timer based tasks.
..there's a lot more to consider, but code it right and you can start with one and move to the 2nd when you're confident about it.
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...