This is a two-parter. The first part is to say, hey, look at this sweet hack I've
discovered in the Oxite
source*! The second part is to ask, hey, is this a good idea?
* the
refactored Oxite source, that is
Background services
First, let's give a little detail here—background services are long-running
tasks that Oxite needs to run periodically. These are things like sending emails and
sending trackbacks—necessary, certainly. But, they shouldn't be running while
some chump stares at his Netscape window waiting for the site to finish sending 1000
spam trackbacks. He should be able to post to his blog, receive an immediate response
indicating the post is now available, and the trackback spamming can commence later.
Background services are the things you can put off, the things that don't have to
finish before sending a response to your website patrons.
These background services are called by many names—I've heard cron jobs, timer
jobs, background jobs, jobs, "the heartbeat," services, and tasks. In Oxite
they're called background services.
Look at this sweet hack!
The full source is below, but I'll attempt a walkthrough of the solution here. First,
to explain the problem: we must achieve the impossible—we must
somehow emulate a continuously-running Windows service inside an IIS worker process.
This means we must periodically trigger jobs to run, but we can't monopolize valuable
worker threads. And we certainly can't delay responses to send 30000 spam
trackbacks. We've got to run, but we can't run anywhere in the ASP.NET page/request
lifecycle! It's a conundrum.
What the Oxite team has done to achieve the impossible is, plainly, to cheat—they
use a System.Threading.Timer.
How they manage the impossible is a lot like juggling—magic juggling.
Enter stage left: Oxite, the juggler. Oxite takes a background task and throws it
in the air. He takes hold of the next background task (let's start calling these things
bowling pins) and throws it into the air, and moves on down the line. Before
anyone knows what's happened, Oxite has gathered up all the bowling pins, thrown them
all into the air, and made his getaway. Unlike most jugglers, Oxite makes
no attempt to catch bowling pins once thrown! And this is why it's magic.
Let's try to break this back down into code. When Start() first executes [line 28],
the Timer object sets a callback without halting progress [line 43].
This is the juggler throwing a pin in the air.
The callback method is eventually invoked. A thread is spun up* and runs the designated timerCallback() function
[line 56]—and, let's make this clear—timerCallback() doesn't block the
original Oxite web request; it lives in a new thread. And this new thread does its
first dose of work, as shown on line 68 (SPOILER ALERT: it calls
Run()). We're not interested in what Run() does exactly—for today it must
remain a spooky mystery, go look it up yourself.
* precisely how the thread is
spun up is in fact, real magic, or might as well be to my superstitious caveman brain
Ok. Here's where the "magic" part of magic juggling comes in. Because any dunce can
throw bowling pins, and any dunce can catch them, and any dunce, with practice, can
juggle. The magic here is inside the timerCallback() method, where the Timer once
again sets a callback. Each time a background service awakens, it does its work and,
before going back to sleep, sets up the next callback with another call to timer.Change()
[line 75]. That is to say, each time the bowling pin makes as if to land, it spins
back upward into the air!
So there you have it. Oxite takes a bunch of bowling pins, throws them all into the
air, and leaves. As the pins drop down to the ground, the "mystical Timer callback
juggling force" propels them back into the air.
And we're running background threads in the web process. Sweet.
Now the question is: is this a good idea?
Now you understand how background tasks work in Oxite—or can now juggle. I get
confused sometimes. In any case, congratulations!
Assuming I'm not misrepresenting anything, this is how background tasks work in Oxite.
So, now for the question. Is this a reasonably acceptable way to set up background
tasks for a site? I've discussed it some on twitter, but is there anything
particularly nasty I've missed? Will it kill the process? Will it hang all 25 threads?
Or some large portion of them?
I'm curious to hear if anyone has taken this approach, and what their experiences
were.
Full source
From http://oxite.codeplex.com/SourceControl/changeset/view/45053#438025:
1 //
————————————————
2 //
Copyright (c) Microsoft Corporation. All rights reserved.
3 //
This source code is made available under the terms of the Microsoft Public License
(Ms-PL)
4 //
http://www.codeplex.com/oxite/license
5 //
————————————————-
6 usingSystem;
7 usingSystem.Threading;
8 usingMicrosoft.Practices.Unity;
9 usingOxite.Services;
10
11 namespaceOxite.Infrastructure
12 {
13 publicclassBackgroundServiceExecutor
14 {
15 privatereadonlyTimertimer;
16 privatereadonlyIUnityContainercontainer;
17 privatereadonlyGuidpluginID;
18 privatereadonlyTypetype;
19
20 publicBackgroundServiceExecutor(IUnityContainercontainer, GuidpluginID, Typetype)
21
{
22 this.timer=newTimer(timerCallback);
23 this.container=container;
24 this.pluginID=pluginID;
25 this.type=type;
26
}
27
28 publicvoidStart()
29
{
30 IBackgroundServicebackgroundService= (IBackgroundService)container.Resolve(type);
31 IPluginplugin=getPlugin();
32 TimeSpaninterval=getInterval(plugin);
33
34 if (interval.TotalSeconds>10)
35
{
36 #if DEBUG
37 if (plugin.Enabled)
38
{
39 backgroundService.Run(plugin.Settings);
40
}
41 #endif
42
43 timer.Change(interval, newTimeSpan(0, 0, 0, 0, -1));
44
}
45
}
46
47 publicvoidStop()
48
{
49 lock (timer)
50
{
51 timer.Change(Timeout.Infinite, Timeout.Infinite);
52 timer.Dispose();
53
}
54
}
55
56 privatevoidtimerCallback(objectstate)
57
{
58 lock (timer)
59
{
60 IBackgroundServicebackgroundService= (IBackgroundService)container.Resolve(type);
61 IPluginplugin=getPlugin();
62 TimeSpaninterval=getInterval(plugin);
63
64 if (plugin.Enabled)
65
{
66 try
67
{
68 backgroundService.Run(plugin.Settings);
69
}
70 catch
71
{
72
}
73
}
74
75 timer.Change(interval, newTimeSpan(0, 0, 0, 0, -1));
76
}
77
78 //TODO:
(erikpo) Once background services have a cancel state and timeout interval, check
their state and cancel if appropriate
79
}
80
81 privateIPlugingetPlugin()
82
{
83 IPluginServicepluginService=container.Resolve<IPluginService>();
84 IPluginplugin=pluginService.GetPlugin(pluginID);
85
86 returnplugin;
87
}
88
89 privateTimeSpangetInterval(IPluginplugin)
90
{
91 returnTimeSpan.FromTicks(long.Parse(plugin.Settings["Interval"]));
92
}
93 }
94 }
