0

I am building a Push notification system, for Android.

I have an ASP.NET web application, hosted on a commercial hosting provider. I have one page that almost always is in an infinite loop waiting for an event to occur.

One host (Android device) loads this page, and remains connected on a persistent connection, till that event occurs. When it occurs, it serves it, and goes back to waiting for it to occur again.

Now, my question is, Is this page being in a perpetual loop, and always connected to a client going to affect the performance of the rest of the web application?

(I think it should not, because servers handle loads of client connections anyway. Am I correct in assuming this?)

Should I deploy this on a different application pool on the server? Also, is there a better way of doing Push notifications, using persistent connections?

Thanks in advance...

Anirudh Ramanathan
  • 46,179
  • 22
  • 132
  • 191

1 Answers1

2

Based on your description, you're going to run into issues. First, having a page that loops forever is going to cause timeout errors (connection timeout defaults to something like 120 seconds). Which, by the way, will cause the app pool to fail/shut down based on how fast it happens (I've accidentally done this, trust me it's not good).

If you don't have to have 100% real time notifications, I'd use a polling setup (let them hit your page once every couple of minutes). If you do have to have 100% real time notifications, and you're targeting 2.2 on up, use Cloud to Device Messaging. Otherwise you're best option will be to create a server application and not going the ASP.Net approach.

JaCraig
  • 1,053
  • 6
  • 10
  • Oh and phone connections aren't constant, so you'll run into issues with that also going your initial approach. – JaCraig Jul 11 '11 at 01:06
  • Thanks,. I'll look into it.. As for the approach, I am reconnecting on hitting the timeout, and any messages stored for me wait for me. Even with the timeout, and re-connection, wouldn't it be at-least as good as polling? – Anirudh Ramanathan Jul 11 '11 at 02:14
  • 1
    I would say yes, but the app pool is going to shut down. After a number of errors (assuming they are in quick succession), it shuts down. Depending on your host provider, they may restart it automatically but still going to be an issue. The issue is you're not going to run into the issue until you're in production. – JaCraig Jul 11 '11 at 14:03
  • 1
    OK, if you go into IIS Manager and take a look at an app pool's advanced settings, you'll notice a section that says Rapid-Fail Protection. Since you're using a host provider, you can assume that it's on. Basically what this means is that the server is going to ping the worker thread (each connection) and see if it's "healthy". Since you're in an infinite loop, it will assume that it's "unhealthy" and shut the process down. If this happens more times within a specified time frame than the RFP settings state, it shuts down the app pool (the default is something like 5 times in 5 minutes). – JaCraig Jul 12 '11 at 16:02