Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Event ID: 2273 Source: W3SVC-WP

19 views
Skip to first unread message

Mike Price

unread,
Jan 14, 2005, 11:47:06 AM1/14/05
to
I received the message below on one of or web servers and unfortunately there
is now other info I can find to give me insight into what caused this. Once
it was detected I shutdow the WP and then started it again an that fixed the
issue. I am wondering if anyone has any experience with this warning or has
any insight as too why the metabase may have been inaccessable. We recycle WP
everything night at 9:30PM so I could understand if this happened during the
recycle but it happened an hour afterwards. Also, I am confused as to why the
WP was trying to acccess the metabase at that time. I can understand if it
were trying to access the metabase due to a recycle but again that should
have happened an hour earlier.

David Wang [Msft]

unread,
Jan 14, 2005, 11:22:34 PM1/14/05
to
Realistically, you really should not worry about the event unless it
repeatedly happens. IIS should naturally recycle the WP on its own, when
the WP fails to run due to inaccessible metabase. IIS is simply telling you
that something strange happened. Random things can happen - you have no
control what exactly is executing on the server at any given time. If it
becomes chronic, that's when you want to investigate.

Let me clarify your understanding of how IIS works. Unlike Apache, IIS will
dynamically read and apply any setting changes you make in a performant
manner. What this means is that:
1. WP will only read the metadata for requests that it is serving.
2. WP will cache the metadata such that future requests for the same URL
will not need any disk reads
3. WP will be notified if the metadata is changed, so that it can flush that
cache entry and save memory

This means that WP can be trying to read metadata at any time, depending on
whether IIS has processed that request URL before and whether metadata has
changed since caching.

One possible explanation for your situation is that you have some other
process on the server (maybe it was some GPO script, your own
admin/monitoring scripts, etc) which took a lock on the metabase for a long
time, possibly changing many properties while doing server maintenance.
This will naturally cause WP to invalidate there metadata cache entries,
which forces them to look up the values again -- and since this process also
locked the metabase up (it may be doing a long series of operations on the
metabase), it prevents WP from reading the metabase when it needed some
metadata to finish processing a request. Of course, this is a problem with
that other process, and it needs to be fixed.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Mike Price" <Mike...@discussions.microsoft.com> wrote in message
news:2E964F43-F7AF-4464...@microsoft.com...

Mike Price

unread,
Jan 20, 2005, 10:51:04 AM1/20/05
to
David,

Thanks for your reply. Unfortunately the WP didnt recycle or did
recycle and didn't fix the issue because the virtual that uses the WP that
was deteremined to be unhealthy was not working.

David Wang [Msft]

unread,
Jan 20, 2005, 8:14:42 PM1/20/05
to
A process recycle is not a guarantee that it fixes the original problem. It
is simply a corrective attempt and indication that something is wrong on the
server that should be investigated.

I still think that you are running some other process that happens to keep
the metabase locked and prevent w3wp.exe from reading and serving requests.
What is causing that, I do not know -- but that is really an issue for you
to determine because you do not want to be running such bad code.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Mike Price" <Mike...@discussions.microsoft.com> wrote in message

news:4B168F56-EB7E-40D3...@microsoft.com...

0 new messages