In my application, the client can request a complex task that could take 1-2 minute to complete. The task runs in a separated thread and the request handler communicates with it via a BlockingQueue.
Currently, the sever immediately redirects the client to a waiting page which polls the server every 10 seconds. However, this is quite inefficient and the client may have to wait for an extra 10s if the task finished right after a poll.
What I would like to do is to allow the request handler (for the waiting page) to be blocked until the task is done and only then write the response to the user. Based on my observations, most browsers will use a longer timeout if the server accepted the TCP socket (and maybe has written back some header??), but I am not sure about the exact timeout across different browsers.
Is it realistic to make the browser wait for 2 minutes? Does anyone has any experience on this or better ideas?
Have you thought about Push Notification.
What you have currently in place is Pull notification where you poll server for response.
In pull server will let you know when response is ready, Its called comet aka reverse ajax.
In this case your browser doesn't need to wait anymore, you can proceed with other work and once response is ready, present it to the user.
Yes browser can be made to wait, just dont write the response.
To explain, when you submit the work and then instead of redirecting to a different page, dont commit the response, instead start the server processing and once done submit the response. And in the UI you show processing message so that user knows task submitted is under process.
IMHO I don't feel this will be any good, as It will make your application appear as if it can handle only one request at a time, If that's acceptable then no issues, though given today's technology, almost everyone wants to do more in less time.