开发者

How to run server-side code AFTER page render & sending

开发者 https://www.devze.com 2023-01-30 10:05 出处:网络
i hope you guys can help with this :) I need to do stuff after my page is rendered in the browser. In detail, i need to send email/sms and other non-browser related stuff, but the operation takes tim

i hope you guys can help with this :)

I need to do stuff after my page is rendered in the browser. In detail, i need to send email/sms and other non-browser related stuff, but the operation takes time, and i dont want my visitors waiting 5-8s for the success message.

I have tried putting the "After Rendering Code" in the page Unload event. That seems to work - but only on localhost. It does not work on our production server.

So i figgured, maybe this is some IIS setting? I've also read that it's up to the browser, if it will show th epage after rendering is complete - or wait for the whole package to end.

So i tried to end the package with Response.end before my "A-R-C", but that just killed it.

Do you guys have any explanations开发者_如何学编程 or theorys on how to this?


ThreadPool threads may help you implementing this functionality.


You can create a new Thread and call your method on that Thread.


You might look at asynchronously decoupling the Email / SMSing from the page entirely, e.g. by using a MSMQ Queue. This way you will also be able to handle the Emails / SMS in a more robust manner, e.g. retry in 10 mins if the SMTP server is down or the SMS gateway is busy.

Edit : Re : MSMQ vs Thread / Threadpool - Using a new worker thread should also work fine in most cases, however, for high end scalability you might consider MSMQ or similar.

Have a look at this SO post here

Threadpool (or Thread) - Quicker and easier to implement - Unsent SMS's / messages will be lost if the App Pool is recycled - Will compete for threads (recommend using a custom Threadpool)

MSMQ - More work needed - will need to create a new listener process (e.g. use WCF) to process messages - May be difficult to host unless you have control over the server - Can be transactional and persistent - i.e. unsent messages won't be lost even if your App Pool is recycled or server reboots. - Can exercise more control over throughput -throttling and delayed delivery - e.g. send SMS's after hours when it is cheaper

0

精彩评论

暂无评论...
验证码 换一张
取 消