Related
We use heavily Firebase JS SDK, and at one point encountered an issue where updates made by the SDK (using updateDoc) did not reach the server (though no network issues were detected). Same happened also for onSnapshot call (no updates retrieved from server, although there were updated).
In order to better understand what happens, we wanted to understand what happens on the network layer (in terms of HTTP requests flow), especially when we listen for updates, or perform updates.
The question is created in order to share our findings with other who are wondering about this, and in case some one from the Firebase team can confirm.
We performed updateDoc and onSnapshot calls using Firebase JS SDK for Firestore, and expected to be able to associate the network requests seen in Chrome Dev Tools to these SDK calls.
Below are the observations regarding the HTTP calls flow.
When we initialize Firestore, a Web Channel is created on which the traffic between the client and the server will go through.
The Web Channel uses gRPC over HTTP/2 (thanks Frank van Puffelen for the tip)
The default behavior is as follows:
Commands (e.g. start listen, set data) are sent using POST requests.
The response includes SID, which identifies the command lifecycle. Note that start listen commands (on different docs) will share the same SID.
SSE-based (server-side-events) GET requests with ±1 minute interval are used to listen on results from the commands (with the appropriate SID).
After the interval ends, a new SSE-based GET request will be created unless the command finished (e.g. stop listen was called, data was set).
If the command finished, and no additional GET request is required, a POST terminate request will be sent with the relevant SID.
The listen (onSnapshot) behavior by default is as follows:
Whenever onSnapshot is called, we have a POST request to a LISTEN endpoint to addTarget which returns immediately with SID. The addTarget includes the document path and a targetId generated by the client for later use. If there's already an open onSnapshot, it will use the same SID.
Following the POST response, a pending GET request is created which receives changes. It will use the same SID.
The pending GET requests receives changes are for all target (listened) objects (e.g. documents).
The GET request remains open for about a minute (sometimes less, sometimes more).
Every time new data arrives, it is processed, but the GET request remains open until it's interval (±1 minute) has passed.
The GET request also receives the initial values once a target was added (via onSnapshot).
Once the interval has passed, the pending GET request ends (and we can see the response).
Once it ends, it is replaced by a new pending GET request, which behaves the same way.
Whenever we unsubscribe from a listener, there is a POST request to a LISTEN endpoint to removeTarget.
After unsubscribing from all targets, the GET request will still end after the interval completes. However, no new GET request will initiate, and a terminate POST request will be sent.
Setting data for a doc (setDoc) behaves as follows:
A POST request is sent to the backend in order to start a session and receive SID.
A pending GET request is created, on which we aim to receive updates when the data was set in the backend. The pending GET request leaves for ±1 minute.
Another POST request is created with the update details (e.g. update field f1 on document d1 ).
Once the Firestore backend has updated the data, we'll receive the update operation details on the GET request, which will remain pending until the ±1 minute interval completes.
After the interval completes, and if the data was stored in the backend DB, the GET request will end, and a terminate POST request will be sent.
With long-polling (set by experimentalForceLongPolling) we have the following notable changes:
Every time there's a change in an object we listen on, the pending GET request is ended and a new one is created instead.
Instead of ±1 minute GET request, we have a ±30 seconds GET request followed by a ±15 seconds GET request.
I would like to understand the internals of Session~setMaxInactiveInterval
I understand that if HTTP requests are not received within the said interval then the session is cleared. All the objects belonging to the session will be gone.
Does that also mean that the existing requests part of the session will be terminated ?
I have scenario for large file transfer to happen over a single request.
So if one request (A) is long running and there are no other requests sent within the time interval. Then will the request A will be terminated ?
Best Regards,
Saurav
I have some HTTP requests in my Test Plan and I would like to analyze which are executed in a certain limit of time and which or not. The PreProcessor Sample Timeout could be useful here, but I also would like to check if the HTTP request itself is working, so I need the request not to be stopped when exceeding the time limit.
The perfect behavior would be that the request is marked in red if it exceeds the timeout, and that we can still see the real time of execution and the request result.
Is there a way to do so?
You need to add Duration Assertion to your request, It'll mark as failure (red) the request, but let the request finish and save its response/ load time
A Duration Assertion can be used to detect responses that take too long to complete.
For example assertion message:
Assertion failure message: The operation lasted too long: It took 15,111 milliseconds, but should not have lasted longer than 1,000 milliseconds.
I have a server that takes a file, analyse it and sends back the result when requested by the client. In some cases there are some files that are inserted in a queue and waits for a analyser to do its job. At the same time if the analysis result is pending client can request for a result. So what should be the Http status code in this case?
Per the w3c spec, 202 means that that status has been accepted by the server (and is still processing).
The request has been accepted for processing, but the processing has
not been completed. The request might or might not eventually be acted
upon, as it might be disallowed when processing actually takes place.
There is no facility for re-sending a status code from an asynchronous
operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist until
the process is completed. The entity returned with this response
SHOULD include an indication of the request's current status and
either a pointer to a status monitor or some estimate of when the user
can expect the request to be fulfilled.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
I would go with 202:
202 Accepted
The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.
There is no specific separate status code for the pending request.
You can predicate it from the status code 202
The request has been accepted for processing, but the processing has
not been completed. The request might or might not be eventually acted
upon, and may be disallowed when processing occurs
2xx status code series means Success, means request heated to the server & it is in process.
What is the most appropriate HTTP status code to give to a client to mean "your request is fine, but it is still in progress; check back shortly in the exact same place."
For example, say the client submits an initial request to start a heavy query, and the server immediately returns a URL that the client can poll periodically for the result. In the case the client calls this URL before the job is completed, what is the most appropriate HTTP status code to return?
202 Accepted would be my first impulse. Is this the best one, or is there a better one that is more idiomatic for this purpose in REST interfaces?
To me, 202 Accepted would be the best way to go.
See the documentation on the W3C website.
10.2.3 202 Accepted
The request has been accepted for processing, but the processing has
not been completed. The request might or might not eventually be acted
upon, as it might be disallowed when processing actually takes place.
There is no facility for re-sending a status code from an asynchronous
operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist until
the process is completed. The entity returned with this response
SHOULD include an indication of the request's current status and
either a pointer to a status monitor or some estimate of when the user
can expect the request to be fulfilled.