Long Term Wicket Ajax Request

I sometimes have some long AJAX requests in a Wicket app. When this happens, the application is largely unusable because subsequent AJAX requests are queued for processing synchronously after the current request. I would like the request to stop after a while regardless of whether the response was returned (I have a user requirement that if this happens, we must present the user with an error message and continue). This presents two questions:

  • Is there a way to specify a timeout specific to AJAX or all AJAX requests?
  • If not, is there a way to kill the current request?

I looked at the wicket-ajax.js file and I do not see any mention of the request timeout.

I even went so far as to try to reload the page after some timeout on the client side, but unfortunately the server is still busy processing the original AJAX request and does not return until the AJAX request completes processing.

Thanks!

+4
source share
2 answers

I think this will not help you let the client "cancel" the request. (However, this may work.)

The fact is that the server is busy processing a request that is no longer required. If you wanted to drag and drop such operations, you had to implement a timeout on the server side. If the operation takes too much time, the server aborts it and returns some error value as a result of the Ajax request.

Regarding the queue problem: you can use asynchronous requests, despite the synchronous ones. This means that the client first sends a request to start a long process. This request is returned immediately. The client then periodically checks the server and asks if the process is complete. Those polling requests also immediately return, saying either that the process is still running or that it ended with a certain result.

+3
source

Unsuccessful solution: after the given setTimeout, I kill active transports and restart the channel that processes everything on the client side. I avoided query conflicts by binding them to an identifier and checking it for a global link, which increments every time a request is executed, and every time a request ends.

function longRunningCallCheck(refId) { // make sure the reference id matches the global id. // this indicates that we are still processing the // long running ajax call. if(refId == id){ // perform client processing here // kill all active transport layers var t = Wicket.Ajax.transports; for (var i = 0; i < t.length; ++i) { if (t[i].readyState != 0) { t[i].onreadystatechange = Wicket.emptyFunction; t[i].abort(); } } // process the default channel Wicket.channelManager.done('0|s'); } } 

Unfortunately, this still left the PageMap blocked and any subsequent calls wait for the request to complete on the server side.

My solution at this point is to instead provide the user with the option to log out using the BookmarkablePageLink bookmark (which creates a new page that does not create competition on the PageMap page). Definitely not optimal.

Any better solutions are more than welcome, but this is the best I could come up with.

+2
source

Source: https://habr.com/ru/post/1303166/


All Articles