Saturday, September 14, 2013

[Resolved] Issue with EventListener.OnEventWritten when used In-Proc

Finally I was able to trace the issue why my In-Proc EventListener's OnEventWritten was not being called. In order to understand it let's create a sample console application targeting .net framework 4.5.



Let's add a simple method to write event when a request is received for password hashing. It has an EventId set as 1.


Now add an event listener as follows:


Now let's first enable the events for the listener after instantiating this. We can now call the EventSource method to write event data. When we run this EventListener's OnEventSourceCreated does get called but there is never a call for OnEventWritten when the event data is written. If we set a breakpoint there, it never gets hit.


Now let's change the code a little and remove the keyword detail decoration from the EventSource's method as follows:



Without changing anything else, let's run the application again. Now we notice that the break point in MyEventListener.OnEventWritten does get hit.



Connect Issue
I have logged an issue here on Connect. Let's see if we are missing something here:



Resolution
In order to enable events by the listener, we need to be clearly specifying the keywords we are interested in. There can be more than one keywords used with bit masking (that's why the keywords should have enumeration values in the power of 2). We can also enable the listener for all keywords using Keywords.All. [Thanks, Alex Ghiondea!]


Download


2 comments:

Luca Jonathan Panetta said...

Hi Muhammad,

great post. I found that method LotToSqlDatabase's behavior is correct because if you make

for (int i = 0; i < 1000; i++)
ApplicationEventSource.Log.RequestPasswordHashing(1447);

it log all correctly.

As you know at the end of the processe is better to Dispose the object listener.

Best Regards
Luca Jonathan Panetta

Muhammad Shujaat Siddiqi said...

Hi Luca, Thanks for nice words. Actually you need to specify the keyword when adding the listener. Although the issue is not fixed, this workaround can be used. In this case, I would generally assume that it would use ALL keyword by default.