Hi Nik

I "use" smarter stats and this picks up pings to keepalive.aspx.
I will have a look to see about exclusions.

Thanks for your points and time.

Ian

Hi Plippard,

I took some time to give a look at your site and the solution you propose, and my feeling is that:

• your post in here is a little rude: 
  • First you just posted your own anouncement in that very forum, so I find it some kind of intrusive and offensive that you simply copy paste it into mine. I did post my solution into several threads of people seeking for keepalive technique, which I think is fair, yet I did not post into your previous anouncements threads to pretend that your commecial utility is obsolete.
  • You suggest that the solution I propose is the common and inefficient one; well I don't say that I own that technique (i read it in Rick Strahl's blog) , but to my knowledge it has not been discussed much so far. I'd rather think that pinging the site at a regular time interval IS the common solution, such as in the utility that you sell, or in the code snipet that you provide here. As for the inefficiency, I come to that later.
  • Then in my opinion, the code you advertise is more of an asp.net proof of concept than some real dedicated dnn stuff. As for mine, I had first mentioned the concept in another thread, but I did take some time to build a proper (yet very light) DNN module before I posted an anouncement in here.
• I don't find your solution more elegant nor efficient:
  You set the application to fire HeartBeatEvents at a regular time interval, and the you provide an overriden SQLWebEventProvider to handle the beat events and perform the pinging logic. 
  • Appart from the fact that the app does the pinging itself, there is not much difference in behaviour with the regular pingers. You could as well have implemented the logic in a scheduler client task (set in timer mode). I also think that having to plug an SQLWebEventProvider is quite heavy. You could probably implement your own webeventprovider if the only purpose is to peform the keep alive. BTW, you need to be careful to ping the KeepAlive page rather that the root, cause otherwise this will pollute the site logs.
  • Your code requires manual file configuration.
  • Unlike with external based pingers, the solution you propose should stop working for any application recycling not caused by a inactivity (web.config modification, module installation, IIS alternative recycling conditions). I would think that HeartBeatEvents purpose is to monitor the site's health externally, and potentially send a ping it if the events stop firing rather that when the events do fire.
  • There is still the overhead of regular pings, and no immediate restarting on app recycle. The purpose of my module is specifically to keep the site alive by a single ping at recycle time, thus with practically no offline time at nearly zero cost.
  • App recycle on idle time does not have to be a bad thing by itself. My module does not emulate activity to prevent the application to recycle, it simply restarts the application perpetually. thus it frees unused memory on idle time, while keeping the app awake, which may be expected behaviour. 
  • It does not have to be though, and I think it may be compatible with other monitoring solutions such as your web utility (I do also use a free web ping windows service, and I see no problem with them). Having said that, and considered the fact that no solution inside the app will probably ever be able to monitor and signal major failures, I would rather combine a regular external monitoring system that sends me emails with an inner module that does not ping all the time nor stops on recycling.

Ok loads said already. well I might have sounded a little arch and ticky myself now. I have to admit I felt annoyed.  Now I don't mean to pretend there is nothing good in your idea. I'm pretty sure you can achieve something good with a custom webeventprovider doing some smart stuff.