Hi all....

Microsoft released Beta 2 of ASP.NET AJAX. Although it's a very powerful framework, when you will build a real AJAX site like those out there in the Web 2.0 world, you will face many problems that you will hardly find documented anywhere. In this thread, We will look at the advantages and disadvantages of Batch calls, AJAX call timeouts, browser call jam problem, ASP.NET 2.0's bug in web service response caching, and so on.

thx...

Hi,

The key element that is giving everyone the heebie-jeebies is the term “asynchronous” - in other words we’re going to make a round trip to the server, without actually going there! We’re all used to the normal browser behaviour where a user takes an action, the browser makes an HTTP request to the server, then the server sends a response back.

While it all works just wonderfully, sometimes the results leave a bit to be desired. What AJAX will allow us to do is make a request to the server asynchronously – without making that round trip. It will be done in the background, with our pal JavaScript doing most of the heavy lifting and some simple .NET or PHP on the server side doing the rest of the work.

In order for you to get a feel for what we are talking about here, take a good look at Google Suggest. This is Google – on steroids. And on AJAX, too. Type in a search term and you will see a box come up with a list of the top results for what you have entered into the search box. Every time you type another character the suggest box updates itself – all without reloading the page. It all happens asynchronously – in the background if you will. You get the same concept with Google Maps. You are able to move the map around and it essentially updates in real time.

thnx...

Hi,

ASP.NET AJAX has a feature in the CTP release (and previous releases) which allows batching multiple requests into one request. It works transparently, you won't notice anything, nor would you need to write any special code. Once you turn on the Batch feature, all web service calls made within a duration gets batched into one call. Thus it saves roundtrip time and total response time.

The actual response time might be reduced, but the perceived delay is higher. If three web service calls are batched, the first call does not finish first. All three calls finish at the same time. If you are doing some UI updates upon completion of each WS call, it does not happen one by one. All of the calls complete in one shot and then the UI gets updated in one shot. As a result, you do not see incremental updates on the UI, instead a long delay before the UI updates. If any of the calls, say the third call downloads a lot of data, the user sees nothing happening until all three calls complete. So, the duration of the first call becomes nearly the duration of the sum of all three calls. Although the actual total duration is reduced, the perceived duration is higher. Batch calls are handy when each call is transmitting a small amount of data. Thus three small calls get executed in one roundtrip.

Let's work on a scenario where three calls are made one by one. Here's how the calls actually get executed.

The second call takes a little bit time to reach the server because the first call is eating up the bandwidth. For the same reason, it takes longer to download. Browsers open two simultaneous connections to the server. So at a time, only two calls are made. Once the second/first call completes, the third call is made.

When these three calls are batched into one:

Here the total download time is reduced (if IIS compression is enabled), and there's only one network latency overhead. All three calls get executed on the server in one shot, and the combined response is downloaded in one call. But to the user, the perceived speed is slower because all the UI update happens after the entire batch call completes. The total duration the batch call will take to complete will always be higher than that for two calls. Moreover, if you do a lot of UI updates one after another, Internet Explorer freezes for a while, giving the user a bad impression. Sometimes, expensive updates on the UI makes the browser screen go blank and white. But Firefox and Opera does not have this problem.

Batch calls have some advantages too. The total download time is less than that for downloading individual call responses because if you use gzip compression in IIS, the total result is compressed instead of individually compressing each result. So, generally, a batch call is better for small calls. But if a call is going to send a large amount of data or is going to return, say, 20KB of response, then it's better not to use batch. Another problem with batch call is, say two calls are very small but the third call is quite big, and if these three calls get batched, the smaller calls are going to suffer from the long delay due to the third larger call.


thnx...

If two HTTP calls somehow get stuck for too long, those two bad calls are going to make some good calls expire too, which in the meantime got queued. Here's a nice example:

