MSE monitoring and reporting

Topics: Usage Scenarios, Technical Questions
Jan 5, 2009 at 9:09 PM

Does MSE provide monitoring and reporting capabilities, e.g., performance metrics, current state of a service, requests and access to a service, etc.


Jan 7, 2009 at 4:36 PM
Not out of the box, but this discussion does shed some light on how to provide this functionality (

By "current state of the service", if you are referring to the state of the service implementation logic, the MSE doesn't host the service logic, so the only thing it knows is whether the last request resulted in an exception or if the response message is a soap fault contract.  This can be tracked in a message inspector applied to the endpoint or channel and logged.  This would enable reporting to understand success/failure rates of particular service implementations.  You could also do deeper analysis of the responses in the message inspector if your services don't return fault contracts but instead return a message with some sort of indicator of success/failure.
Jan 8, 2009 at 4:04 PM
Thanks for your reply. What I mean "current state of the service" is the health of the individual hosted Endpoint services by the MSE Runtime Server or perhaps the Runtime server itself.

Also, are there "throttling" capabilities that MSE provide that may override or supersede the ServiceThrottlingBehavior class. Perhaps on the Endpoint level where you can set a certain threshold for concurrent call or request to increase performance or throughput.

Other question I have is regarding Notification binding or or how to enable event notification. I couldn't find sufficient document on how to implement this. On the MSE Management console, under Runtime Server setting, even though I've provided values for the Catalog Binding, Notification URI and Notification Binding settings, events such as adding Endpoint; Operation to an Endpoint; or another version of a service operation. I would always need to restart the Runtime Service to enable or reflect the mentioned changes.


Jan 8, 2009 at 5:13 PM
There isn't a built in health check of the virtual service endpoint hosted in the MSE.  These endpoints are WCF ServiceHost instances, so you could leverage the same WCF instrumentation & perfmon integration to observe these endpoints.  Since each MSE hosted endpoint is a WCF ServiceHost you can apply the ServiceThrottlingBehavior to them irrespective of the ServiceThrottling characteristics of the underlying serivce logic (assuming the service logic is a web service).  Note that overall scalability of the MSE endpoint will still ultimately be dependent upon the underlying service logic.

The notifications sent out to the runtimes when a change is made is being changed in our next release.  With the current solution you may run into what you have experienced.  The immediate fix is to stop the Runtime, ReStart the Catalog service and then Start the Runtime.  There are a couple things at play here to keep in mind for the current release:
1) Catalog Server maintains an in memory list of runtime Servers
2) Runtime Servers Subscribe/Unsubscribe on startup/shutdown
3) if the Catalog Server is restarted the subscription list is lost resulting in no notifications being sent to runtimes (always restart runtimes if the catalog service is ever restarted)
4) The Catalog Server also subscribes to changes made in the database... this subscription expires after 8 hours.

To address #4 either restart the Catalog server or change the 'SubscribeToEvent' stored procedure to make sure the subscription lasts longer than 8 hours.

The next release won't have these issues, Runtime Servers and/or Catalog Servers can be restarted in any order and notifications will still be able to be sent.

In addition, if you want to address #1 for your current installations so that the runtime server subscription list is persisted somewhere to improve the overall availability of the solution the Catalog and Repository source code is available for download.
Jan 8, 2009 at 7:00 PM
Not sure on what you meant or how to implement what you've said regarding ServiceThrottlingBehaviour, to quote, "Since each MSE hosted endpoint is a WCF ServiceHost you can apply the ServiceThrottlingBehavior to them ...".

On a web service, this is done through the app.config file for each service baseAddress, where the serviceThrottling attributes, i.e., maxConcurrentCalls could be set. On a MSE hosted Endpoint, are there any application configuration files to do the same?
Jan 8, 2009 at 7:10 PM
In the MSE management console check out the policy "WCF Throttling Override".  This is a policy can be applied to MSE endpoints to configure the ServiceThrottlingBehavior.  Anything you'd tyically do in config for WCF services is done instead through policies (policies are infact just a list of WCF behavior extensions) so that you can dynamically change behaviors w/o having to modify config files.

hope that helps.
Jan 8, 2009 at 7:21 PM
awesome. thanks a lot.
Jan 9, 2009 at 11:37 AM
It's an interesting discussion you have here. You might find this interesting as well

Oct 28, 2009 at 11:23 AM

Has there been any improvements/changes in the current MSE release in this regard? I mean, w.r.t MSE monitoring and Reporting.

- Satish