0

Our ASP.NET MVC application is used to coordinate parallel execution of a 3rd executable that loads records into an ERP system. With some sets of data everything works perfectly. When the set of data gets bigger the 3rd party program gets hung up and never exits even when it is done sending the data.

I ran a test using a batch file with the same level of parallel processing and data and the program works as expected.

It appears that there is something about running in the context of IIS that is causing this. We launch the application from our code using Process.Start().

I have ruled out permissions as the cause already. I also tried checking a box in the IIS Admin Service to allow the service to interact with the desktop but that made no difference.

Are there any other changes to the IIS configuration that are likely to be affecting the way the application runs?

UPDATE I am changing this question because I have now learned that my problem had nothing to do with IIS. It was a deadlock condition caused by the way I was configuring Process.Start(). This problem and it's solution duplicate: ProcessStartInfo hanging on “WaitForExit”? Why? Tim's comment gave the clue needed to ask the right question.

Community
  • 1
  • 1
Matthew MacFarland
  • 2,413
  • 3
  • 26
  • 34
  • any chance to put your effort on a real program or api that feed the ERP, instead of automating app (this is like pandora's box in my opinion) ? – Steve B May 05 '17 at 15:35
  • After you call Process.Start, do you wait for exit or check the exit code anywhere? Synchronous handling can eat a LOT of threads under load. You may also try redirecting stdout and stderr to see exactly what the other exe is doing – Tim Copenhaver May 05 '17 at 15:39
  • @SteveB No, the program we are automating is the only supported option for this particular ERP product. – Matthew MacFarland May 05 '17 at 16:12
  • @TimCopenhaver Yes, we are waiting for the process to exit. The program does not return a meaningful exit code so we must parse the log it produces after it exits. We saw very high thread counts and wondered what that was. We considered using fire and forget and then polling the processes with WMI to know when the parallel batch is done. Do you think that will be more reliable? – Matthew MacFarland May 05 '17 at 16:18
  • @TimCopenhaver You got me looking more closely at Process.Start(). The problem was that I was redirecting standard out and causing a deadlock. Redirect = false (the default) prevents the problem. I have updated this question accordingly and it can be changed to a duplicate by one of the moderators. – Matthew MacFarland May 05 '17 at 20:55

0 Answers0