function TestTimeout()
{
debug.trace("--Start--");
TestService.set_defaultFailedCallback(
function(result, userContext, methodName)
{
var timedOut = result.get_timedOut();
if( timedOut )
debug.trace( "Timedout: " + methodName );
else
debug.trace( "Error: " + methodName );
});
TestService.set_defaultSucceededCallback( function(result)
{
debug.trace( result );
});

TestService.set_timeout(5000);
TestService.HelloWorld("Call 1");
TestService.Timeout("Call 2");
TestService.Timeout("Call 3");
TestService.HelloWorld("Call 4");
TestService.HelloWorld("Call 5");
TestService.HelloWorld(null); // This one will produce Error
}

On the server side, the web service is very simple:

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ScriptService]
public class TestService : System.Web.Services.WebService {

public TestService () {

//Uncomment the following line if using designed components
//InitializeComponent();
}

[WebMethod][ScriptMethod(UseHttpGet=true)]
public string HelloWorld(string param) {
Thread.Sleep(1000);
return param;
}

[WebMethod][ScriptMethod(UseHttpGet=true)]
public string Timeout(string param) {
Thread.Sleep(10000);
return param;
}
}

I am calling a method named "Timeout" on the server which does nothing but wait for a long time so that the call gets timed out. After that, I am calling a method which does not timeout. But guess what the output is:



Only the first call succeeded. So, if at any moment, the browser's two connections get jammed, then you can expect other waiting calls are going to timeout as well.

In our website, we used to get nearly 400 to 600 timeout error reports from users' browsers. We could never find out how this could happen. First, we suspected slow internet connection. But that cannot happen for so many users. Then we suspected something is wrong with the hosting provider's network. We did a lot of network analysis to find out whether there were any problems on the network or not. But we could not detect any. We used SQL Profiler to see whether there were any long running queries which timed out the ASP.NET request execution time. But no luck. We finally discovered that, it mostly happened due to some bad calls which got stuck and made the good calls expire too. So, we modified the Atlas Runtime and introduced automatic retry on it, and the problem disappeared completely. However, this auto retry requires a sophisticated open heart bypass surgery on the ASP.NET AJAX framework JavaScript. The idea is to make each and every call retry once when it times out. In order to do that, we need to intercept all web method calls and implement a hook on the onFailed callback, which will call the same web method again if the failure reason was a timeout.

Another interesting discovery we made while we were traveling was that whenever we tried to visit Pageflakes from a hotel or an airport wireless internet connection, the first visit always failed and all the web service calls on first attempt always failed. Until we did a refresh, nothing worked. This was another major reason why we implemented immediate auto retry of web service calls, which fixed the problem.

Here's how to do it. Sys$Net$WebServiceProxy$invoke function is responsible for making all Web Service calls. So, we replace this function with a custom implementation which passes a custom onFailure callback. That custom callback gets fired whenever there's an error or timeout. So, when there's a time out, it calls the this function again and thus a retry happens.

Sys.Net.WebServiceProxy.retryOnFailure =
function(result, userContext, methodName, retryParams, onFailure)
{
if( result.get_timedOut() )
{
if( typeof retryParams != "undefined" )
{
debug.trace("Retry: " + methodName);
Sys.Net.WebServiceProxy.original_invoke.apply(this , retryParams );
}
else
{
if( onFailure ) onFailure(result, userContext, methodName);
}
}
else
{
if( onFailure ) onFailure(result, userContext, methodName);
}
}

Sys.Net.WebServiceProxy.original_invoke = Sys.Net.WebServiceProxy.invoke;
Sys.Net.WebServiceProxy.invoke =
function Sys$Net$WebServiceProxy$invoke(servicePath, methodName, useGet,
params, onSuccess, onFailure, userContext, timeout)
{
var retryParams = [ servicePath, methodName, useGet, params,
onSuccess, onFailure, userContext, timeout ];

// Call original invoke but with a new onFailure
// handler which does the auto retry
var newOnFailure = Function.createDelegate( this,
function(result, userContext, methodName)
{
Sys.Net.WebServiceProxy.retryOnFailure(result, userContext,
methodName, retryParams, onFailure);
} );

Sys.Net.WebServiceProxy.original_invoke(servicePat h, methodName, useGet,
params, onSuccess, newOnFailure, userContext, timeout);
}

When run, it will retry each timed out call once.



Here you see the first method succeeded and all the others timed out and was retried. But you will see that after a retry they all succeed. This happens because server side method do not timeout on retry. So, this proves that our implementation is correct.

thnx...

Browsers make two concurrent AJAX calls at a time to a domain. If you make five AJAX calls, the browser is going to make two calls first, then wait for any one of them to complete and then make another call until all remaining four calls are complete. Moreover, you cannot expect calls to execute in the same order as you make the calls. Here's why:



Here you see, call 3's response download is quite big, and thus takes longer than call 5. So, call 5 actually gets executed before call 3.

So, the world of HTTP is unpredictable.

thnx...

Hi,

Try this, go to any start page in the world which will load a lot of RSS on the first visit (e.g., Pageflakes, Netvibes, Protopage), and while loading, try to click on a link which will take you to another site or try to visit another site. You will see the browser is stuck. Until all queued AJAX calls in the browser completes, the browser will not accept any other activity. This is worst in Internet Explorer. But Firefox and Opera do not have this much of a problem.

The problem is, when you make a lot of AJAX calls, the browser keeps all calls in a queue and executes two at a time. So, if you click on something or try to navigate to another site, the browser has to wait for running calls to complete before it can take another call. The solution to this problem is to prevent more than two calls being queued in browser at a time. We need to maintain a queue ourselves, and send calls to the browser's queue from our queue one by one.

The solution is quite shocking, brace for impact:
Collapse

var GlobalCallQueue = {
_callQueue : [], // Maintains the list of webmethods to call
_callInProgress : 0, // Number of calls currently in progress by browser
_maxConcurrentCall : 2, // Max number of calls to execute at a time
_delayBetweenCalls : 50, // Delay between execution of calls
call : function(servicePath, methodName, useGet,
params, onSuccess, onFailure, userContext, timeout)
{
var queuedCall = new QueuedCall(servicePath, methodName, useGet,
params, onSuccess, onFailure, userContext, timeout);

Array.add(GlobalCallQueue._callQueue,queuedCall);
GlobalCallQueue.run();
},
run : function()
{
/// Execute a call from the call queue

if( 0 == GlobalCallQueue._callQueue.length ) return;
if( GlobalCallQueue._callInProgress <
GlobalCallQueue._maxConcurrentCall )
{
GlobalCallQueue._callInProgress ++;
// Get the first call queued
var queuedCall = GlobalCallQueue._callQueue[0];
Array.removeAt( GlobalCallQueue._callQueue, 0 );

// Call the web method
queuedCall.execute();
}
else
{
// cannot run another call. Maximum concurrent
// webservice method call in progress
}
},
callComplete : function()
{
GlobalCallQueue._callInProgress --;
GlobalCallQueue.run();
}
};

QueuedCall = function( servicePath, methodName, useGet, params,
onSuccess, onFailure, userContext, timeout )
{
this._servicePath = servicePath;
this._methodName = methodName;
this._useGet = useGet;
this._params = params;

this._onSuccess = onSuccess;
this._onFailure = onFailure;
this._userContext = userContext;
this._timeout = timeout;
}

QueuedCall.prototype =
{
execute : function()
{
Sys.Net.WebServiceProxy.original_invoke(
this._servicePath, this._methodName, this._useGet, this._params,
Function.createDelegate(this, this.onSuccess), // Handle call complete
Function.createDelegate(this, this.onFailure), // Handle call complete
this._userContext, this._timeout );
},
onSuccess : function(result, userContext, methodName)
{
this._onSuccess(result, userContext, methodName);
GlobalCallQueue.callComplete();
},
onFailure : function(result, userContext, methodName)
{
this._onFailure(result, userContext, methodName);
GlobalCallQueue.callComplete();
}
};

QueuedCall encapsulates one web method call. It takes all the parameters of the actual web service call and overrides the onSuccess and onFailure callbacks. We want to know when a call completes or fails so that we can issue another call from our queue. The GlobalCallQueue maintains the list of all web service calls. Whenever a web method is called, we first queue the call in the GlobalCallQueue and executes calls from the queue one by one ourselves. It ensures, browser does not get more than 2 web service calls at a time and thus browser does not get stuck

In order to enable the queue based call, we need to override the ASP.NET AJAX web method invocation again, as we did before.

Sys.Net.WebServiceProxy.original_invoke = Sys.Net.WebServiceProxy.invoke;
Sys.Net.WebServiceProxy.invoke =
function Sys$Net$WebServiceProxy$invoke(servicePath, methodName,
useGet, params, onSuccess, onFailure, userContext, timeout)
{
GlobalCallQueue.call(servicePath, methodName, useGet, params,
onSuccess, onFailure, userContext, timeout);
}

thnx...

Hi,

Browsers can cache images, JavaScript, CSS files on a user's hard drive, and it can also cache XML HTTP calls if the call is a HTTP GET. The cache is based on the URL. If it's the same URL, and it's cached on the computer, then the response is loaded from the cache, not from the server when it is requested again. Basically, the browser can cache any HTTP GET call and return cached data based on the URL. If you make an XML HTTP call as HTTP GET and the server returns some special header which informs the browser to cache the response, on future calls, the response will be immediately returned from the cache and thus saves the delay of network roundtrip and download time.

At Pageflakes, we cache the user's state so that when the user visits again the following day, the user gets a cached page which loads instantly from the browser cache, not from the server. Thus the second time load becomes very fast. We also cache several small parts of the page which appears on user's actions. When the user does the same action again, a cached result is loaded immediately from the local cache and thus saves the network roundtrip time. The user gets a fast loading site and a very responsive site. The perceived speed increases dramatically.

The idea is to make HTTP GET calls while making Atlas web service calls and return some specific HTTP Response headers which tell the browser to cache the response for some specific duration. If you return the "Expires" header during the response, the browser will cache the XML HTTP response. There are two headers that you need to return with the response which will instruct the browser to cache the response:

HTTP/1.1 200 OK
Expires: Fri, 1 Jan 2030
Cache-Control: public

This will instruct the browser to cache the response till Jan 2030. As long as you make the same XML HTTP call with the same parameters, you will get cached response from the computer and no call will go to the server. There are more advanced ways to get further control over response caching. For example, here is a header which will instruct the browser to cache for 60 seconds but not contact the server and get a fresh response after 60 seconds. It will also prevent proxies from returning cached response when the browser local cache expires after 60 seconds.

HTTP/1.1 200 OK
Cache-Control: private, must-revalidate, proxy-revalidate, max-age=60


thnx...

ASP.NET AJAX, by default, makes HTTP POST for all web service calls. HTTP POST is more expensive than HTTP GET. It transmits more bytes over the wire, thus taking precious network time, and it also makes ASP.NET do extra processing on the server end. So, you should use HTTP GET as much as possible. However, HTTP GET does not allow you to pass objects as parameters. You can pass numerics, string, and date only. When you make an HTTP GET call, Atlas builds an encoded URL and makes a hit to that URL. So, you must not pass too much content which makes the URL become larger than 2048 chars. As far as I know, that's what is the max length of any URL.

In order to enable HTTP GET on a web service method, you need to decorate the method with the [ScriptMethod(UseHttpGet=true)] attribute:

[WebMethod] [ScriptMethod(UseHttpGet=true)]
public string HelloWorld()
{
}

Another problem of POST vs. GET is, POST makes two network roundtrips. When you first make a POST, the web server sends an "HTTP 100 Continue" which means that the web server is ready to accept the content. After that, the browser sends the actual data. So, initiation of a POST request takes more time than GET. Network latency (roundtrip time between your computer and the server) is the biggest concern in AJAX applications because AJAX makes many small calls which needs to be done within milliseconds. Otherwise the application does not feel smooth and creates user annoyance.

Ethereal is a nice tool to see what happens under the hood on POST and GET:




From the above picture, you see that POST requires a confirmation from the web server: "HTTP/1.1 100 Continue" before sending the actual data. After that, it transmits the data. On the other hand, GET transmits the data without waiting for any confirmation.

So, you should use HTTP GET while downloading data from a server like parts of pages, contents in a grid, or a block of text etc. But you should not use HTTP GET to send data to a server like submission of web forms.

thnx...

Depending on the extent to which you implement AJAX, you will probably have pages that appear differently or give different information to the user after some user interaction. What I am calling "Bookmark Issues" is the fact that because you are not having a page for each view, or a page for each set of information that is being displayed, users will not be able to create bookmarks to pages.

One example of this would be if you had a dictionary site. You could have an extremely smooth system of lookup and retrieval that doesn't necessitate the reloading of any pages. Users would probably appreciate it for its speed and predictability. The issue would be that users could not bookmark the words or searches that they run.

thnx...

The second issue with AJAX is similar to the first. Because you are changing the entire web browsing model, the forward and back buttons are most likely going to break.

Let’s go back to the imaginary dictionary website. If a user looks up three different words using your interactive AJAX system, the user is not going to be able to user their browser's back or forward buttons to get to previous or next dictionary definitions or searches.

There are ways to rewrite the functionality of the forward and back buttons, those ways are outside the complexity that the standard developer wants to take. When your site relies on the forward/back buttons of the browser, or when your site wants to be friendly to standard users, you should consider the additional value of reloading each page to give some additional control of their browsing experience.

I understand that it would be fairly easy to implement your own "back" "forward" buttons within that AJAX, but from experience users almost NEVER listen to commands sounding similar to: "Don't use your browser's "Back" or "Forward" button".

thnx...

At my company, we use a hand-rolled AJAX solution (it's about 2-3 years old, otherwise we probably would have used someone else's solution). Recently, we've applied it to one of our secure (HTTPS) websites and we've been having intermittant problems with the XMLHTTP object on the browser (always IE 5.5+) sending requests to the server (always Win2k3). It happens about once every 20-25 requests and just returns an error message that says "The download of the specified resource has failed." We tried moving our web service to an HTTP server rather than an HTTPS server and the problem went away, so we're fairly certain that it's a problem with the XMLHTTP object communicating with the secure server, and we've tried stripping out all irrelevant code, so we're also fairly certain that it's not something unrelated.

We've contact Microsoft support about this and they've confirmed that we're not the first people to encounter this problem but haven't gotten any more info from them yet (although we should hear back soon).

This is just an FYI for those of you jumping on the AJAX bandwagon from someone who's been doing this sort of thing for a while now.

thnx...

Hi Deeban,

here is the sample example for autocomplete textbox using ajax.

AutoComplete Example

Ajax.NET comes without any web control, it is designed only for data exchange with the web server. Here you will see how easy it is to implement a AutoComplete feature.
This example will include following features:
Keyboard support (TAB, ENTER, DOWN, UP, ESC)
Mouse support (select on value with the mouse, dblclick in textbox to get list)
ParentControl support (change value if parent control has been changed)
DataTable built-in support
MinChars needed support (default is 0)
WaitAfterInput to prevent high request interval to the server
Please notice that it is only tested on Firefox and Internet Explorer, it may fail on other web browser not because of Ajax.NET.
Try to enter a cusomter name beginning with A. You will see a list of customer names I have stored in SQL Server. Hitting Tab will place your cursor in the order number text box. All order numbers are starting with 0, so try to enter 0. You should see a order number in bold and maybe one character at the end in red. If you use a customer name starting with i.e. M you will get a different order number selection, it will be text only.
Customer: -----------
OrderNumber: ------------

JavaScript Code

