As stated in the title, i would like to know what happens when an AJAX request is sent to a controller action and, during this time, a network timeout happens for a few ms before the request is completed.
Reply from <Server IP>: bytes=32 time=31ms TTL=122
Request timed out
Reply from <Server IP>: bytes=32 time=28ms TTL=122
Considering the timeout happens only for a couple of ms, what effects would this have on my AJAX request?
This is in continuation to a problem we are facing in our application as explained in this SO question and i would like to know if they are somehow related.
I have googled for similar issues but couldn't find anything useful.
Edit: Apart from the impact on AJAX, would it affect the action method's behavior (server)?
Regardless of whether the timeout happens only for a couple of ms or more, the request will fail. The success callback function of your AJAX request will not be executed and the request will end with the execution of complete callback function. By default, all AJAX requests will have a timeout of 0ms (unlimited), but it will hit the default timeout of the browser.
When an AJAX request times out, the error callback function will be invoked. The second argument of this function is a string describing the type of error and in this case, it will have the value timeout. You can handle request timeouts by handling this callback function and by optionally specifying a timeout value (if not specified, works on the default value) in the AJAX request body:
$.ajax({
...
timeout: 5000, //specify the timeout value in milliseconds
error: function(jqXHR, textStatus, errorThrown) {
if(textStatus==="timeout") {
//code to execute when timeout occurs
}
}
});
Additionally, you can also check if the request has timed out in the complete callback function (in a similar way as shown above) by checking the second argument which is a string and it will have the value timeout if the request was timed out.
Also, note this:
The timeout period starts at the point the $.ajax call is made; if several other requests are in progress and the browser has no connections available, it is possible for a request to time out before it can be sent.
Request timeouts are usually either left at their default or set as a global default using $.ajaxSetup() rather than being overridden for specific requests with the timeout option.
I would suggest you to use an alternative HTTP/s traffic monitoring tool like fiddler to find the mystery behind the second request.
More info: jQuery ajax documentation
The request will "fail", meaning it will enter the onError state of your AJAX request. The status code will then be 0, since there is no response from the server to determine the real status code (eg. 200 OK or 500 Internal Server Error).
In case of time-out your success callback wont execute so you have to write an error callback at the client side to handle such issues.
You have to raise an exception from server side in case of time-out so that it will get back to the client as an error that is the one way you can handle the time-out.
Related
In XQuery code when I make an xdmp:http-post call, I can configure a timeout value in the request options. Say I configure it as 5 seconds, it gives a timeout exception back.
My question here is, will MarkLogic try to complete the calling XQuery module or cancel it? Lot of times this needs to be done from admin console to cancel the query manually.
will MarkLogic try to complete the calling XQuery module or cancel it?
The module that you happen to be invoking from the xdmp:http-post() does not know that the client has timed out and stopped waiting for a response to be sent. It will continue processing the request and work to generate a response.
If you would like for it to have a shorter timeout closer to the timeout value of the module invoking xdmp:http-post(), then you could add xdmp:set-request-time-limit() to set an explicit (shorter) timeout for this request.
xdmp:set-request-time-limit(6),
for $i in (1 to 1000)
return ( xdmp:log("I'm feeling sleepy..."||$i), xdmp:sleep(1000) )
You could even accept a timeout value as a request parameter to the HTTP POST, so that the client could dynamically set the timeout per request.
I'm using Postman to debug my WebAPI.
There are 2 cases where Postman does not get any answer from my API:
1. When I set a breakpoint for incoming requests
2. When my API is not running
In 1st case, Postman waits (for inifinity theoretically), but in the other it returns me an information that something is wrong after a few seconds.
So my question is: How does that work? In the 1st case, request gets to my server, but it doesn't send any response until I stop debugging, which can take minutes possibly. In the 2nd case, Postman also does not egt any repsonse, but somehow it knows after a few seconds that it will never get it.
In first request the connect to server is successful and it waits for a reply until postman timeout defined.
Second request it connect to server and get reply immediately with an error.
You can increase or decrease max time postman wait for response by using XHR Timeout
Set how long the app should wait for a response before saying that the server isn't responding.
I'm trying to understand how to use the IOwinRequest.CallCancelled CancellationToken IOwinRequest. I assumed that the token would get flagged any time the request became invalid (for the following cases):
Disposing the object returned by WebApp.Start.
The HttpClient.GetAsync Task is cancelled or disposed.
In all these cases, it seems that the CallCancelled request is never flagged. Why?
EDIT: I found an error in my code and my first point "Disposing the object returned by WebApp.Start" works now. Disposed/Cancelled client requests still don't trigger the server request token to flag though.
For some background, I am trying to implement long-polling, where the server suspended the request thread until some data arrived to return to the client, or if the request is cancelled. To implement this, my suspending loop will fall out if the cancellation token is flagged. If it's not flagged, the request thread will NEVER end unless there is something to return. Since the token is never flagged, my server could end up with an infinite number of requests that never end.
Is there an HTTP status code to instruct a client to perform the same request again?
I am facing a situation where the server has to "wait" for a lock to disappear when processing a request. But by the time the lock disappears, the requests might be close to its timeout limit. So instead, once the lock clears, I would like to instruct the client to just perform the same request again.
The best I an come up with is a HTTP 307 to the same location, but I'm worried that some browsers might not buy into this (redirect loop detection).
The correct response, when a server is unable to handle a request, is 503 Service Unavailable. When the condition is temporary, as it is in your case, you can set the Retry-After header to let the client know how long it should wait before trying again.
However, this will not force the browser to perform the request again - this is something you would need to handle yourself in javascript. For example, here is how you might perform a retrying ajax POST request in jquery:
function postData() {
$.ajax({
type: 'POST',
url: '503.php',
success: function() {
/*
Do whatever you need to do here when successful.
*/
},
statusCode: {
503: function(jqXHR) {
var retryAfter = jqXHR.getResponseHeader('Retry-After');
retryAfter = parseInt(retryAfter, 10);
if (!retryAfter) retryAfter = 5;
setTimeout(postData, retryAfter * 1000);
}
}
});
}
Note that the above code only supports a Retry-After header where the retry delay is specified in seconds. If you want to support dates that would require a little more work. In production code I would also recommend a counter of some sort to make sure you don't keep retrying forever.
As for using a 307 status code to repeat the request automatically, I don't think that is a good idea. Even if you add a retry parameter to get around the browser loop detection (which feels like a horrible hack), it's still not going to work on a POST request. From RFC2616:
If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user.
While some browsers are known to ignore this requirement, it's definitely not correct, and isn't something you would want to rely on.
And if you're not using a POST request, you almost certainly should be. Remember that a GET request should not have any side effects, and by default the response will be cached. From the description of your problem, it sounds very much like your request is likely to be doing something that has side-effects.
Use the 307 redirect, but add a retry counter:
http://path/to/server?retry=3
This will make the URL different on each retry, preventing loop detection. And the server could check for retry hitting a limit, and abort with an error when that happens, so the user doesn't wait forever.
I've poked around a bit, but I don't see an HTTP status code for when a request's succeeds, but there is an error after the "point of no return".
e.g., Say you process a request, its committed to the database, but while returning the result you run of memory, or encounter a NPE, or what have you. It would have been a 200 response, but now, internally, you aren't able to return the proper, well-formed response.
202 Accepted doesn't seem to fit since we've already processed the request.
What status code means "Success, but errors"? Does one even exist?
HTTP doesn't have such a status code, but there is a best practice that allows you to handle such situations - redirect the user after a POST operation.
Here is a break down -
A POST request tries to modify data on the server
If the server fails, it sends a 500 error to indicate failure
If the server succeeds, it sends a 302 redirect response
The browser then sends a fresh GET request to the server
If this fails, you get a 500 error, otherwise you get a 200
So, your use case of 'Saved data but can't retrieve it immediately' translates to a 302 redirect for the initial POST, followed by a 500 for the subsequent GET.
This approach has other advantages - you get rid of the annoying 'Are you sure you want to resubmit the data?' message. Also keeps your back/forward/refresh buttons usable.
If the server is aware that it has encountered a problem, it should normally return a 5xx error. The most generic one is the 500 Server Error, which the RFC 2616 defines as follows:
500 Internal Server Error
The server encountered an unexpected condition which prevented it
from fulfilling the request.
Then it's the client's responsibility to reattempt the request. If the previous request was partially committed, it's the server's (or the database's) responsibility to roll that back, or to handle the duplicate transaction appropriately.
I agree with #Daniel that the proper response is an HTTP 500 (server error). The web application has to be written to roll back the transaction when there is an error, not leave things half-finished.
One thing you can leverage in your web application is "idempotency". This is the property of a function (or operation) that you can repeat it as many times as you like with the same result. For instance if a read fails, the client can simply retry it until it succeeds. If a deletion appears to fail, the client can again retry and the server will treat the request as valid whether or not the resource being deleted is already gone. And if an update appears to fail, the client can retry that until it gets a successful return from the server. The REST approach to architecting web services makes heavy use of idempotency to make operations robust in the face of error.