GWT-RPC-AsyncCallback

[Paddy]

Hi All,

We have a UI application, where user searches for records and exports the data to an excel. Once the export is completed at the server side, it notifies the client by async call back and then there is code at client side to give a popup to the customer saying, the file is ready for download and give an option to download the file from server.

However, when server side fetch takes more than 3 minutes, the client is closing the socket(I think). Though the report is getting generated at the server, the user is not getting the pop up to download the report. Is there anyway to stop the client from closing the socket? This issue happens only when there are more than 400 records to be fetched. One way to fix this, is to fix the fetch (which at this point cannot be done as there are some encryption calls happening during this). But wanted to know if there is any timeout parameters that can be configured, so that we can somehow stop client from closing the socket?

I am seeing socket timeout exceptions in the GWT logs.

[vie...@gmail.com]

Hi Paddy,

maybe you can split the request. ATM you trigger the export and fetch the data. I suggest to write a request for trigger the export (and you receive a unique export id) and then check the download service from time to time with the export id. If the export is not finished yet the callback is rescheduled, otherwise you fetch the data. 

I think you can build better solutions with webhooks and stuff, but the main idea is split the two actions ;)

Hope this helps.

Norbert

[JonL]

Depending on your architecture, the server generating the file might not have any control over the timeout.  You could have proxies, firewalls, etc that can affect the timeout.  It is best to remove the timeout from the equation.  

If you can not fix the fetch, I would split it into a call that spawns a separate thread to do the generation, returns to the client saying "your request was successful and is pending", then use a secondary async call to poll periodically to check if the file creation is finished, then when available, the user can click a button to download and you can immediately write the file to the browser.  The secondary request could possibly include progress to display to the user if you can provide feedback on the number of records being processed, etc.