04-14-2010 01:02 PM
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.
04-14-2010 11:53 PM
Do you use the hash command inside the probe? Can you provide configuration?
04-15-2010 05:54 AM
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
probe URL-DEFAULT-ASPX
rserver PUBLIC-001
inservice
rserver PUBLIC-002
inservice
rserver PUBLIC-003
inservice
rserver PUBLIC-004
inservice
rserver PUBLIC-005
inservice
rserver PUBLIC-006
inservice
rserver PUBLIC-007
inservice
rserver PUBLIC-008
inservice
probe http URL-DEFAULT-ASPX
interval 2
faildetect 2
passdetect interval 2
passdetect count 2
request method get url /default.aspx
expect status 200 200
hash
04-15-2010 06:29 AM
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!
M.
04-15-2010 06:39 AM
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 10.1.1.1 GET /default.aspx - 80 - 10.1.2.2 - 200 0 0
2010-04-14 23:30:09 10.1.1.1 GET /default.aspx - 80 - 10.1.2.1 - 200 0 0
2010-04-14 23:30:09 10.1.1.1 GET /default.aspx - 80 - 10.1.2.2 - 200 0 0
2010-04-14 23:30:11 10.1.1.1 GET /default.aspx - 80 - 10.1.2.1 - 200 0 0
2010-04-14 23:30:12 10.1.1.1 GET /default.aspx - 80 - 10.1.2.2 - 200 0 64
2010-04-14 23:30:13 10.1.1.1 GET /default.aspx - 80 - 10.1.2.1 - 200 0 64
2010-04-14 23:30:13 10.1.1.1 GET /default.aspx - 80 - 10.1.2.2 - 200 0 64
2010-04-14 23:30:15 10.1.1.1 GET /default.aspx - 80 - 10.1.2.1 - 200 0 64
04-15-2010 07:50 AM
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
F2CA9290F11E5DCF2BE0DED2A675AA1C
C:\Users\User\Desktop>simplemd5 default.aspx
F2CA9290F11E5DCF2BE0DED2A675AA1C
04-15-2010 09:07 AM
mmm strange. but what means the 64 in your last message?
04-15-2010 01:31 PM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: