Killing request after reload();
Killing request after reload();
I'm implementing a polling method by listening to the xhr.dt
event and then running a setInterval that calls someTable.ajax.reload()
on it. Initally I was just setting a flag that would prevent the next reload from happening. Not "instant", but it did the trick.
However, I have need of not only preventing the next reload, but aborting the XHR altogether so that DataTables does not do a new draw. Or, if there's a simple way to just prevent the draw stage after the XHR returns, that's fine, too.
I actually have a few DataTables at a time, and for brevity of code and management, it's worth the "expense" for me to just abort all of them at once. Here was my attempt:
$.each(fcapp.storedTables, function() {
this.context[0].jqXHR.abort();
});
Where storedTables is an object literal populated with cached DataTables objects (created with the someTable = $("#someTable").DataTable()
pattern).
There is indeed an abort function available at that "location"... however, no abort happens. This leads me to believe that I'm dealing with the wrong jqXHR... this isn't the "outstanding" request anymore.
Is there a way to abort an XHR that hasn't returned yet, when the ajax request was fired with ajax.reload()
?
Answers
Can we write plugins that might allow me to add an "abort" method to the "ajax" object? I other words, instead of digging into the context (which isn't working anyhow),
someTable.ajax.abort()
would be a great method to have. :DDealing with the same problem... Having datatables working with endlesss requests polling data from the server. Request runs maximum for 60 seconds, the whole browser (Chrome) waits for the request before navigating to the next page. So worst case scenario, I must wait 60 seconds before the next page shows up.
Already tried a lot of things, but still not able to abort an jqXHR request. An
someTable.ajax.abort()
would be very nice!There is currently no external way to do this I'm afraid. Having said that, I would have though that the method GregP shows above using the
jqXHR.abort();
method from the private settings would have worked. Is there only one table Greg? Possibly a loop over the context is required?Allan
Thought I was getting nuts... Eventually figured it out how to use the
jqXHR.abort();
function and got to cancel requests before they were done. Still the page wouldn't refresh and looked like it was waiting for some request to finish or some javascript to get executed.Finally found it. Nothing to do with javascript, it was all server-side. When using session_start() in polling requests, PHP session locking will block all other scripts / calls for the same session to avoid race conditions. The polling-script had an 'sleep' in it. So aborting the jqXHR with javascript still kept the script running on the server and blocking all scripts before done. Managed to fix it using the
session_write_close();
function in PHP to unlock te session.Allan,
There is only one table. However, it is constantly being hit with the "reload()" request. If you think this MIGHT be a way to get it to work, I will investigate further. Somehow it seems that the jqXHR pointer that I'm finding cached at that location is no longer pointing to the in-flight XHR... Not exactly sure how to find out where the pointer is getting lost/reset, but it's a jumping off point at least.
I will also talk with the back-end team. Maybe something similar is happening as pingvis' problem, though it doesn't seem likely. I believe my request for data is non-blocking.
Cheers,
Greg
That would happen if another xhr has since been made.
DataTables will set the private
jqXHR
property when the$.ajax
method is executed. So as soon as that function has completed (and not before) thejqXHR
property will refer to it.Allan
There are other XHR, but on different tables. Is the jqXHR not private to each instance of a DataTable?
Yes - it is unique to that settings object and each settings object is unique to the DataTable.
Allan
If it's unique, then my method should have worked. :-/ Confused. I could go back for round two, but in the meantime I re-architected how polling works in my application so I don't actually need to cancel it anymore. ;)