To use the example AutoComplete feature you need to add a behaviour to the text box control. After you have included the autocomplete.js you can write this:
<script type="text/javascript" src="scripts/autocomplete.js"></script>
<script type="text/javascript">
function init() {
var x = new MS.Web.AutoCompleteDataTable("searchCustomerID", 10);

x.getDisplay = function(item) {
return (item != null ? item.CustomerName : "");
}
x.getValue = function(item) {
return (item != null ? item.CustomerName.toString().trimRight() : "");
}
x.getData = function() {
Namespcae.Classname.AjaxMethod(this.ele.value, this.count, this.callback.bind(this));
}
}
addEvent(window, "load", init);
</script>
In the example above we are returning a DataTable from the method Namespcae.Classname.AjaxMethod. In getDisplay() we have to return the data that will be displayed in the select control, and getValue() must return the text that will be put in the text box value after selected one item.
C# Source Code

Below you will find the source code used on the server-side Ajax.NET method which will return the list of order numbers for the second text box.
[AjaxPro.AjaxMethod]
public DataTable SearchAdvanced(string orderNumber, int customerID, int count)
{
DataSet ds = new DataSet();

SqlConnection conn = new SqlConnection(ConfigurationSettings.AppSettings["AjaxDemoSqlServer"]);

SqlCommand cmd = new SqlCommand("SELECT TOP " + count + " * FROM Orders " +
"WHERE CustomerID = @CustomerID " +
"AND OrderNumber LIKE @OrderNumber " +
"ORDER BY OrderNumber, PartNumber, JobNumber", conn);

cmd.Parameters.AddWithValue("@CustomerID", customerID);
cmd.Parameters.AddWithValue("@OrderNumber", orderNumber + "%");

try
{
conn.Open();

try
{
SqlDataAdapter da = new SqlDataAdapter(cmd);
da.Fill(ds);
}
finally
{
conn.Close();
}
}
catch (Exception)
{
return null;
}

return ds.Tables.Count == 1 ? ds.Tables[0] : null;
}
As you can see it doesn't matter which arguments you want to use for the search. If you want to return a string[] you can simply use the MS.Web.AutoComplete class in JavaScript and only implement the getData() method, that's all.


cheers...

Hi all,

I have to restrict the users to acess the ajax methods by role based, is there any way to resrict the users by their role based authentication.....?


Thanks in advance....
Its urgent....

__________________
J.Saravanan

Hi Saravanan,

Ajax.NET is working great with forms authentication. See how you can use ASP.NET security to protect your Ajax.NET methods.

[AjaxPro.AjaxMethod]
[PrincipalPermission(SecurityAction.Demand, Role = "Admin")]
public static string AdminMethod()
{
return "Hello Admin, you can get this text only if you are a Admin!";
}

[AjaxPro.AjaxMethod]
[PrincipalPermission(SecurityAction.Demand, Role = "Admin")]
[PrincipalPermission(SecurityAction.Demand, Role = "Editor")]
public static string EditorAndAdminMethod()
{
return "Hello Editor or Admin, both roles can see this text!";
}

If you are not logged-in you cannot run one of the methods below. Try to login as admin (role = Admin,Editor) or editor (role = Editor), both have the password ajax.

Try to invoke AdminMethod() which is only allowed for users in role Admin. Or try the EditorAndAdminMethod() that can invoked from any Admin or Editor.

hope this will help you...

Hi All,

how to use the AjaxServerCache attribute to reduce the CPU and database usage on the server-side code..?


Its urgent...

Any help would be appreciated...

Hi Ramesh....

This example will show you how to use the AjaxServerCache attribute to reduce the CPU and database usage on the server-side code.

If you put an AjaxMethod attribute to a server-side method the method will be invoked every time you call this method. Using Ajax will increase the requests done to the web server, maybe with less data but more often. If there are a lot of identical requests it would be nice to have an attribute to tell how long the same result should be returned.

The following example will have the AjaxServerCache attribute for the GetServerTime method configured to cache the result for 10 seconds. This means if you call the method you will get 10 seconds the same requests.

[AjaxMethod]
[AjaxServerCache(10)]
public static DateTime GetServerTime()
{
return DateTime.Now;
}

Call the GetServerTime method. call several times the link to see that you will get the same result. Note that the server-side method is not invoked when in the time slice of 10 seconds.


I hope this will help you...

thnx...