none
WCF Worker Threads RRS feed

  • Question

  • Hi.

    We’re developing a service that performs long batch processing that can take several hours.

    There are batch definitions, inputs and outputs, and the service would allow starting a job that would be running in background, get a list of running jobs and their status and stop a job.

    We’d like to control this service via WCF calls to methods like StartJob, StopJob, GetJobList, etc. These methods would be non-blocking; all the real work would be made by the job processing engine using worker threads in background.

    The questions are:

    Is it recommendable to use worker threads for background processing inside the WCF service itself?

    Can be hosted by IIS or would be better self-hosting?

    Or would be better to decouple the WCF service from the job processing engine? And, how would you establish the communication between WCF and the background job processing engine?

    Thanks in advance.

    Sergio


    Monday, September 30, 2013 5:35 PM

Answers

  • I wouldn't host this in IIS - if/when IIS recycled the app domain, you'd lose the work.

    It might make sense to decouple the processing from your service, and use something like MSMQ to queue the work and results, as this would allow you to keep it all very simple.


    Reed Copsey, Jr. - http://reedcopsey.com - If a post answers your question, please click Mark As Answer on that post. If you find a post helpful, please click Vote as Helpful.

    Monday, September 30, 2013 5:38 PM
  • Hi sergiojareno,

    For background and long-run processing, I think a self/custom host such as windows service will be better than IIS web application host. And since you're going to use WCF for exposing a control/management interface for the background processing engine, you do need to host the WCF together with the background processing engine's code (within the same application process). Otherwise, if you host WCF in a seprate application (such as IIS) from the background processing app (such as a windows service app), you still need further inter-process communication effort to make WCF connected and interact with the main background process code.

     


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Tuesday, October 1, 2013 10:14 AM
    Moderator

All replies

  • I wouldn't host this in IIS - if/when IIS recycled the app domain, you'd lose the work.

    It might make sense to decouple the processing from your service, and use something like MSMQ to queue the work and results, as this would allow you to keep it all very simple.


    Reed Copsey, Jr. - http://reedcopsey.com - If a post answers your question, please click Mark As Answer on that post. If you find a post helpful, please click Vote as Helpful.

    Monday, September 30, 2013 5:38 PM
  • Hi sergiojareno,

    For background and long-run processing, I think a self/custom host such as windows service will be better than IIS web application host. And since you're going to use WCF for exposing a control/management interface for the background processing engine, you do need to host the WCF together with the background processing engine's code (within the same application process). Otherwise, if you host WCF in a seprate application (such as IIS) from the background processing app (such as a windows service app), you still need further inter-process communication effort to make WCF connected and interact with the main background process code.

     


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Tuesday, October 1, 2013 10:14 AM
    Moderator
  • Thanks I figured out that would be a bad idea to host it in IIS but I wanted to check why.
    Monday, October 7, 2013 5:24 PM
  • Thanks  for your response, I just was able to check it today.
    Monday, October 7, 2013 5:25 PM
  • <copied>

    Thanks I figured out that would be a bad idea to host it in IIS but I wanted to check why.

    <end>

    That's correct. You would bring IIS to its knees, which would deny Web server access to other Web server clients.

    Monday, October 7, 2013 5:58 PM