views:

89

answers:

4

I have a email queue with email to be send. A webservice calls a SOAP webservice that processes the queue one by one.

We send email using an external vendor using their REST API. My problem is that calls to this API can take from 0.1ms to 12s. We sent thousands of emails to customer that subscribe to our notices and it important that in each batch there's not to much delay between the first compared to the last in the queue (ideally they'd be sent in simultaneously).

I've complained to the vendor but as they suck I'm quite sure they will not do anything about this.

Can I somehow Threadify this process, instantiating simultaneous calls to the server? The server is also my web server so I can't use all the juice. How many threads is appropriate? Is this a good idea? What's the best way to generically manage these threads?

+3  A: 

You shouldn't be creating threads within an ASP.Net application. If you have a large enough queue to warrant multithreading you should create a windows service to handle the queue.

Spencer Ruport
You shouldn't use threads **for this**. Threading in ASP.NET does have it's uses.
Henk Holterman
@Hank: In highly specialized cases perhaps. Personally I feel that multithreading inside a web app destroys the model.
Spencer Ruport
It is trickier than in other models but ASP.NET has some provisions for threads. Think about needing 2+ queries for a response.
Henk Holterman
+1  A: 

I have had some success with ThreadPool.QueueUserWorkItem() for a ASP.NET app. You can google for some usage examples.

jkchong
+1  A: 

I would queue the email in a database table and generate a separate windows service that reads from the table and spawns a thread for each email, up to some max thread limit. The database can also be used to capture throughput time.

You also should find out how many simultaneous web service requests your vendor can handle. BCC yourself on the emails to find out if simultaneous submissions on your end end up as a single-threaded transmission on their end. And perhaps start shopping for an alternative to this vendor (you did say they suck).

If you want to get fancy and offload the effort from your own server, you send a batch of emails to a cloud service (Amazon Web Services, Microsoft Azure, or Google App Server) and spawn a process on the cloud to spray the emails to your vendor simultaneously.

You can also send the emails directly from the cloud, at least you can with Amazon. They provide a default limit, but then here's a link on how to remove the limit: http://aws.amazon.com/contact-us/ec2-email-limit-request/.

ebpower
The good thing with the vendor is that they know how to handle sending loads of mail to hotmail, gmail etc. There's specific rules that you need to apply for each domain.
Niels Bosma
A: 

There is no need to spawn threads yourself. The class generated by visual studio to access a web service already contains asynchronous methods. For each webservice call Foo, you will see that there is a BeginFoo and EndFoo method. The BeginFoo method will immediately return an IAsyncResult object while the webservice call is done in another thread.

See this MSDN topic for more information on how to use IAsyncResult.

Wim Coenen