The Right Tool / 04.27.13
Re-inventing the wheel
When I first decided to build the Jukebox, I decided I would try to write my own long polling mechanism on top of ASP.NET. My thinking was that this would allow me to have as much control of the pipeline as possible, as well as give me exposure to implementing a mechanism that I have never really worked with before. I leapt in, both feet first. This approach worked well for me up through development of the Jukebox and testing, right up until I published my first build out to my production server. That's when I noticed my entire web app locking up (seemingly) randomly. I discovered that there were about 10 requests being locked up on the server, 10 requests which Microsoft Licensing, in all its wisdom, decided to enforce as the upper limit for a single application on IIS on top of Windows 7 Professional. While I was able to mitigate this over the past week by ensuring that old requests got completed and flushed out of the system, I knew this was ultimately an unsustainable approach to hosting my Jukebox service.
I had known about SignalR for a long time, since before I started building the Jukebox, but had decided not to use it, figuring that simple long polling would be enough for my uses. As soon as I ran into the issue with IIS, I rather quickly decided that a SignalR application hosted outside of IIS would be the best fit for my needs.
I always enjoy re-inventing the wheel, because it not only gives you a better sense of how the 'wheel' works, but also gives you a greater appreciation for the craft others have put into their 'wheel'. While the IIS issue was frustrating, I'm glad I came across it in such a small project and learned my lesson here on my own time and was able to switch over to SignalR in a couple of days. Knowledge is power, kids. Don't be afraid to re-invent the wheel, as long as you know when to cut your losses and learn from your mistakes!