Attended an introductory session on Windows Server App Fabric given by one of my new colleagues Charan Bhatia.
It was a useful one, with a candid introduction to the tool for someone like me, who never knew anything other than its name.
From what I remember and what I understood at a higher level, App Fabric is a monitoring tool that monitors the WCF web services hosted on IIS 7.x or above. The services should be built on .Net Framework 4.0. App Fabric was designed keeping in view its use for Azure.
The minimum pre-requisites include IIS 7.x, WAS, services built on .Net Framework 4.0.
There were some contructive questions as well, like,
How App Fabric differs from WCF trace and diagnostics utilities?
Answer: App Fabric has much more advanced features compared to the WCF trace and diagnostics. For example, Distributed Caching, etc., which will be dealt with in the next session on this Friday (11/02/2011)
Can we monitor classic web services (.asmx) in the same way as WCF through App Fabric?
This proved to eb a good question as Charan was really interested in researching on it and coming up with an answer soon.
Is there a way we can configure the App Fabric such that it only monitors a subset of the services deployed on the server?
Answer: Yes, of course. We have to decrease the level of monitoring to the least level (which means "Off") at the service level, for whichever services we don't want the it to monitor.
It was an interesting and useful session, evident fromt he way it was stretched almost unknowingly, from the scheduled 30 minutes to around 90 minutes.
The second part of the session is scheduled on this Friday (11/02/2011). This deals with, Distributed Caching through Windows Server App Fabric.
will update the proceedings once that is done.
Wednesday, March 09, 2011
Thursday, May 27, 2010
Today's importance
Birthday of the legendary NTR (Nandamuri Taraka Rama Rao), who was born on 28th May, 1923.
He was awarded with Padma Sri by the Government of India in 1968 and was popularly adored as Viswa Vikhyatha Nata Saarvabhowma.
Person who brought a distinguished identity to Andhra Paadesh as a state and recognition to the Telugu language. He will be remembered as long as Telugu is be spoken.
He was awarded with Padma Sri by the Government of India in 1968 and was popularly adored as Viswa Vikhyatha Nata Saarvabhowma.
Person who brought a distinguished identity to Andhra Paadesh as a state and recognition to the Telugu language. He will be remembered as long as Telugu is be spoken.
Tuesday, May 18, 2010
Thursday, May 13, 2010
Script Resource and HTTP 304
Here are my findings on HTTP 304’s -
Issue – HTTP 304 every time a page(rendered html) has reference to ScriptResource.axd or WebResource.axd. this reference is added by Ajax tool kit.
Context – ScriptManager adds .axd references in the rendered html as below to get the javascript support for AJAX.
User Impact –
The user is neither being redirected to the error page, nor getting any AJAX/functionality errors. But, some server traffic-monitoring softwares like the tea-leaf show them as errors in their statistics.
Probable Cause –
The actual page is being rendered with #pragma set to ‘no-cache’. So, when the page is refreshed, it is trying to load again from server.
When we verify the request/response headers –
The request headers for the page and the .axd files have cache-control set to ‘no-cache’.
While the page response still has ‘no-cache’, the .axd file response (with 304 status) has ‘public’, which means the file can be cached.
Based on the response header’s cache control value, it is trying to verify the .axd file version with cached version and hence, the HTTP 304 – ‘Not Modified’ error. 304 basically says, the resource is not modified from its last cached copy.
Possible Fixes –
Extend the ScriptResourceHandler (that implements IHttpHandler) and Override the ProcessRequest method.
The fix for this should either be – force-get the .axd files as if they are not cached OR use only the cached version of the .axd files.
For the first fix –
Set the Expires property to a past date which would effectively set the cache-control to ‘no-cache’.
Setting cache-control to ‘no-cache’ is also necessary to handle the behaviour on all browsers.
For the second fix – (this may NOT be the recommended one)
Set the status code of the response in the HttpContext to ‘200’ if it is ‘304’.
The first fix can have a slight impact on performance, but consistent.
The second fix is not really consistent(, at least when I verified). Theoritically it should work and it should have no impact on performance.
To replicate the issue, do browser refresh on any that has ScriptManager. Use Fiddler or similar software to view the 304-response.
MY CONCLUSION ON THIS -
From my knowledge and analysis on HTTP 304’s, I’ve found that this is a FEATURE of HTTP rather than a bug. That’s the right message the server is sending in accordance with Http protocol, and it is not an error/warning message, but just a status message.
304 basically says, the resource is not modified from its last cached copy and the browser can load it from its local cache. This way, it avoids the resource being unnecessarily transferred between client and server, thereby, enhancing the performance of the application.
Some iis traffic-monitoring softeware, like the Tea leaf can misread it as an error, while it is actually a feature. They will have to be configured accordingly.
Issue – HTTP 304 every time a page(rendered html) has reference to ScriptResource.axd or WebResource.axd. this reference is added by Ajax tool kit.
Context – ScriptManager adds .axd references in the rendered html as below to get the javascript support for AJAX.
User Impact –
The user is neither being redirected to the error page, nor getting any AJAX/functionality errors. But, some server traffic-monitoring softwares like the tea-leaf show them as errors in their statistics.
Probable Cause –
The actual page is being rendered with #pragma set to ‘no-cache’. So, when the page is refreshed, it is trying to load again from server.
When we verify the request/response headers –
The request headers for the page and the .axd files have cache-control set to ‘no-cache’.
While the page response still has ‘no-cache’, the .axd file response (with 304 status) has ‘public’, which means the file can be cached.
Based on the response header’s cache control value, it is trying to verify the .axd file version with cached version and hence, the HTTP 304 – ‘Not Modified’ error. 304 basically says, the resource is not modified from its last cached copy.
Possible Fixes –
Extend the ScriptResourceHandler (that implements IHttpHandler) and Override the ProcessRequest method.
The fix for this should either be – force-get the .axd files as if they are not cached OR use only the cached version of the .axd files.
For the first fix –
Set the Expires property to a past date which would effectively set the cache-control to ‘no-cache’.
Setting cache-control to ‘no-cache’ is also necessary to handle the behaviour on all browsers.
For the second fix – (this may NOT be the recommended one)
Set the status code of the response in the HttpContext to ‘200’ if it is ‘304’.
The first fix can have a slight impact on performance, but consistent.
The second fix is not really consistent(, at least when I verified). Theoritically it should work and it should have no impact on performance.
To replicate the issue, do browser refresh on any that has ScriptManager. Use Fiddler or similar software to view the 304-response.
MY CONCLUSION ON THIS -
From my knowledge and analysis on HTTP 304’s, I’ve found that this is a FEATURE of HTTP rather than a bug. That’s the right message the server is sending in accordance with Http protocol, and it is not an error/warning message, but just a status message.
304 basically says, the resource is not modified from its last cached copy and the browser can load it from its local cache. This way, it avoids the resource being unnecessarily transferred between client and server, thereby, enhancing the performance of the application.
Some iis traffic-monitoring softeware, like the Tea leaf can misread it as an error, while it is actually a feature. They will have to be configured accordingly.
Subscribe to:
Posts (Atom)