seperate service thread

[PJ]

I'd like to create a subsystem in my asp.net application that is responsible
for emails that need to be send out based upon certain events so that the
main request/response threads aren't responsible for the communication with
the smtp server, etc. I don't want to create a seperate thread for every
instance in which a notification must be sent...I'd rather record the
necessary information to the db or web cache and let the subsystem be
responsible for it from there. What is the best way to go about
this....should I just launch another thread upon application start? What do
I do w/ the thread when it has no responsibility. Should it just loop, look
for work and do work/sleep for a few seconds, etc?

I'm sure someone has done something like this before or come across some
article, etc...I appreciate any comments.

~Paul

 

[Steve C. Orr [MVP, MCSD]]

I suggest you look into using a Windows Service to handle such background
tasks.

Here's more information on Windows Services:
http://msdn.microsoft.com/library/d...nvssamp/html/vbcs_CreatingaWindowsService.asp

 

[David Browne]

I'd like to create a subsystem in my asp.net application that is responsible
for emails that need to be send out based upon certain events so that the
main request/response threads aren't responsible for the communication with
the smtp server, etc. I don't want to create a seperate thread for every
instance in which a notification must be sent...I'd rather record the
necessary information to the db or web cache and let the subsystem be
responsible for it from there. What is the best way to go about
this....should I just launch another thread upon application start? What do
I do w/ the thread when it has no responsibility. Should it just loop, look
for work and do work/sleep for a few seconds, etc?

I'm sure someone has done something like this before or come across some
article, etc...I appreciate any comments.

Here's a type called SingleThreadWorkQueue for this kind of thing. When you
create a SingleThreadWorkQueue is creates a thread and a Queue. The thread
pulls items off the queue and then invokes a delegate (a function outside
the type), and passes it whatever was on the queue.

So you would just bundle up the information to send an email into an object,
and pass it to SingleThreadWorkQueue.AddWork. The worker thread would then
dequeue the work and invoke your work function.

Like this:

--- somewhere in global scope ----
public shared OutgoingEmailQueue as new SingleThreadWorkQueue(addressOf
SendAnEmail)

public shared sub SendAnEmail(work as Object)
dim em as MyEmailInfo = directcast(work,MyEmailInfo)
--send the email
end sub


---- anywhere you want to generate an email, somehting like ----



