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?
Related
Is there a way to implement a "delivery receipt", or, "quick response", from the server before the start of a long running process (that will delay the actual response content)?
I mean this:
request -> server receives -> res.send(200) ((but keep this 'res' alive!)) -> server long running process -> res.send("actual response")
This would be very useful in the app side, so I get to know that timeouts are really happening because of the process and not because the server is offline. Also, I wanted to avoid making two requests, one following the other one.
HTTP Status Code 100 CONTINUE can be used for this purpose. See https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1
According to the RFC, 100 Continue is an interim response which must be followed by a final response once the request has been completed.
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 am trying to upload an image. I need to start a synchronising thread as soon as the http request comes in. Presently my Grails code starts only after the entire post data has been received.
The controller is in fact invoked as soon as the request comes in. Only when the image data is fetched from the http request body does the code stall and wait for the upload to finish.
Is there a protocol (or framework) that ensures that when a request fails, it fails on both the client side (iOS, Android, etc) and server side, and when it succeeds, successes on both sides?
The request might be completed on the server but because of dropped network connection, the client does not receive the response and thinks that the request failed.
The Post-Redirect-Get pattern can be adapted to this. The post part is used to submit the request, and the redirected get will be to a "results" page where the client can acquire the status (in progress, failure, success. etc).
Obviously, a client should not conclude from a network problem that the request failed. It should simply be prepared to wait and/or retry to obtain the status.
The interesting case is where the initial request submission is incomplete, i.e. nothing, not even the redirect comes back. This is where the adaptation comes in. The initial data submission should be after the server has generated a transaction identifier that the client can use as an alternative for status requests. (E.g., a form with a static field "Please save and use this tracking ID for status inquiries".)
If your question was whether this fallback can be automated at the protocol level, the answer unfortunately is no.