2

A simple problem. I have an ASHX handler which generates a report. Unfortunately, this process can take 2 or more minutes to finish and Azure will close the connection before this handler can respond. Why? Because the connection is idle for too long, thus it is killed off.
So, I need to keep this connection alive in some way. To make it a bit more complex, the handler is called from a Silverlight application which will call the handler from a frame on the current webpage or (when not running from a browser) create a new browser instance to call the handler.
My challenge is to get around this timeout with a minimum amount of code. But also, the code needs to work exactly as it does now!

Opening the handler in a separate frame or browser window allows the report to be saved anywhere on the system of the user. If I would download it from within the Silverlight code, I will not have proper write access. There will be no permission given to any Silverlight application that needs to write to the local disk, thus the work-around with the browser/frame.

Wim ten Brink
  • 25,901
  • 20
  • 83
  • 149
  • Credits: The title of this Q is from smarx from his answer in http://stackoverflow.com/questions/4858800/wcf-timeout-issue ;-) That explains the problem, just doesn't provide a solution... (Besides, I use a handler, not a service.) – Wim ten Brink Jul 07 '11 at 12:01

1 Answers1

4

Not too sure about HTTP transport, but you can certainly use TCP keep-alives at the socket level. However, then you need to create socket listener to download HTTP content (way overkill).

Perhaps there is a much simpler solution? Why don't you have the client make the request to generate the report and have the handler return a SAS signature (time limited, read-only signature) to where the report will eventually be put in blob storage. This is very quick and requires no open TCP connection. The report generator should simply create the report in a file to be downloaded at the blob location it sent to the client (any GUID would work here) instead of streaming it back over the response. Finally, the client just needs to poll the location until it gets a file. Now you are nice and asynchronous with short open connections and don't have to worry about this TCP timeout issue. The code to do this is far, far less complex than anything to work around a TCP timeout.

dunnry
  • 6,858
  • 1
  • 20
  • 20
  • Interestingly enough, I was already examining such a solution. :-) It might work. First a call to generate the report, then polling to see if it's finished, then finally download the thing... Still, since Silverlight can't download and save files to the local disk (or even network) I still need the handler to get the report from the blob storage... – Wim ten Brink Jul 07 '11 at 15:22
  • Why do you need to download it? Just set the correct MIME type in blob storage and it will stream and be interpreted by the client. All your handler will do is set a MIME type and read and stream bytes. You can do that directly from storage without downloading to disk. – dunnry Jul 07 '11 at 15:25
  • It needs to be downloaded because it's a report that the user needs to store on their local system. For example, to be printed, sent by email or just stored for future references. The download is done on the client, and Silverlight can't write to the local hard disk. The user needs to have it on disk, though. – Wim ten Brink Jul 08 '11 at 08:58