nservicebus - IWantToRunWhenBusStartsAndStops not for production? -

new nservicebus (4.7.5) , implemented nsb host.exe hosted service (implementing iwanttorunwhenbusstartsandstops) detects changes database tables , notifies subscribing web apps publishing events, e.g. "customerdatawasupdatedevent". in future perform actual update through messagehandlers receiving commands obviously, @ moment publishing service polls database etc.

it works well, however, approaching production, noticed david boike, in latest edition of "learning nservicebus", states classes implementing iwanttorunwhenbusstartsandstops development , used in production. set database change detection in start method , works nicely, know why discouraged?

here comment in actual book:

https://books.google.se/books?id=rvpzbgaaqbaj&pg=pa110&lpg=pa110&dq=nservicebus+iwanttorunwhenbusstartsandstops+in+production+david+boike&source=bl&ots=u6snii0nm3&sig=qixffovfhcy-_3qdnsexrpwrld4&hl=sv&sa=x&ei=lhwrvc2_bkrwywpb65fibw&ved=0cbsq6aewaa#v=onepage&q=nservicebus%20iwanttorunwhenbusstartsandstops%20in%20production%20david%20boike&f=false

i'll copy answer gave in particular software google group...

---

i'll quote myself directly here:

an implementation of iwanttorunwhenbusstartsandstops great place create quick interface in order test messages during debugging allowing send messages based on console input. apart this, isn't common have widespread use of them in production system. 1 possible production use case provision resource needed endpoint @ startup , tear down when endpoint stops.

i think if add little bit of emphasis "widespread use". i'm not trying won't/can't have iwanttorunwhenbusstartsandstops in production code or avoiding them best practice. trying having ton of them code smell.

above paragraph in book, warn iwanttorunwhenbusstartsandstops not having ambient transactions or try/catch stuff going on. key part. if end throwing exception in iwanttorunwhenbusstartsandstops, tyou can run big problems. if use .net timer , throw exception, can crash process!

let me tell how screwed on in first-ever nservicebus system. system (still in use today, hear) responsible ingesting more 3000 rss feeds (probably lot more now) cms. processing each feed, breaking items, resizing images, encoding attached video mobile ... things handled in nservicebus message handlers, scaled out multiple servers, , fantastic.

the problem scheduler. implemented iwanttorunwhenbusstartsandstops (well, iwanttorunatstartup @ time) , turned mess. kept whole table worth of feed information in memory calculate when fire off next processfeed command. using .net timer class, , iirc, had use threading primitives manualresetevent in order coordinate activity. , because using .net timer, if scheduler threw exception, endpoint failed , had restart. lots of weird edge cases , quagmire of bugs. plus, singleton "commander app" while feed/item processors scaled out, scheduler not.

as got more experienced nservicebus, realized each feed should have been saga, starting feedcreated event, controlled through pauseprocessing , resumeprocessing commands, using timeouts control next processing time, , (perhaps) ended via feedremoved event. have been more straightforward , have executed inside transactionally-controlled message handlers.

that experience led me little bit distrustful/skeptical of iwanttorunwhenbusstartsandstops. not saying it's bad, aware of. prepared consider if you're trying couldn't better accomplished in way.