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.
Related
I have built a testsuite for a service orchestration with Citrus framework.
In one case, when the former request results in an "empty" response, the last orchestration step, a HTTP request, is skipped.
How can I test that this last request is NOT executed? I did not found a way to do this.
When I do not check this with an explicit expectation, the test is successful no matter if a request is executed or not.
I have an HTTP server simulation in place to respond according to the request. What I was looking for is something like
runner.http(action -> action.server(simulation)
.receiveNothingDuring(5000)
);
to wait for 5 seconds for a request to arrive and SUCCEED if nothing arrives. This is kind of the inverse of the normal receive assertion.
You can use the receiveTimeout action that is exactly what you need:
runner.receiveTimeout(action -> action.endpoint(simulation)
.timeout(5000));
See also descriptions in docs
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.
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.
In Paw if I have a long running request and attempt to invoke another I'm presented with a dialog that says Stop request? A request is currently running. with the options Cancel, Stop and Stop & Send. How can I keep the first request running and invoke another without canceling the first request?
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.