c# - Custom Command Windows Services on HIGH Priority -

i have work tracker wpf application deployed in windows server 2008 , tracker application communicating (tracker)windows service via wcf service.

user can create work entry/edit/add/delete/cancel work entry worker tracker gui application. internally send request windows service. windows service work request , process in multithreading. each workrequest entry create n number of work files (based on work priority) in output folder location.

so each work request take complete work addition process.

now question if cancel creating work entry. want to stop current windows service work in runtime. current thread creating output files work should stopped. thread should killed. thread resources should removed once user requested cancel.

my workaround:

i use windows service on custom command method send custom values windows service on runtime. achieving here is processing current work or current thread (ie creating output files work item recieved).and coming custom command cancelling request.

is there way work item request should stopped once custom command.

any work around appreciated.

summary

you talking running task host long running tasks, , being able cancel tasks. specific question seems want know best way implement in .net. architecture good, although brave roll own rather using existing frameworks, , haven't mentioned scaling architecture later.

my preference using tpl task object. supports cancellation, , easy poll progress, etc. can use in .net 4 onwards.

it hard provide code without designing whole job hosting engine , knowing .net version. have described steps in detail below, references example code.

your approach of using windows service oncustomcommand fine, use messaging service (see below) if have option client-service comms. more appropriate scenario have many clients talking central job service, , job service not on same machine client.

running , cancelling tasks on threads

before @ exact context, review msdn - asynchronous programming patterns. there 3 main .net patterns run , cancel jobs on threads, , list them in order of preference use:

• tap: task-based asynchronous pattern
  • based on task, has been available since .net 4
  • the prefered way run , control thread-based activity .net 4 onwards
  • much simpler implement eap
• eap: event-based asynchronous pattern
  • your option if don't have .net 4 or later.
  • hard implement, once have understood can roll out , reliable use
• apm: asynchronous programming model
  • no longer relevant unless maintain legacy code or use old apis.
  • even .net 1.1 can implement version of eap, not cover implementing own solution

the architecture

imagine rest based service.

• the client submits job, , gets returned identifier job
• a job engine picks job when ready, , starts running it
• if client doesn't want job more, delete job, using it's identifier

this way client isolated workings of job engine, , job engine can improved on time.

the job engine

the approach follows:

• for submitted task, generate universal identifier (uid) can:
  • identify running task
  • poll results
  • cancel task if required
• return uid client
• queue job using identifier
• when have resources
  • run job creating task
  • store task in dictionary against uid key

when client wants results, send request uid , return progress checking against task retrieve dictionary. if task complete can send request completed data, or in case go , read completed files.

when want cancel send request uid, , cancel task finding in dictionary , telling cancel.

cancelling inside job

inside code need regularly check cancellation token see if should stop running code (see how abort/cancel tpl tasks? if using tap pattern, or albahari if using eap). @ point exit job processing, , code, if designed well, should dispose of idiposables required, remove big strings memory etc.

the basic premise of cancellation check cancellation token:

• after block of work takes long time (e.g. call external api)
• inside loop (for, foreach, do or while) control, check on each iteration
• within long block of sequential code, might take "some time", insert points check on regular basis

you need define how need react cancellation - windows service should within milliseconds, preferably, make sure windows doesn't have problems restarting or stopping service.

some people whole process threads, , terminating thread - ugly , not recommended more.

reliability

you need ask: happens if server restarts, windows service crashes, or other exception happens causing lose incomplete jobs? in case may want queue architecture reliable in order able restart jobs, or rebuild queue of jobs haven't started yet.

if don't want scale, simple - use local database windows service stored job information in.

• on submission of job, record details in database
• when start job, record against job record in database
• when client collects job, mark delayed garbage collection in database, , delete after set amount of time (1 hour, 1 day ...)
• if service restarts , there "in progress jobs" requeue them , start job engine again.

if want scale, or clients on many computers, , have job engine "farm" of 1 or more servers, @ using message queue instead of directly communicating using oncustomcommand.

message queues have multiple benefits. allow reliably submit jobs central queue many workers can pick , process, , decouple clients , servers can scale out job running services. used ensure jobs reliably submitted , processed in highly decoupled fashion, , can work locally or globally, reliably, can combine running windows service on cloud workers can dynamically scale.

examples of technologies msmq (if want maintain own, or must stay inside own firewall), or windows azure service bus (wasb) - cheap, , done you. in either case want use patterns , best practices enterprise integration. in case of wasb there many (msdn), many (msdn samples brokeredmessaging etc.), many (new task-based api) developer resources, , nuget packages use