Defensive event publishing in .NET – Part I

re: Defensive event publishing in .NET – Part I

obiwanjacobi — Tue, 24 Apr 2007 11:48:15 GMT

If you call every delegate asynchronously, you hit the thread pool pretty hard if you have a lot of subscribers (and thread pool resources are precious ;-).

As an alternative you could consider calling the FireClickedEvent asynchronously. That way you only eat up 1 thread of the thread pool. This is of course only an option if the event is not too time-sensitive and subscriber would still get predictable/expected behavior when their handler is called with a certain delay...

re: Defensive event publishing in .NET – Part I

damien — Thu, 08 Feb 2007 07:34:38 GMT

Im an advocate of the fail-fast philosphy on exceptions.

I absolutely never want to gooble up exceptions the way you proposed in your delegate invoke with try/catch.

Unless your program recognises exactly what the exception is and can take steps to rectify the situation, it should fall over in a heap.

re: Defensive event publishing in .NET – Part I

Herman van der Blom - sr. software architect — Tue, 23 May 2006 13:30:17 GMT

Thanx, this was just where i was looking for. I have a windows service which is capable of sending messages with remoting to listeners with events. If one of these messages fails it has to be logged and the service is continuing delivering its messages to the other listeners. After study of the logged error i make sure these exceptions will not happen again. But thats why defensive events are a very good way of programming. In the ideal world everything is always running fine, but we all know this is not the case. So i want to make sure i catch all glitches the right way, and i think this is a very good way.

Defensive event publishing, a different approach

TrackBack — Fri, 08 Apr 2005 03:00:00 GMT

Defensive Event Publishing for Remoting

TrackBack — Thu, 07 Apr 2005 19:17:00 GMT

Some possible additions to Roy Osherove's comments on Defensive Event Publishing in .Net, with special attention to some performance scenarios introduced by Remoting.

re: Events, Delegate and Multithreading

TrackBack — Sun, 16 Jan 2005 07:34:00 GMT

re: Raising C# events doesn't feel right (and seems to have problems too)

TrackBack — Fri, 14 Jan 2005 17:22:00 GMT

re: Defensive event publishing in .NET – Part I

Eric — Tue, 11 Jan 2005 05:31:00 GMT

A couple of notes, based on my own recent experience:

1. BeginInvoke uses the threadpool. What happens if one of your subscribers never returns (intentionally or not; maybe they deadlocked)? After 25 (per processor) BeginInvokes, all of your events -- even to other subscribers have effectively been DOSed.

One way around this would be to spin off a separate Thread (not a threadpool thread). Obviously it's still possible to DOS that situation, but it will take longer, and be easier to debug (since you'll see the absurd number of threads in Task Manager etc, rather than just having the events mysteriously stop). Alternatively you could implement a timeout and Abort any thread that took an absurdly long time to finish.

2. I can think of one situation where you might care about detecting "dead" clients. If you're a remoting server and you're raising remoted events back to the client, it might be useful to detect that a method call threw a remoting-related exception (such as a SocketException) and remove that subscriber, log the error, etc. Of course, removing the subscriber can be somewhat tricky given that only the class declaring the event can modify the subscriber list, at least without a little additional legwork. I may write up the solution we're using and post it on my site, as it seems to be working out rather well.

re: Defensive event publishing in .NET – Part I

tal — Sun, 09 Jan 2005 19:29:00 GMT

the
try(

}

catch

{}

is a bad way to solve the callee execution problems.
and of course it is a performance pennalty.

I believe there is a better way to know if the async call finished correctly(To query it - after some time)

There is also a mix between the async world and sync world.
Do i really want to create a new thread for each event firing? and what if i call it 10000 times?

Do i know my subscribers ?
This generic Solution has many drawbacks in order to get for the pure goal of being Generic

Do i really want to create an

re: Defensive event publishing in .NET – Part I

Roy Osherove — Sun, 09 Jan 2005 14:01:00 GMT

Ian, let me start with the end of your reply:

“To start from the point of view that there could ever be just one correct way in which to write event sources is a flawed assumption. There are many viable and very different ways in which to use events in .NET. You have illustrated just one of them. Yours is by no means the only way, and is demonstrably the wrong way for certain important event-based scenarios. (E.g., your approach is badly broken for raising events from a Windows Forms control.)
In short, your statement:
"When your componenet fires an event it should *never in a million years* care what any of the subscribers do with the event. "
is a pipe dream.”

- I never said there is only one way, I stated that this approach is preferable for the “fire and forget” kind of publishing that we want to achieve. Truly, there are cases where this does not work. However, as I stated in another comment, you can (and do) have both an async and standard “Fire” method on the EventsHelper. The standard one can be called when you want sync invocation. Everything I’ve written here prescribes to the “fire and forget” scenario which is the most widely used scenario for event sources in your components that I know of. There are others, but they are not the issue for this article.

