Dear Randy,
I have created a discussion http://entlib.codeplex.com/discussions/574964.
To know what is causing issue while I logging string length more than 32723 in Out of Process.
Because I have created a class and the method for writing logs in to blob and it was working fine in “In-Process” type of logging with large length of allowable string data type.
But the same source code is converted as dll and placed in out-of-process semantic logging folder called via xml file through custom sink tag but unfortunately it was not logging large size string (>32723) and also it was not throwing (log) any error.
Initially it was throwing proxy error and I have fixed proxy error by put some code and now it is running fine.
Be simple, Out-of-Process is not logging payload string which is having length more than 32723.
I’m using Event level as Log always.
Also I’m using semantic logging custom sink unhandled fault method to write logs when exception happen in a method. Error logging is not happen.
SemanticLoggingEventSource.Log.CustomSinkUnhandledFault()
If I’m using above code , definitely this should get some error log when method is throwing error. Am I right?
Moreover , How to disable events and close the listener in custom sink out of process. Please guide me.
Share me the event life cycle of the Semantic Logging custom sink.
1. OnCompleted – Not implemented
2. OnError – Here I’m calling custom sink unhandled fault()
3. OnNext – Here I’m calling my own method for writing logs to blob
Kindly expedite and I Need your help.
Comments: What you are seeing is a limitation in the size of an ETW event. ETW is what is used to communicate between the event producing process (event provider) and the OOP service (event consumer). From [About Event Tracing](http://msdn.microsoft.com/en-us/library/windows/desktop/aa363668%28v=vs.85%29.aspx): # > Events can be lost for a number of reasons: The total event size is greater than 64K. This includes the ETW header plus the data or payload. A user has no control over these missing events since the event size is configured by the application. # You are hitting the 64K limit but the string length does not necessarily have to be 32723 -- it depends on the total size of the event (e.g. in my testing I hit a slightly different number). The reason why a single string of about ~32000 characters is hitting the 64K limit is that 2 bytes is allocated per character. What happens is that the in-process ETW buffer is too small to accept the incoming data so the status ERROR_MORE_DATA is returned and the message is never published. You can see that the message is not published by enabling exceptions on the EventSource (pass true to the EventSource base constructor) to see that an exception is being raised: ``` c# public sealed class MyMessagingEventSource : EventSource { public static MyMessagingEventSource Log = new MyMessagingEventSource(); private MyMessagingEventSource() : base(true) { } } ``` Finally, the occurrence of an error is delivered out of band to the the OOP service and will be written if the "Microsoft-SemanticLogging" EventSource is configured to log. The output would look something like the following: ``` ProviderId : d1ed7ec7-5701-5554-2c5e-796dc42511c5 EventId : 811 Keywords : 4 Level : LogAlways Message : Out of band event level 0 for provider 00000000-0000-0000-0000-000000000000 on session Microsoft-SemanticLogging-Etw-ConsoleEventSink. Message: Opcode : Info Task : 64723 Version : 0 Payload : [sessionName : Microsoft-SemanticLogging-Etw-ConsoleEventSink] [providerId : 00000000-0000-0000-0000-000000000000] [eventLevel : 0] [eventKeywords : 0 ] [eventMessage : ] EventName : TraceEventServiceOutOfBandEventInfo Timestamp : 2014-12-17T18:35:27.2873067Z ProcessId : 10884 ThreadId : 11240 ``` Unfortunately, there is not much useful information in that message. Also, since the limitation is baked into ETW there is not much that can be done short of splitting/truncating long strings or perhaps implementing a retry to try to split/truncate long strings and log multiple smaller messages (assuming that fits with the application requirements). ~~ Randy Levy [entlib.support@live.com](mailto:entlib.support@live.com) Enterprise Library support engineer [Support How-to](http://entlib.codeplex.com/wikipage?title=Support%20How-to)
I have created a discussion http://entlib.codeplex.com/discussions/574964.
To know what is causing issue while I logging string length more than 32723 in Out of Process.
Because I have created a class and the method for writing logs in to blob and it was working fine in “In-Process” type of logging with large length of allowable string data type.
But the same source code is converted as dll and placed in out-of-process semantic logging folder called via xml file through custom sink tag but unfortunately it was not logging large size string (>32723) and also it was not throwing (log) any error.
Initially it was throwing proxy error and I have fixed proxy error by put some code and now it is running fine.
Be simple, Out-of-Process is not logging payload string which is having length more than 32723.
I’m using Event level as Log always.
Also I’m using semantic logging custom sink unhandled fault method to write logs when exception happen in a method. Error logging is not happen.
SemanticLoggingEventSource.Log.CustomSinkUnhandledFault()
If I’m using above code , definitely this should get some error log when method is throwing error. Am I right?
Moreover , How to disable events and close the listener in custom sink out of process. Please guide me.
Share me the event life cycle of the Semantic Logging custom sink.
1. OnCompleted – Not implemented
2. OnError – Here I’m calling custom sink unhandled fault()
3. OnNext – Here I’m calling my own method for writing logs to blob
Kindly expedite and I Need your help.
Comments: What you are seeing is a limitation in the size of an ETW event. ETW is what is used to communicate between the event producing process (event provider) and the OOP service (event consumer). From [About Event Tracing](http://msdn.microsoft.com/en-us/library/windows/desktop/aa363668%28v=vs.85%29.aspx): # > Events can be lost for a number of reasons: The total event size is greater than 64K. This includes the ETW header plus the data or payload. A user has no control over these missing events since the event size is configured by the application. # You are hitting the 64K limit but the string length does not necessarily have to be 32723 -- it depends on the total size of the event (e.g. in my testing I hit a slightly different number). The reason why a single string of about ~32000 characters is hitting the 64K limit is that 2 bytes is allocated per character. What happens is that the in-process ETW buffer is too small to accept the incoming data so the status ERROR_MORE_DATA is returned and the message is never published. You can see that the message is not published by enabling exceptions on the EventSource (pass true to the EventSource base constructor) to see that an exception is being raised: ``` c# public sealed class MyMessagingEventSource : EventSource { public static MyMessagingEventSource Log = new MyMessagingEventSource(); private MyMessagingEventSource() : base(true) { } } ``` Finally, the occurrence of an error is delivered out of band to the the OOP service and will be written if the "Microsoft-SemanticLogging" EventSource is configured to log. The output would look something like the following: ``` ProviderId : d1ed7ec7-5701-5554-2c5e-796dc42511c5 EventId : 811 Keywords : 4 Level : LogAlways Message : Out of band event level 0 for provider 00000000-0000-0000-0000-000000000000 on session Microsoft-SemanticLogging-Etw-ConsoleEventSink. Message: Opcode : Info Task : 64723 Version : 0 Payload : [sessionName : Microsoft-SemanticLogging-Etw-ConsoleEventSink] [providerId : 00000000-0000-0000-0000-000000000000] [eventLevel : 0] [eventKeywords : 0 ] [eventMessage : ] EventName : TraceEventServiceOutOfBandEventInfo Timestamp : 2014-12-17T18:35:27.2873067Z ProcessId : 10884 ThreadId : 11240 ``` Unfortunately, there is not much useful information in that message. Also, since the limitation is baked into ETW there is not much that can be done short of splitting/truncating long strings or perhaps implementing a retry to try to split/truncate long strings and log multiple smaller messages (assuming that fits with the application requirements). ~~ Randy Levy [entlib.support@live.com](mailto:entlib.support@live.com) Enterprise Library support engineer [Support How-to](http://entlib.codeplex.com/wikipage?title=Support%20How-to)