IIS wrongly reports 'Permission Denied'

R

Richard Shea

Hi - I have an ASP script which does numerous writes via FSO using ...

Function LogActivity(strText)
Dim fso, f
Dim strTime
strTime = ABCNOW()
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso_OpenTextFile((ABC_OS_ROOT_PATH & "ABCMAINLOG.txt"), 8,
True)
f.WriteLine strTime & " " & strText
f.close
End Function

.... We have recently tripled the number of users using the app have
found that IIS is intermittently reporting 'Permission Denied' while
writing to the log. You can try again a moment later and all will be
well. Has anyone seen this ? It seems very strange that W2K can't deal
with multiple processes/threads writing to the same file without
getting itself confused ! To give you an idea of volume the script is
being invoked up to twice a second at peak times and each invocation
results in approx 150 calls to the above function. That doesn't seem
particularly radical to me but ... By the way the incidence of the
problems seems to be proportional to both the size of the file and the
density of the script requests.

There is a post in this newsgroup from a couple of months back ...

http://tinyurl.com/jyjk

.... which seems to be about the same issue but nothing much in the way
of a reply.

Does anyone know of any known issue with W2K/IIS/FSO which might make
it behave this way ?

regards

Richard Shea.
 
A

Alan

I don't think it's magic - it's just that one process is locking the file
for the update and another process is trying to get access - the same thing
happens with databases, source code control systems, the Application object
(if you use the Lock() method), etc... The longer your files are of course
the longer it'll take to do each update, and the longer the lock will
persist. My logger classes normally start a new log each day - this keeps
file sizes down.

You need to avoid or handle the error. You could use a loop with On Error
Resume Next that continues until a valid reference to the TS is returned
(watch out for infinite loops), or you could arbitrate access by using a
global semaphore/flag that you store in the Application object. When your
logger class gets a reference to the TS it sets the flag and clears it on
release - other instances of your log class enter a wait state (a queue)
until the flag clears. If you wanted to get really tricky maybe MSMQ would
hold some ideas.

Cheers,

Alan
 
R

Richard Shea

Alan said:
I don't think it's magic - it's just that one process is locking the file
for the update and another process is trying to get access - the same thing
happens with databases, source code control systems, the Application object
(if you use the Lock() method), etc... The longer your files are of course
the longer it'll take to do each update, and the longer the lock will
persist. My logger classes normally start a new log each day - this keeps
file sizes down.

Good idea. We hadn't foreseen the volume of logging that would result
from the system being used in production and this type of approach
would certainly have helped !
You need to avoid or handle the error. You could use a loop with On Error
Resume Next that continues until a valid reference to the TS is returned
(watch out for infinite loops), or you could arbitrate access by using a
global semaphore/flag that you store in the Application object. When your
logger class gets a reference to the TS it sets the flag and clears it on
release - other instances of your log class enter a wait state (a queue)
until the flag clears. If you wanted to get really tricky maybe MSMQ would
hold some ideas.

You've made clear to me that my model of how W2K handles this type of
file was wrong. I was thinking that by default W2K would allow
multiple processes to open and write to the file and would arbitrate
between them. On reflection that was probably a bit hopeful ! Thanks
for the suggestions above for the moment I'm looking at moving the
logging to a database table but if that's too slow I'll try out some
of the above.

regards

richard shea.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top