(Using 10.7 for now—upgrade to 11 is planned but not scheduled yet.)
In my web app I have implemented client-side on-load JavaScript that implements deferred loading of the results of long-running queries. The JS finds elements that represent callbacks to the server and makes REST calls that are then dispatched to an appropriate worker server based on worker load.
These queries can take minutes to run and return a result back to the browser, where the result is added to the HTML page, replacing the original element.
In order for the server to maintain the HTTP connection while the query runs I had to turn off the server time out. This works but seems like a crude solution.
My question: Is there a better way to manage this kind of client-to-server-to-client communication for long-running queries? For example, is there a way to have the response timeout be more dynamic? I didn’t see anything but I haven’t had time to push on it hard. The result I was getting in the browser with the default 30-second timeout was that when the response eventually returned, the browser reported that the connection had already been closed so it couldn’t do anything with the result. I’m using fetch() to get the result:
fetch(url).then(function(response) { return response.text(); }).then(function(data) { const parser = new DOMParser(); const doc = parser.parseFromString(data, 'text/html'); … update web page … }
Where “url” is the REST call back to my server.
My infrastructure *should* be protecting against long-running queries blocking the main web-serving worker, but it still seems dangerous to have no time out (or a timeout set to 10 minutes or something).
Thanks,
Eliot _____________________________________________ Eliot Kimber Sr Staff Content Engineer Digital Content & Design O: 512 554 9368 M: 512 554 9368 servicenow.comhttps://www.servicenow.com LinkedInhttps://www.linkedin.com/company/servicenow | Twitterhttps://twitter.com/servicenow | YouTubehttps://www.youtube.com/user/servicenowinc | Facebookhttps://www.facebook.com/servicenow