IIRF doesn't always seem to run

Topics: Developer Forum, Project Management Forum, User Forum
Jan 27, 2010 at 4:02 PM

Currently running Ionic ISAPI Rewriting Filter (IIRF) 2.0.1.15 RELEASE and noticed a few strange things happening.

I have the IIRF.dll file and a global .ini file set up in a Windows folder. This is then set up as an ISAPI filter in IIS6 for the default website and shows as running.

I've then got a .ini file in one of my applications. Visiting iirf status usually shows that everything is running ok and there are no errors.

However, sometimes if I navigate directly to a URL that should be processed by the rules in my ini file, I get page not found and again nothing in the log. Sometimes refreshing the page seems to kick IIRF into life and it will then process the rewrite rule and show the page. Other times you have to goto the root of the application, then try a page again and it will work. This doesn't happen 100% of the time though. In addition if I am getting page not founds, I won't be able to view IIRF status either.

The problem definitely seems random, and only happens sometimes.

Does anyone have any ideas?

Coordinator
Jan 27, 2010 at 11:04 PM

a stale cache can cause this . 

If IIRF does not "run" it means the request never arrived at IIS. 

You can verify this by checking the IIS log.  IIS will have a log that shows the request arriving at the server.  all requests sent to the IIRF-configured site, will also be logged in the IIRF log file.  If there is no log statement in either log file, then the request didn't arrive at IIS.

You can also hook up an HTTP Debugging proxy like Fiddler to your browser, and check outgoing requests with that. 

With all of this diagnostic information, you will be able to see which requests went out, and which requests were received, etc.  Takes the mystery out of it.

 

Jan 28, 2010 at 7:33 AM

Cheeso,

 

Thanks for these pointers, they are very useful. I’ll do as you suggested and see what I can dig up and post the results.

 

Thanks!

Andy

 

From: Cheeso [mailto:[email removed]]
Sent: 28 January 2010 12:04 AM
To: [email removed]
Subject: Re: IIRF doesn't always seem to run [IIRF:82200]

 

From: Cheeso

a stale cache can cause this . 

If IIRF does not "run" it means the request never arrived at IIS. 

You can verify this by checking the IIS log.  IIS will have a log that shows the request arriving at the server.  all requests sent to the IIRF-configured site, will also be logged in the IIRF log file.  If there is no log statement in either log file, then the request didn't arrive at IIS.

You can also hook up an HTTP Debugging proxy like Fiddler to your browser, and check outgoing requests with that. 

With all of this diagnostic information, you will be able to see which requests went out, and which requests were received, etc.  Takes the mystery out of it.

 

Read the full discussion online.

To add a post to this discussion, reply to this email (IIRF@discussions.codeplex.com)

To start a new discussion for this project, email IIRF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

Feb 10, 2010 at 5:00 AM
Edited Feb 10, 2010 at 5:10 AM

Hi Andy113

 

did you find the root of the problem?

I'm currently having the exact same issue.

 

Thanks

Feb 10, 2010 at 7:56 AM

Hi makulit,

I did start looking into it using the methods Cheeso suggested, but didn't get very far. Fiddler was definitely showing the requests going out, but I didn't get as far as checking the IIS logs to see if the requests were received. The failed requests definitely didn't appear in the IIRF log (which makes sense I suppose).

Interestingly, this only appeared to be an issue on our production server - when I moved it across to our live server (running IIS7 and WS2008 rather than IIS6 and WS2003), the problem disappeared.

What is your setup like? Are you IIS6 / WS2003 too?

Andy

 

Feb 10, 2010 at 8:31 AM

Andy,

yes, I do have IIS6 / WS2003 too

I have done a little investigation on my side and noticed that the failed requests are definitely coming to IIS and then being redirected to our custom 404 page (set in the website custom errors). However, just like you there is no trace of that request whatsoever in the IIRF logs.

This is where I'm stuck so far. I'm now trying to figure out why those requests are not sent to the rewrite filter.

Mak

Feb 10, 2010 at 9:07 AM

Mak,

Out of curiosity, is your server located on a LAN or are you accessing it over the web?

