Spinning out a new thread for long running processes?
I've got a site that uploads lots and lots of data to an external web service and potentially can take quite a long time to complete.
On my test machines it runs fine but with the client we get http timeout issues hence we are looking at running this in a separate thread to the main app
Thanks - the Umbraco data pulling side is fine, it's actually extracting the member details that are being stored in an object and then uploading to this third party site which is timing out occasionally.
I can quite easily throw a new thread for the third party upload, just more about how best to do it so Umbraco does not hiccup!
Hi. For my taste spawning child threads in an ASP.NET application is hardly ever a good idea.
1) Most ASP.NET and Umbraco APIs are supposed to be used from within ASP.NET own threads only. Being used in a custom child thread they don't work at all or (even worse) work but far way not as expected.
2) ASP.NET threads come from the .NET thread pool. It prevents uncontrolling rise of application thread count that can happen with manually-created threads when an application is highly lodeded.
3) There's often a problem with unhandled exceptions when you notice no errors but later suddenly realise that your application pool magically recycles again and again at some random points of time.
This is the dilema I have really, I know Asp.net should be able to handle it fine and I don't normally start spinning off spurious threads like this for that very reason, however the client is pushing to get this in and as a result, not sure the best way around it.
Spinning out a new thread for long running processes?
I've got a site that uploads lots and lots of data to an external web service and potentially can take quite a long time to complete.
On my test machines it runs fine but with the client we get http timeout issues hence we are looking at running this in a separate thread to the main app
Is there a preferred way to do this in Umbraco?
Simon
Only things I know of is that Linq to Umbraco is not thread safe: http://our.umbraco.org/wiki/reference/api-cheatsheet/linq-to-umbraco/understanding-the-generated-classes/datacontext. I think the rest should work.
Jeroen
Thanks - the Umbraco data pulling side is fine, it's actually extracting the member details that are being stored in an object and then uploading to this third party site which is timing out occasionally.
I can quite easily throw a new thread for the third party upload, just more about how best to do it so Umbraco does not hiccup!
Hi. For my taste spawning child threads in an ASP.NET application is hardly ever a good idea.
1) Most ASP.NET and Umbraco APIs are supposed to be used from within ASP.NET own threads only. Being used in a custom child thread they don't work at all or (even worse) work but far way not as expected.
2) ASP.NET threads come from the .NET thread pool. It prevents uncontrolling rise of application thread count that can happen with manually-created threads when an application is highly lodeded.
3) There's often a problem with unhandled exceptions when you notice no errors but later suddenly realise that your application pool magically recycles again and again at some random points of time.
This is the dilema I have really, I know Asp.net should be able to handle it fine and I don't normally start spinning off spurious threads like this for that very reason, however the client is pushing to get this in and as a result, not sure the best way around it.
is working on a reply...