Is it possible with JSF to make ajax calls that will execute simultaneously (not waiting for previous calls to finish before starting a new one)?
No, they are explicitly queued by specification, without any exception. See chapter 13.3.2 of the JSF 2 specification:
13.3.2 Ajax Request Queueing
All Ajax requests must be put into a client side request queue before they are sent to the
server to ensure Ajax requests are processed in the order they are sent. The request that has been waiting in the queue the
longest is the next request to be sent. After a request is sent, the Ajax request callback function must remove the request
from the queue (also known as dequeuing). If the request completed successfully, it must be removed from the queue. If
there was an error, the client must be notified, but the request must still be removed from the queue so the next request
can be sent. The next request (the oldest request in the queue) must be sent. Refer to the jsf.ajax.request
JavaScript documentation for more specifics about the Ajax request queue.
This is done so to ensure thread safety of among others the view scoped beans in the server side.
To prevent problems with the so called View-State of the page or some forms, AJAX requests are serialized.
JSF-Extensions (https://www.intersult.com/wiki/page/JSF%20Ext) gives you the option to parallelize AJAX requests. Just set the JavaScript variable jsf.ajaxQueue to another value than the default of 1. But if you don't lock out manually duplicate requests from within the same form or rendering of the same region, you will get errors.
This is how you activate parallel requests:
<script type="text/javascript">
if (jsf)
jsf.ajaxQueue = 2;
</script>
For example you can parallelize the rendering on the server of a page with <e:async>. Most applications would not need parallel requests, because they run nice when strictly serialized.
Related
I'm working on an application stack that has a rather particular architecture. The forms component is loaded on a view, and when the action is submitted, an async call using sidekiq is performed. This calls an endpoint that validates the form data, but none of this is returned back to the server and after this process is fired, there is a redirect to another page.
We want to add cookies to write the status of this call sidekiq did. This is not possible to do on the controller as the controller when it is rendering the destination page has no knowledge of this event that occurred. The possibility of writing this cookie on the async callback is tempting but this is not done on the controller (The controller loads a class that contains a module with this functionality)
Question: Is it possible to write cookies in places not in the controller, such as classes or models? I'm assuming no, but I figured it might be an interesting question.
It's not possible. Writing a cookie is a part of HTTP response, so you need to be in the request-response cycle, i.e. in the controller.
What you could do (and I did that more than once) is to have some kind of record in the database, storing a status of a background job, and from the page you redirected to periodically poll some endpoint with AJAX (or establish a Websocket connection) to check if the job has finished and with what status. Then you'll be able to set the cookie.
Is it possible with JSF to make ajax calls that will execute simultaneously (not waiting for previous calls to finish before starting a new one)?
No, they are explicitly queued by specification, without any exception. See chapter 13.3.2 of the JSF 2 specification:
13.3.2 Ajax Request Queueing
All Ajax requests must be put into a client side request queue before they are sent to the
server to ensure Ajax requests are processed in the order they are sent. The request that has been waiting in the queue the
longest is the next request to be sent. After a request is sent, the Ajax request callback function must remove the request
from the queue (also known as dequeuing). If the request completed successfully, it must be removed from the queue. If
there was an error, the client must be notified, but the request must still be removed from the queue so the next request
can be sent. The next request (the oldest request in the queue) must be sent. Refer to the jsf.ajax.request
JavaScript documentation for more specifics about the Ajax request queue.
This is done so to ensure thread safety of among others the view scoped beans in the server side.
To prevent problems with the so called View-State of the page or some forms, AJAX requests are serialized.
JSF-Extensions (https://www.intersult.com/wiki/page/JSF%20Ext) gives you the option to parallelize AJAX requests. Just set the JavaScript variable jsf.ajaxQueue to another value than the default of 1. But if you don't lock out manually duplicate requests from within the same form or rendering of the same region, you will get errors.
This is how you activate parallel requests:
<script type="text/javascript">
if (jsf)
jsf.ajaxQueue = 2;
</script>
For example you can parallelize the rendering on the server of a page with <e:async>. Most applications would not need parallel requests, because they run nice when strictly serialized.
In, for example, JavaScript AJAX libraries it is possible to abort an AJAX request. Is there any server side advantage to this or is it just for client-side cleanliness? Is it part of TCP?
If, for example, I am requesting via AJAX a Python based server service – which is resource intensive – from my JavaScript Web App and abort this AJAX request, is it possible that aborting will ease the load on the server, or will the my ajax library just ignore the response from the server?
It does not affect the server-side if you use your frameworks abort feature. The server will still process the request regardless.
Once you made an HTTP request to a resource URL on your server (be it Asynch or not, aka ajax or "regular"), you can't abort it from your client / with another http request (unless your service has some weird listener that awaits for potential consequent http requests and stops itself up receiving one). My proposition, if you have one resource and time consuming operation, either split it into simpler operations, parallelize it or at east make some periodic responses to at least inform the user that it's still working and hasn't died
When people create real-time web apps, they are leaving a ajax request open/long running.
how do they do this in javascript?
There is really no difference from a normal ajax request. A callback is associated with the XMLHttpRequest. Once the request is complete the callback is invoked. The difference is on the server-side where the request is held open until data is ready for the client, or a timeout occurs. On the browser side, the callback is invoked as each successive request is answered. The callback must process the data from the server and initiate another request. The request is handled asynchronously, so the browser is not blocked.
A really good example of the whole thing is the chat demo included in Tornado.
Is there any difference in performance ( speed wise ) between a synchronous request and and asynchronous request?
What all are the reasons for using an asynchronous request??
You should mostly always use an asynchronous Ajax Request, in fact I know only about one place where a synchronous Ajax Request should be used which is if you're in an Ajax Request embedding a new JavaScript file on the client and then referencing types and/or objects from that JavaScript file in the return from the original Ajax Request. Then the fetching of this new JS file should (or can sanely) be included through using a synchronous Ajax Request...
Other then that you should always use asynchronous Ajax Requests. The most important reason is that a synchronous Ajax Request makes the UI (browser) unresponsive...
#Thomas Hansen answer is right but I found a clear explanation with benefits of Asynchronous.
Synchronous is simple, but wait for the server response, thus block the execution of the caller for a period and slower than asynchronous while processing the request.
Asynchronous is required setting, do not wait after submitting the request and immediately return control to the caller, thus faster than Synchronous.
I am coming here when I have to use upload control which has both functionalities in the question and looking the pros and cons of this functionality.
I got the another link which explained with a real example. (the link is the specific tool, so understand the logic)
The major difference is the response time from our servers. At the time of upload, synchronous will validate file and create the passcode in real-time. Asynchronous will send the file to our server's queue and deliver notification via email once it is processed.
Synchronous is not ideal for multiple, large CSV file since you will need to wait until the file is processed by the server to submit another request. On large files, this also may cause your browsers to return with timeout errors due to the server being too busy. If you have multiple files, asynchronous will allow you to submit multiple files to the server queue to be processed with a email receipt once completed.
https://www.aspsnippets.com/Articles/Difference-between-Synchronous-Sync-and-Asynchronous-Async-Request-Call-in-AJAX.aspx
there can be serious performance implications caused when it come to highly database intensive applications .. although it's very unlikely to happen .. and sending many Synchronous ajax calls can create a backlog .. so if the application database intensive and sending so many request at once it is better to make it asynchronous.
when its set to asynch the browser will fail all unresponsive request and continue with new once..