“Consider the specific case of exception handling - are you saying that Windows Forms takes the wrong approach here? It has an exception handler in its event processing loop. This means that if an event handler allows an exception to propagate back to the event source, there is a centralized mechanism for dealing with this.”

- I think it’s flawed in that the event invocation loop stops at its tracks right there, and that you “automatically” are stopped without notification. Sometimes that’s what you want, more often it’s not. The thing is, you can’t control it unless you specifically loop on the invoation list and decide what to do there.
Would you agree that if 3 subscribers get the event, and 7 don’t that’s a flaw in your program(There are scenarios which call for this behaviour, but mostly, this is not what you want)? If someone got the event, everyone should get it. Or you should at least be informed that they didn’t get it.

“(So long as event sources don't attempt to swallow the exception. The code you show here would fail to operate correctly in this scenario.) “

The point is that I don’t know nor care if they swallow the exception or not. If I have a logger that listens for the event, it’s a non-priority for my component to know whether the logger did it’s job, how long it takes to write to the log file, if it threw an exception or what not. That’s classic fire and forget. Now assume I have multiple loggers, I want them all to get the event regardless how each one operates. If one fails and that means others won’t get the event, you’re not just coupling the event source to the failed handler, you’re also coupling the *other* subscribers to all the other subscribers in your notification list. Like I said – usually a no no in a fire and forget scenario.

”Note that this particular aspect of the way events are handled in Windows Forms is ENTIRELY compatible with your stricture that an event source shouldn't care what the event handler does - controls in Windows Forms don't need to do anything special to enable this to work - they just let the exception propagate up. “

- That’s because usually events are thrown on the main GUI thread anyway. And remember that now you have full control over your event subscribers so you can make sure you don’t “hang” the application as you listen for events. I mean, you don’t want to do that on purpose, do you?

”In fact if you follow your own advice - that an event source shouldn't make assumptions about the event handler - then surely you MUST NOT swallow exceptions like you are doing. By swallowing the exception, you are making the assumption that the exception was unimportant - sure you need to know a lot about the code that threw the exception to be able to make that decision! “
- I think that’s the wrong approach. Because I can’t assume anything about the code I have no idea what kind of exceptions it could throw, nor how I should handle them. Suppose that a logger threw a “WriteLogException” in the event handler and was bad enough not to catch it on its own. What is my event source supposed to do with that exception other than to make sure it does not interfere with propagating the event to the rest of the subscribers? (again – this is the case for fire and forget).

”I think you are assuming a very specific use case for delegates and events here. The truth is that there are many different behaviours that an event source might reasonably implement for exceptions, depending on how you are using events. “

- exactly – I’m assuming this is a fire and forget model, nothing more nothing less.

”But I think that swallowing the exception is pretty much the wrong thing to do in the majority of circumstances. At a bear minimum, it should log some kind of diagnostic trace. “
- That’s possible and arguable a good idea, but it has to be implemented on a per application/component basis. For example – how would you log that a logger that tried to log your event has failed? By raising another event? By making an internal logger? How would you know *not* to log a logger failure event? You’d have to do some serious hoop jumping in order to verify what you want pr don’t want to log. All I’m saying is that it’s possible, but needs thought.

”It's not clear what you think a "standard callback" is. In Win32, the term callback typically refers to a single function callback, so it doesn't even make sense to talk of multiple subscribers. “

- I’m referring to the logical callback term. There are many ways to implement asynchronous or event based execution. Firing events is just one of those. You could also except an interface of the subscriber and invoke methods on it directly from the event source. You could also send the event source to the subscriber to create a “push-pull” model where the subscriber “pulls” the event stack from the source. These are all valid mechanisms. I would refer to the term callback logically as a way to invoke methods and follow them invocation through to the end (making sure they are finished, getting a value back, etc.). Although events are using a callback mechanism technically, the fire and forget model I think of does not have this notion of callback (i.e it does not care what happens after raising the event).

- Again, you seem to have a very specific use of the event/delegate mechanism in mind here: why are you assuming that I probably don't care whether the message got to all the subscribers? Given that the under the covers, events are raised by calling functions through delegates, it's certainly possible for me to know when the handlers have finished.
- possible, but logically that would be wrong for the fire/forget model. Just like it would be wrong to invoke private methods of a class using reflection, even though you can do that too.

“So who are you to declare that nobody is allowed to design a system that takes advantage of this? (Especially when there are examples of systems that do depend on this very feature in the .NET Framework already.) “
- I am saying that this holds water for a fire/forget model. For that I would as a rule try to stay clear of such assumptions on the event handlers my code sends messages to. Other thatn that I’m a developer such as yourself :)

”Well now you're changing the subject - the fact that certain static data is never collected is entirely unconnected with how you do event notification. Using the [OneWay] attribute will make absolutely no difference to that. And everything else will get collected whether you use [OneWay] or not. “