With ours, it's on our LAN (but has a web address pointed at it). The problem only occurs when I'm in the office and it's technically a 'local' request. If I run similar requests from a remote machine out of the office, I can't replicate the problem.

Very strange..

Andy

 

Feb 10, 2010 at 9:17 AM

I've got several servers on the same LAN, but I am accessing them from outside via a web address

The problem happens on all

I'm currently trying to replicate the issue while having the IIS logs on. I just wanna make sure it does actually appear in the logs, though the 404 custom page I get, for me, means that it so going through IIS but not the filter.

I have been unable to replicate the issue for the last 30 minutes. Maybe because the load on our servers at this time of the day is usually less than a few hours ago.

 

Cheeso, could it be related to load? any idea why IIS would get the request but not forward it to the filter? or could there be a possibility that, for any unknown reason, the filter is getting it but returning it as it is without having it go through the rules and without showing it in the logs?

Thanks

Feb 10, 2010 at 10:07 AM

Well, strangely enough, the problem doesn't happen on the servers for which I enable IIS logs. :-S

As soon as I disable the logs, I start replicating the problem again....

I can't leave the logs on so I'm a bit lost on how to tackle the issue...

 

Coordinator
Feb 10, 2010 at 12:46 PM

The problem you guys are describing should not be related to load.  Load problems generally show one or two major symptoms: 

1. crashes - where IIRF is working and then it stops working, as IIS restarts itself.  This is usually evidence of a bug in IIRF or a bug in your rules.  Examining the Windows Event Log will show such crash/restart problems.  But the symptom you would observe is: iirf is working, and then it experiences a long delay for several requests, then it begins working again.

2. "503 service unavailable" responses. This is what you see after a series of repeated crashes, as IIS decides to give up on restarting the failing process.

You are not seeing that.  You are seeing, no IIRF activity at all.   In my experience, this happens only when IIRF is not actually configured correctly.   Either the ISAPI is not configured, or the rules are incorrect. 

My best suggestion is to use the 3 sources of diagnostic information I described previously - Fiddler, IIS Logs, IIRF Logs -  to verify that the requests are being (a) sent out, (b) received by IIS, and (c) received by IIRF.   If it is being sent out but not received by IIS (no IIS log messages for the request), you may hae a cache issue, where some intermediate server is returning the result from cache.  If it is being received by IIS but not IIRF (eg no IIRF log messages but you do get IIS log messages), check that IIRF is enabled for the particular website or vdir.   If it is being received by IIRF and not processed as you expect, check your IIRF rules.

 

 

Feb 19, 2010 at 9:16 PM