MyGlobal.OutgoingEmailQueue.AddWork(new EmailObject("(e-mail address removed)","helo,
joe"))





Private Class SingleThreadWorkQueue
Private workQueue As Queue = Queue.Synchronized(New Queue())
Private wp As DoWork
Private wt As Thread
Public Delegate Sub DoWork(ByVal w As Object)
Public Event ExceptionOccured(ByVal e As Exception)

Public Sub New(ByVal WorkProc As DoWork)
wp = WorkProc
wt = New Thread(AddressOf workerThreadProc)
wt.IsBackground = True
wt.Name = "worker thread for " & wp.Target.GetType.Name & "." &
wp.Method.Name
wt.Start()
End Sub

Private Sub workerThreadProc()
SyncLock workQueue
Do
Monitor.Wait(workQueue, 5000)
Do While workQueue.Count > 0
Try
Dim w As Object = workQueue.Dequeue
wp.Invoke(w)
Catch ex As Exception
RaiseEvent ExceptionOccured(ex)
End Try
Loop
Loop
End SyncLock
End Sub
Public Sub AddWork(ByVal work As Object)
workQueue.Enqueue(work)
If Monitor.TryEnter(workQueue) Then
Monitor.Pulse(workQueue)
Monitor.Exit(workQueue)
End If
End Sub

End Class

 

[Steve C. Orr [MVP, MCSD]]

This could work in some cases, but if the thread is especially long running
I'm afraid it could time out once the initiating thread (the ASP.NET page)
is long gone. A windows service should never time out, so it might be a bit
more reliable. A Queue could still be used to store up the list of to-dos.

 

[David Browne]

This could work in some cases, but if the thread is especially long running
I'm afraid it could time out once the initiating thread (the ASP.NET page)
is long gone. A windows service should never time out, so it might be a bit
more reliable. A Queue could still be used to store up the list of to-dos.

You wouldn't want to run especially long running things this way. Just
things that take too long to do while your user is waiting. Sending an
email is a perfect use because it can take about a second to do all the SMTP
stuff, and you just don't need to add that to your user's wait time. I also
use this mechanism to write to my log file. Multiple threads can add log
entries very quickly and the worker thread writes them all out to disk.
Things you might be tempted to use the ThreadPool.QueueUserWorkItem for if
that weren't frowned upon in asp.net, and things that require access from a
single thread, like a file.

A service will work, but for something like this I think it's not really
worth the hastle of administering and configuring the interprocess
communication.

David

 

[PJ]

This is good stuff. Excuse my ignorance, but why is it necessary to use a
delegate? Why can't the wrokerThreadProc just call SendAnEmail directly?

Thanks~
Paul

 

[PJ]

I'm curious about this as well. What exactly would time out? I assume
"time out" means certain object instances would be recycled? If the page
instance is recycled, how will it affect a worker thread if the thread is
not referencing any of the page's members? Will an object created in the
page, i.e. an EmailObject, that's passed to the queue get recycyled if the
page instance does?

Thanks for the clarification?

 

[Steve C. Orr [MVP, MCSD]]

Once a page has been rendered, any threads it created are eventually
orphaned and become potential targets for the .net garbage collector. How
often the garbage collector runs varies, depending on the load of your
server & such.

David is right that this won't likely be a problem if all the thread is
doing is sending a quick email to an exchange queue. Once the email has
been generated and is in the queue, it shouldn't matter if the thread that
created it gets recycled. However, if the code is only doing something
really quick like that then I'm not sure why you'd need a separate thread
for it anyway.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://Steve.Orr.net

 

[PJ]

There's a noticable difference when holding up the main response/request
thread at times. Also, some CDONTS errors seem to slip through any error
handling we have in place.

As far as orphaned threads...

What if I use a Singleton instance to create the thread? This singleton
could behave much like David's code snippet. The worker thread could be
created in the static constructor. Will the worker thread still be a target
for the garbage collector? I don't see how....I mean, if I add an item to
the web cache in a page instance, it doesn't get marked for garbage
collection, right?

Thanks for your time.

Public Class NotificationManager
Private Sub New()
End Sub

Shared Sub New()

'start thread with addressof Notify
End Sub

Private Shared ReadOnly _instance As NotificationManager = New
NotificationManager
Private _notificationList As Queue

Public Shared Function GetInstance() As NotificationManager
Return _instance
End Function

Public Sub AddWork(ByVal work as Object)
'add email data to queue
End Sub

Private Sub Notify
'loop, check queue, send email, etc
End Sub
End Class

'client code
NotificationManager.GetInstance().AddWork(myEmailObject)

 

[PJ]

Also, if the Singleton instance holds a reference to the thread ( as a
private class member ), will that not prevent the thread from being garbage
collected?

 

[David Browne]

Once a page has been rendered, any threads it created are eventually
orphaned and become potential targets for the .net garbage collector. How
often the garbage collector runs varies, depending on the load of your
server & such.

Nope. Threads are roots. A running thread and everything it references is
safe from the garbage collector. Even if this weren't the case, the static
reference to the thread would keep it reachable and keep it from being
collected.

David

 

[David Browne]

Also, if the Singleton instance holds a reference to the thread ( as a
private class member ), will that not prevent the thread from being garbage
collected?

The garbage collector never collects running threads. But you are right,
singletons are never collected because of the static (shared in VB)
reference. Classes are roots, just like threads are roots, and so any
object referenced by a class is not elegible for collection.

David