- The subject got changed for me when you claimed that the GC will take care of the resources. The fact is that there is one delegate that will be held in memory – the on inside the EventHelper class that is supposed to call the InvokeDelegate method. As such, it will hold information about the past calls, unless you put a [OneWay] attribute on the event handler for that delegate (which is “InvokeDelegate”). And yes, this has nothing to do with the defensive event strategy mentioned in the article. It’s just a technical problem that is resolved and must be mentioned.

”My point was that the use of the [OneWay] attribute doesn't actually contribute anything useful when it comes to reclamation of resources - the resource handling behaviour is unaffected by this attribute.
- I think you’re wrong. The memory leak isn’t a “leak” really, just a resource hog that gets bigger as the delegates are called time and time again. If the delegates are not claimed by the GC (because they are used in a system that is up 24/7 that could be a problem. The attribute solves our problem in that It rids us of the need to save the call information.

[About not having to call EndInvoke]
”This is unequivocally wrong!
You MUST call EndInvoke whenever you call BeginInvoke, even if you don't care about the results. That is the whole rule. The documentation is clear about this. (At least it is now.) “

- I beg to differ. I know you won’t believe me, so I’ll just quote Don Box’s Essential .Net part 1 on async execution:
-----snip------
“Technically, it is legal to omit the call to EndInvoke if the results of the call are not important. This mode of invocation is sometimes called fire-and-forget, or one-way invocation. One typically uses this invocation style only with methods that do not have a return value and have no pass-by-reference parameters. One also uses this invocation style only when one can safely ignore method failure, because any exceptions thrown by the target method will be swallowed by the CLR in fire-and-forget scenarios”
-----snip-------

”The documentation for OneWayAttribute says nothing about making EndInvoke optional. So there is no reason to suppose that applying [OneWay] will make it clean everything up for you. “

- that’s not why I’m using it, and that’s not what its for. It’s only for the sake of suppressing exceptions from serializing, and from preventing various other data to be saved in tot her delegate making the call. It has nothing to do with EndInvoke.

”f you don't hold onto the call object (IAsyncResult) the GC will detect that it's unreachable, and that will mean all the resources it allocated are also now unreachable. Finalizers run, objects are collected, the resources are now freed. “
- which is not the case with my “AsyncDelegate inside the events helper class.

”If you want to be robust for the future, you *must* call EndInvoke. Whether you apply [OneWay] or not.”
- see my reply on this comment earlier quoting Don Box.

”Again, you're defining arbitrary restrictions on the use of the event mechanism. There are many viable uses, and you're just characterising a subset. “
- True, there are other scenarios, but that’s what this article is about – fire and forget.

”In-process, there is no reason to suppose that event notifications aren't every bit as reliable as method calls, because that's really all they are - method calls indirected via a delegate. Do you really write your programs assuming that any time you call a method, that method call might not get through? “
- Not the same thing. When I call a method I can assume that if something bad happens, I know about it using an exception. If not, I also know in advance that some method does not throw exceptions. In any case – I know what to expect. When firing events – I have no idea whether I will get an exception, or what will happen when I do. Actualy I know that in any case of exception, the events will stop firing. That’s bad design. So this is a way to overcome that. Just like if you get an exception with standard method calls you want to either catch it or pass it on, I want to be able to do the same thing.

“That degree of paranoia would make sense in a distributed scenario, where of course remoted method calls are intrinsically unreliable, and you do need something heavyweight for reliable delivery. But it's generally reckoned to be a bad idea to use events across process - they are really designed to be used in-process. “

- not the scenario we’re talking about here.

“And in-process, there's just no need for paranoia about whether a call will get through - if my process is alive, method calls will succeed. If my process has hung, well, that's pretty much the end for that process. “

- Would you accept a state where if one method threw an exception you knew that calling other methods would succeed? That’s the case here. You at least want to have control on the situation.

Are there scenarios where an event subscriber might be prepared to make the sacrifice of being thread-safe in exchange for being allowed to take a long time to handle the event without blocking other handlers? Of course there are. Are there scenarios in which that looks like a very unattractive trade off? Yes indeed.

- like I said – you can accommodate for both scenarios using the EventsHelper class.

”While it is possible to come up with use cases for events that meet the assumptions you seem to be making, that's by no means an exhaustive list of all possible uses of event handling. “

- true

“But there are plenty of examples of event sources that *do* impose the restriction that the handler must not take a long time. Windows Forms is full of them. If your event handler blocks, the applications will freeze. And as it happens, your examples here also impose some restrictions on handlers. “

- and you normally don’t want your program to freeze, right? That’s the same case for the events helper

“You can't avoid coupling entirely. And arguably, your final design entails much more egregious coupling between event source and handler than your original 'innocent' example. “
- The coupling is to the delegates, not to the targets. It must be done in order to accommodate for the lacking features in the event model today for fire-forget scenarios.