I would like to add that I am experiencing the same (or similar) problem.  If I navigate to the page, I may or may not receive a 404 page.  If I just sit there and refresh over and over about once every couple of seconds, I will get the correct page once followed by the 404 page a couple of times.  Then I will get the correct page, and then the 404 page a couple more times.  That seems pretty consistent, so it looks like the successful rewrite does something that shuts it down for a couple of seconds.  I enabled the IIRF log, and I can see the rewrites for the times the correct page displayed.  I see no hint of the requests that hit the 404 page.  Between the successful rewrites, I see requests for other pages for which there is no rewrite rule (that's expected).  Fiddler shows all the requests being sent, and it shows the correct cache settings on the successful results (HTTP 1.0 Expires header, HTTP 1.1 cache control header, and pragma header).

When I enable IIS logs, the problem stops!  When I disable IIS logs, the problem immediately resumes.  This is exactly the same thing that makulit experienced.  What does that tell us?

TNTitan

Coordinator
Feb 20, 2010 at 8:03 PM

Thank you for the additional information and corroboration.

Are you seeing the w3wp.exe stopping and restarting?  Between requests, do you get a different process ID? You suggested that a successfull rewrite seems to be shutting down IIRF for a few seconds.  This would be consistent with a bug in IIRF that caused a crash - then IIS would automatically restart w3wp.exe. 

Do you have other rules in your ini file that could be causing a problem? 

If it were the case that a crash was occurring, you will get a new IIRF log file, and the process ID shown in the logfile will be different. Is that what you're seeing?

As for why enabling the IIS log changes the behavior, I don't know why that would be.  

Who is responding with the 404?  Is it IIS?   It apparently is not IIRF. 

It could be a bad IIS cache.  With IIS logs enabled it's possible that the IIS kernel-mode cache is not being used.

 

Feb 20, 2010 at 8:56 PM

Hi, Cheeso.

  1. I am not seeing the w3wp service restarting in the system event log (I assume that's where I should be looking).  It does not seem to be crashing.  As confirmation, I executed an ASP page that runs for a couple of minutes and replicated the IIRF failure several times while the page was running.  It successfully finished, so that tells me that w3wp stayed up the whole time it was running.
  2. I only have one rule which you can see in the log below.
  3. I only get one IIRF log.  Here is the beginning of the log.

    Sat Feb 20 16:22:19 -  5012 - -------------------------------------------------------
    Sat Feb 20 16:22:19 -  5012 - Ionic ISAPI Rewriting Filter (IIRF) 2.0.1.15 RELEASE
    Sat Feb 20 16:22:19 -  5012 - IIRF was built on: Dec  3 2009 11:49:15
    Sat Feb 20 16:22:19 -  5012 - Cached: DLL_PROCESS_ATTACH
    Sat Feb 20 16:22:19 -  5012 - Cached: Process ID: 5116
    Sat Feb 20 16:22:19 -  5012 - Cached: DLL_PROCESS_ATTACH - complete
    Sat Feb 20 16:22:19 -  5012 - Cached: GetFilterVersion
    Sat Feb 20 16:22:19 -  5012 - GetLogFile: app:'/LM/W3SVC/1546685392/Root'  new log:'c:\temp\iirfLog.5116.log'
    Sat Feb 20 16:22:19 -  5012 - ReadSiteConfig: actual log file 'c:\temp\iirfLog.5116.log'
    Sat Feb 20 16:22:19 -  5012 - ReadSiteConfig: ini file: '[path removed by TNTitan]\Iirf.ini'
    Sat Feb 20 16:22:19 -  5012 - ReadSiteConfig: ini file timestamp: 2010/02/20 16:22:18 Eastern Standard Time
    Sat Feb 20 16:22:19 -  5012 - ReadSiteConfig: line   4: LogLevel = 3
    Sat Feb 20 16:22:19 -  5012 - ReadSiteConfig: line   1: StatusUrl /iirfStatus
    Sat Feb 20 16:22:19 -  5012 - ReadSiteConfig: line   1: StatusUrl is enabled for local requests only.
    Sat Feb 20 16:22:19 -  5012 - ReadSiteConfig: line  16: RewriteRule (rule 1)  '^/([a-zA-Z0-9_\-]+)/([a-zA-Z0-9_\-]+)/?$'  '/StateLakes.asp?Country=$1&State=$2'   (null)
    Sat Feb 20 16:22:19 -  5012 - ReadSiteConfig: Done reading, found 1 rules (0 errors, 0 warnings) on 17 lines
    Sat Feb 20 16:22:19 -  5012 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:19 -  5012 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:19 -  5012 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:19 -  5012 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:19 -  5012 - HttpFilterProc: SF_NOTIFY_AUTH_COMPLETE

    Here is the log just before and after the rule being processed:

    Sat Feb 20 16:22:22 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:22 -  3840 - HttpFilterProc: cfg= 0x08082A40
    Sat Feb 20 16:22:22 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:22 -  3840 - HttpFilterProc: cfg= 0x08082A40
    Sat Feb 20 16:22:22 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:22 -  3840 - HttpFilterProc: cfg= 0x08082A40
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_AUTH_COMPLETE
    Sat Feb 20 16:22:25 -  3840 - DoRewrites
    Sat Feb 20 16:22:25 -  3840 - DoRewrites: Url (no decoding): '/USA/Alabama'
    Sat Feb 20 16:22:25 -  3840 - EvaluateRules: depth=0
    Sat Feb 20 16:22:25 -  3840 - EvaluateRules: Rule 1 : 3 matches
    Sat Feb 20 16:22:25 -  3840 - EvaluateRules: Result (length 41): /StateLakes.asp?Country=USA&State=Alabama
    Sat Feb 20 16:22:25 -  3840 - EvaluateRules: depth=1
    Sat Feb 20 16:22:25 -  3840 - EvaluateRules: Rule 1 : -1 (No match)
    Sat Feb 20 16:22:25 -  3840 - EvaluateRules: returning 0
    Sat Feb 20 16:22:25 -  3840 - EvaluateRules: returning 1
    Sat Feb 20 16:22:25 -  3840 - DoRewrites: Rewrite Url to: '/StateLakes.asp?Country=USA&State=Alabama'
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_AUTH_COMPLETE
    Sat Feb 20 16:22:25 -  3840 - DoRewrites
    Sat Feb 20 16:22:25 -  3840 - DoRewrites: Url (no decoding): '/StateLakes.asp?Country=USA&State=Alabama'
    Sat Feb 20 16:22:25 -  3840 - EvaluateRules: depth=0
    Sat Feb 20 16:22:25 -  3840 - EvaluateRules: Rule 1 : -1 (No match)
    Sat Feb 20 16:22:25 -  3840 - EvaluateRules: returning 0
    Sat Feb 20 16:22:25 -  3840 - DoRewrites: No Rewrite
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_URL_MAP
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: cfg= 0x08082620
    Sat Feb 20 16:22:25 -  3840 - HttpFilterProc: SF_NOTIFY_AUTH_COMPLETE
  4. The 404 page is a custom 404 page that I assume could only be coming from IIS.
  5. If it's a bad IIS cache, how would I test that theory or correct the problem?

TNTitan

Coordinator
Feb 20, 2010 at 11:20 PM
Edited Mar 26, 2010 at 6:20 PM

You are getting 10 SF_NOTIFY_URL_MAP calls - that seems unusual, and I don't know why you'd get that.  One per request is normal, two is normal, 10 is unusual.  I think you have a strange configuration that is causing this. Do you have IIRF registered multiple times?  Do you have other ISAPI filters registered that would affect this?

You said you assumed the 404 was from IIS.  Why assume?  Can you not modify the 404 page for IIS and verify that IIS is, or is not, the source of the 404? 

I don't know about verifying the IIS cache - for that you should try www.iis.net .  I don't do IIS support.   But I believe that Logging in IIS disables the kernel cache.  That you see no entries in the IIRF log when you get the spurious 404 suggests that the 404 result is being served from a cache somewhere.  That you DON'T get a spurious 404 when IIS logging is enabled suggests that the IIS kernel cache is either corrupted or exhibited some other anomalous behavior.    For more on this I suggest www.iis.net or search: http://www.bing.com/search?q=IIS+kernel+cache+clear&FORM=QBHP 

You wrote:

> As confirmation, I executed an ASP page that runs for a couple of minutes and replicated the IIRF failure several times while the page was running.

That doesn't confirm that w3wp.exe did not crash.  On server machines it's possible and common to have multiple w3wp.exe running concurrently.  So your ASP page can run for 2 minutes in one w3wp.exe, while another w3wp.exe may be started and stopped.  However, if you aren't getting a new IIRF log file, that indicates that there is no stop/start of the IIS process, no crash.   

I suggest to you that because of the effect of IIS Logging on the behavior you observed, the problem is not in IIRF.  It is a problem in IIS.  (or further upstream, see my message below). When IIRF receives the request, IIRF behaves properly.   In some cases, according to the IIRF logfile, IIS is not delivering the request to IIRF.  Therefore the fix or workaround to this problem is not in IIRF.

 

 

Mar 26, 2010 at 4:39 PM

We are experiencing the very same problem. Any news on this? Even this is an IIS messup, it did not manifest on previous versions. We are using the same servers and only with v2 we get the 404 pages.

Coordinator
Mar 26, 2010 at 6:13 PM
Edited Mar 26, 2010 at 6:14 PM

The other possibility that occurs to me, as I Re-read this thread, is that the requests are not being satisfied by IIS at all, but are being handled by some upstream cache.  In the HTTP protocol, any network device or application has the capability to perform caching, and satisfy results from their cache where it makes sense. 

If IIRF is not seeing the request at all, one possibility is that it is not configured properly, as I stated above.  In that scenario, IIS receives the request but doesn't hand it to IIRF.  Seeing the request logged in the IIS logs, but not in the IIRF logs, would indicate that.

Another possibility is that the request is never arriving at the IIS for which IIRF is configured. In this case you would NOT see a request in the IIS log, nor would you see one in the IIRF log.  This would indicate an upstream device or application is handling the request.

I don't have a good suggestion for troubleshooting that. One way I try to "turn off" inline caches is to add a timestamp or nonce parameter in the querystring of a request.  The param need not be important to the intended receiving application.  However, by using a different timestamp or nonce with each request, the inline HTTP devices or apps must treat it as a completely distinct request, and cannot satisfy it from any caches they might maintain. 

Another way to do this is to use the HTTP Headers defined specifically for the purpose of directing apps to NOT use their caches:  "Pragma: no-cache" or "Cache-Control: no-cache" .  But appending a querystring param is easier to do when making a request from a browser.

If you see bad results only when you haven't asked that caches not be used, it would indicate a problem in the mid-stream caches, not a problem in IIRF.

If that doesn't solve the problem, I don't have other suggestions.

 

Coordinator
Mar 26, 2010 at 6:19 PM

Hello pece,

I understand you're having problems.  I wrote about 3 pages of suggestions in the previous messages in this thread.  Your message does not indicate that you've tried any of the troubleshooting suggestions that I made.  You haven't described what you see in the IIS logs, nor in the IIRF logs, nor in a Fiddler trace.

I can't solve your problem for you.  I can only make suggestions.  I've done so.  It's up to you to use those suggestions and figure out what's happening.

The troubleshooting might sound like a hassle; you just want it to work.  But I can't diagnose and fix the mysterious problem you are seeing, from where I sit.  You'll need to do some legwork for yourself.

 

Apr 2, 2010 at 3:08 AM

Just thought I chime in here since I was having the same issue. Turning on IIS logging seems to resolve the issue, no more 404 pages, so that works for me. Keep up the great work. I think I'll be donating some cash :-)

Apr 4, 2010 at 8:51 AM

 

I thought I'd let people in this thread know what we decided to do since my last message almost 2 months ago.

Well, after looking at this problem for a long time, we haven't found any proper solution.

so we have decided to enable the IIS logs with the minimal information so as to not take up too much space on our servers.

This works fine and since that time we haven't had any single problem.

Cheeso I would really appreciate (and I'm sure, also other people in this thread) if you could check on this problem and find a proper fix.

If you read the comments carefully above, you will notice that when the problem happens:

- IIS gets the request but sends it to the 404 page (refreshing a few times would get the correct page, and then the 404 page again, and so on...)

- there is no trace of the request in the IIRF logs which means the request didn't get to IIRF

- enabling the IIS logs stops the problem

My guess on this would be that there is an issue with the way the filter is interacting with IIS in case of heavy load on the server. There must be a reason why IIS cannot forward the request to the filter and thus end up showing the 404 page. Could it be that the filter cannot handle the huge number of continuous requests? but then why would enabling the IIS logs stop the problem? is it because IIS is slowed down because of that extra process and so requests are coming slower to IIRF?

I really don't know and I'm only trying to guess here with a very limited knowledge on IIS.

any input on this?

 

Coordinator
Apr 4, 2010 at 1:10 PM

MAkulit,

glad to have the update.   I can continue to work with you on this but I don't have a good way to reproduce the problem so I don't have much hope of diagnosing it solely from here.  But maybe through cooperation we can figure this out.

Certainly the problem has to do with the way the filter interacts with IIS under heavy load.  There's nothing in the filter that would cause it to simply refuse to respond for a request, from time to time, under heavy load.  If it were to do this - In other words, if IIS invoked IIRF, and IIRF did not respond correctly -  IIS would mark the filter or the worker process as unhealthy and unload and recycle it.  

You mentioned "heavy load" but you did not quantify that precisely.  What is the difference in load that you see, when IIS logging is ON versus OFF?  If the server is completely saturated (100% utilized), then I would imagine that you'd see a drop in throughput between the two cases.  On the other hand if the server is not completely saturated, then it's likely that turning IIS logging on or off would result in no real difference in throughput.  Did you measure a change in throughput and CPU utilization? 

If the setting for IIS logging does not materially affect throughput, yet it does affect the actual behavior of the 404 error, then that suggests that your theory that the problem is due to a load-related issue within IIRF, is not correct.  Does that make sense?  It suggests instead that a problem in the request handling in IIS is causing the request to not reach IIRF.

Previously I offered some other theories that the problem may be related to upstream caching.  Have you investigated those possibilities?

If you find that the problem is readily reproducible and you have the ability to test it, I'd be interested in finding out if kernel mode caching has an effect. You already reported that IIS logging has an effect; what about kernel caching?   Disable the kernel mode cache, and observe to see if the problem continues.  I'd also like to see data on throughput and CPU utilization through all these situations.

I'm also not clear - have you understood where the 404's are coming from?  Have you used Fiddler or another client-side proxy to examine the transaction that results in a 404?  Did you examine the headers and ascertain that the response is a fresh one from IIS and not from any cache?   Did you try as I suggested the various techniques for disabling the client-side cache?

I think there's a bunch of work you could do to diagnose this.  I'm very interested in any information you can provide, and I'll be happy to discuss it further with you.  On the other hand I understand if you'd rather just let it be, since it appears to be working for you now.

Jun 11, 2010 at 3:23 PM
Hi guys I've also been having the same problem outlined by makulit, under Windows 2003 Server and IIS6. Disable logging in IIS and IIRF doesn't seem to refresh the rules (at least not immediately) following a change to iirf.ini. Enable logging in IIS and IIRF refreshes the rules immediately following a change to iirf.ini
Coordinator
Jun 16, 2010 at 9:12 PM

I don't know what you mean by "doesn't seem to refresh the rules (at  least not immediately)" . 

IIRF v2.x checks if the rules file has been updated with each request.  in this way, IIRF will refresh the rules, as necessary, when it gets a new request, if IIRF does not use the new rules, it means that Windows has returned an old timestamp for the (purportedly) updated iirf.ini file.  You may need to "close" the IIRf.ini file in the editor you use, in order for the changes to be visible to IIRF --  in other words in order to allow Windows to report the proper timestamp for that file to IIRF when a new request arrives.

In IIRF v1.2, IIRF used a filesystem "watcher" thread, that would re-read the IIRF.ini file (actually in that release, the ini file was called IsapiRewrite4.ini) automatically whenever the file changed, whether or not a request was pending.  This model has changed for IIRF v2.0.  There were some problems with the v1.2 approach, that were similar to what you report - sometimes the updated rules file would not be read immediately.  Sometimes not at all.   In any case that design is no longer used in IIRF v2.0.   Also, IIRF v1.2 is no longer "supported" so if you're using it, please upgrade.

 

Jun 18, 2010 at 2:30 PM

Cheeso, thanks for the detailed response.

 

Using IIRF v2.x, under Windows Server 2003 R2 with IIS 6 and IIS logging disabled, I can assure you that IIRF is not refreshing the rules. The timestamp on the iirf.ini file is most definitely updated following a rule change and not open in any editor.

 

Enable IIS logging and the problem resolves itself. However, like previous posters on this thread, I don't really want to have IIS logging enabled.

 

Coordinator
Jun 18, 2010 at 4:51 PM

Colani, that is a surprise.

I'd like to see an IIRF logfile showing one request flowing through the filter, showing the problem you describe.  I just checked the code; the timestamp check is logged only at log levels 4 or above. 

I said above that for each request, IIRF checks to see if the rules file has been updated.  In more detail, IIRF checks the "last update" timestamp of the ini file, and compares it to the stored value of the "last update" timestamp of the file which IIRF stores when reading the ini file.  The logfile will not show the value of the timestamps, but it will show the outcome of the comparison.  to diagnose the situation you describe, I may have to change the logging to show the actual timestamps being compared.

If what you observe is true, something is causing IIRF to either not "see" the correct (updated) timestamp, or fail the comparison in some other way. I'm trying to imagine how either of these problems might occur, and so far my imagination is failing me!