Ace probe failure after IIS app pool recycle?

Unanswered Question
Apr 14th, 2010

Windows Server 2003 SP2

ACE Module A2(1.6a)

I suspect this is caused by an IIS6 setting, but posting here in case anyone has seen this.  For this one particular site, we have 4 servers in the farm.  2 of those servers are fine.  The other 2 (new) servers will generate probe failure after the site's app pool recycles.  I then remove the 2 servers from service and re-activate (no inservice, then inservice) and the probe comes back as operational.  It appears that the app pool recycle somehow is resetting the hash on the default page, though I'm not sure how.  Any ideas are very much appreciated. 

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Marko Leopold Wed, 04/14/2010 - 23:53

Do you use the hash command inside the probe? Can you provide configuration?

dan.worstell Thu, 04/15/2010 - 05:54

Yeah, the hash is inside the probe.  Here's the config for the serverfarm and the probe.  Public-007 and Public-008 are new servers...the other 6 have been in the farm for the last 2.5 years and they don't have this issue.  It's only the 2 new boxes that the probe fails when the app pool is recycled.

serverfarm host PUBLIC
  rserver PUBLIC-001
  rserver PUBLIC-002
  rserver PUBLIC-003
  rserver PUBLIC-004
  rserver PUBLIC-005
  rserver PUBLIC-006
  rserver PUBLIC-007
  rserver PUBLIC-008
  interval 2
  faildetect 2
  passdetect interval 2
  passdetect count 2
  request method get url /default.aspx
  expect status 200 200

Marko Leopold Thu, 04/15/2010 - 06:29

Hello Dan!

We ran into same issue here. The documentation says that the ACE is taking the hash from the site that it gets from the server. So far so good, but if this hash is changing the server is marked offline. Problem is, I did not found any coomand to display this hash. Even the "show probe XXX detail" dont show anything. The old CSS was able to show the hash value so you can check it. Question the the crowd: Which command shows me the hash value of the probe?

Maybe you should check if the 2 new server are changing something in the website (maybe something in header) which is sent after the app pool is recycled!


dan.worstell Thu, 04/15/2010 - 06:39

I do believe something is different on the 2 new boxes, but have not yet found what it is.  I just found this in the iis

log.  The app pool recycled at 23:30:11 and we started getting different response from the web server when hitting the default page.  I think this confirms the hash change....

2010-04-14 23:30:07 GET /default.aspx - 80 - - 200 0 0
2010-04-14 23:30:09 GET /default.aspx - 80 - - 200 0 0
2010-04-14 23:30:09 GET /default.aspx - 80 - - 200 0 0
2010-04-14 23:30:11 GET /default.aspx - 80 - - 200 0 0
2010-04-14 23:30:12 GET /default.aspx - 80 - - 200 0 64
2010-04-14 23:30:13 GET /default.aspx - 80 - - 200 0 64
2010-04-14 23:30:13 GET /default.aspx - 80 - - 200 0 64
2010-04-14 23:30:15 GET /default.aspx - 80 - - 200 0 64

dan.worstell Thu, 04/15/2010 - 07:50

I found a utility called simplemd5 that reads the hash for us.  More perplexing is the hash value is the same for the file regardless if the probe has failed or not:

C:\Users\User\Desktop>simplemd5 default.aspx

C:\Users\User\Desktop>simplemd5 default.aspx

dan.worstell Thu, 04/15/2010 - 13:31

We figured it out.  You have to edit the machine.config to support a load balanced environment.  We had already done that for .Net 2.0, but this was the only site running .Net 1.1 on these 2 new boxes. We hadn't edited 1.1 yet.


This Discussion