"當ScriptTimeout發生時,ASPX會繼續執行? 還是嘎然而止?"

以上問題的答案將牽動IIS的調校哲學,當系統發生問題時而導致大量Request處理逾時,調整ScriptTimeout的長短,會產生何種效應?

在過去的印象中,如果使用者開啟一個要執行很久的ASP/ASPX程式,在程式未執行完成之前,使用者關閉瀏覽器時,ASPX仍會繼續跑完,不受與使用者間連線中斷的影響。我用以下的Code進行驗證...

   1:  private void writeLog(string msg)
   2:  {
   3:      using (System.IO.StreamWriter sw =
   4:          new System.IO.StreamWriter("d:\\temp\\longrun.log", true))
   5:      {
   6:          sw.WriteLine(
   7:              string.Format("{0:yyyy-MM-dd HH:mm:ss.fff} {1}",
   8:              DateTime.Now, msg
   9:          ));
  10:      }
  11:   
  12:  }
  13:  protected void Page_Load(object sender, EventArgs e)
  14:  {
  15:      //Write start log
  16:      writeLog("Start!");
  17:      //Wait for 20 seconds
  18:      System.Threading.Thread.Sleep(20000);
  19:      //Write end log
  20:      writeLog("Finished!");
  21:  }

測試時,開啟IE連上該網頁後立即將IE關閉。20秒後檢查longrun.log,可以看到相隔20秒的兩列Log。於是我們得到證明: 使用者關閉Browser並不妨礙ASPX繼續執行

2007-06-21 04:20:51.814 Start!
2007-06-21 04:21:11.832 Finished!

那麼,當ScriptTimeout發生時又是如何? 我將web.config <httpRuntime> executionTimeout設為5秒,跑了以下的程式:

   1:  protected void Page_Load(object sender, EventArgs e)
   2:  {
   3:      //Write start log
   4:      writeLog("Start!");
   5:      for (int i = 0; i < 30; i++)
   6:      {
   7:          System.Threading.Thread.Sleep(1000);
   8:          //One log per second
   9:          writeLog("Loop-" + i.ToString());
  10:      }
  11:      //Write end log
  12:      writeLog("Finished!");
  13:      //Response.Write something    
  14:      Response.Write("Done!");
  15:      Response.End();
  16:  }

大約5-15秒左右(依據這串討論中MS Online Support的說法,ScriptTimeout小於1分鐘,會有5-15秒的延遲),網頁傳回以下的錯誤:
[HttpException (0x80004005): Request timed out.]

在Log則看到有趣的事,30圈的Loop沒有跑完,在i==5時停住了。

2007-06-21 04:26:50.561 Start!
2007-06-21 04:26:51.561 Loop-0
2007-06-21 04:26:52.561 Loop-1
2007-06-21 04:26:53.561 Loop-2
2007-06-21 04:26:54.561 Loop-3
2007-06-21 04:26:55.561 Loop-4
2007-06-21 04:26:56.561 Loop-5

不過我們還不滿足,希望得到更明確的ScriptTimeout證據。但,程式都中止了,還能再做些什麼事? 之前談過Response.End時產生的ThreadAbortException可以被catch抓到,而我猜ScriptTimeout所引發的中止應該也可以被catch捕捉下來。於是改寫Code如下:

   1:  protected void Page_Load(object sender, EventArgs e)
   2:  {
   3:      //Write start log
   4:      writeLog("Start!");    
   5:      try
   6:      {
   7:          for (int i = 0; i < 30; i++)
   8:          {
   9:              System.Threading.Thread.Sleep(1000);
  10:              writeLog("Loop-" + i.ToString());
  11:          }
  12:      }
  13:      catch (Exception ex)
  14:      {
  15:          writeLog("ERROR: " + ex.Message);
  16:      }
  17:      //Write end log
  18:      writeLog("Finished!");
  19:      //Response.Write something    
  20:      Response.Write("Done!");
  21:      Response.End();
  22:  }

Log結果如下:

2007-06-21 04:40:37.580 Start!
2007-06-21 04:40:38.580 Loop-0
2007-06-21 04:40:39.580 Loop-1
2007-06-21 04:40:40.580 Loop-2
2007-06-21 04:40:41.580 Loop-3
2007-06-21 04:40:42.580 Loop-4
2007-06-21 04:40:43.580 Loop-5
2007-06-21 04:40:44.580 Loop-6
2007-06-21 04:40:45.580 Loop-7
2007-06-21 04:40:46.580 Loop-8
2007-06-21 04:40:47.580 Loop-9
2007-06-21 04:40:48.580 Loop-10
2007-06-21 04:40:49.580 Loop-11
2007-06-21 04:40:50.002 ERROR: Thread was being aborted.

抓到了!! cath (Exception ex)抓到了ThreadAbortException。由這項證據可以得知,當程式執行時間超過ScriptTimeout時,W3WP.exe應該是用類似Response.End()的方式強制結束ASPX網頁的執行。

由以上的觀察,我的個人推論是--當程式異常時,設定較短的ScriptTimeout應有助於改善大量Thread被Hang住的狀況,盡早釋放出Resource處理其他仍然健全的功能。但如果程式是卡在Unmanaged World Resource,Thread.Abort並不能讓程式立即由困境中脫身(只能先在Thread上做記號,待控制權交回Managed World時才生效)。另外,以下兩則延伸閱讀中提到Multithread下Thread.Abort可能產生的負面效應,可做為進階設計時的考量。

延伸閱讀:
1.How To Stop a Thread in .NET (and Why Thread.Abort is Evil)
2.Plumbing the Depths of the ThreadAbortException Using Rotor


Comments

Be the first to post a comment

Post a comment


52 + 20 =