Hi there,

I'm currently using the EIF to trace messages in our remoting-enabled
application. I implemented the RequestTrace-class to log context
specific information (like ComPlusInfo).
Now, I want to be able to use the "IsEnabledForType" method in my
remote server application, but I don't know how to access the
RequestEventSource of the calling application (which is necessary to
execute the IsEnabledForType method).

I use the following line of code (in my client application) to
initiate the tracing:

using (RequestTrace request = new RequestTrace(MyRequestEventSource))
{
// Calls to remoting objects start here
}

This way, "MyRequestEventSource" is passed to the calling objects
through remoting and all the trace messages will be logged under the
given EventSource. The following line of code will log messages to the
sink specified in my EnterpriseInstrumentation.config - file.

TraceMessageEvent.Raise("Inside Method on Remote Server" );

This all works great, but the actions executed to write to the event
sink are very costly and should only be executed when tracing is
enabled. Here, the IsEnabledForType method should be very useful.

Some documentation pointed out that information concerning the request
is stored in the "LogicalCallContext", but I can't find how to access
this info.
The only event source I can use is the Application Level Event
Source(RequestEventSource.Application), but this is not the one I
need.
Who can help me with this one?

Hi there,

First some background...

When (on the client app) you go

using (RequestTrace request = new RequestTrace(MyRequestEventSource))
{
// Calls to remoting objects start here
}

The name of the request event source (i.e. MyRequestEventSource.Name) is
being put on the thread. It is this name (and some other information like
sequence count, request instance ID, etc) that is flowed across to the
remote objects.

When an event is raised within the remote object (in the remote process),
the event will be also be raised out through the event source of name
MyRequestEventSource.Name.

Note - The EI.config loaded in the remote process will determine where
events raised through MyRequestEventSource.Name are actually routed - it is
not the EI.config of the client process that initiated the request trace.


Now for your question....

The CallContext.GetData() method is what you'd call to access the
LogicalCallContext. Attached is a sample that is pulling out the request
details an flowing them across web service calls (in the http headers).

However, Im not sure I understand what you would pass into
IsEnabledForType and what you would expect it to return.
I suspect that you may want to leave the EI.config of the remote process
set to always log events and have some flag flow across from the client
process to indicate whether the event should actually be raised or not. Is
this correct?

I hope this helps

Mike

--------------------
| Hi there,
|
| I'm currently using the EIF to trace messages in our remoting-enabled
| application. I implemented the RequestTrace-class to log context
| specific information (like ComPlusInfo).
| Now, I want to be able to use the "IsEnabledForType" method in my
| remote server application, but I don't know how to access the
| RequestEventSource of the calling application (which is necessary to
| execute the IsEnabledForType method).
|
| I use the following line of code (in my client application) to
| initiate the tracing:
|
| using (RequestTrace request = new RequestTrace(MyRequestEventSource))
| {
| // Calls to remoting objects start here
| }
|
| This way, "MyRequestEventSource" is passed to the calling objects
| through remoting and all the trace messages will be logged under the
| given EventSource. The following line of code will log messages to the
| sink specified in my EnterpriseInstrumentation.config - file.
|
| TraceMessageEvent.Raise("Inside Method on Remote Server" );
|
| This all works great, but the actions executed to write to the event
| sink are very costly and should only be executed when tracing is
| enabled. Here, the IsEnabledForType method should be very useful.
|
| Some documentation pointed out that information concerning the request
| is stored in the "LogicalCallContext", but I can't find how to access
| this info.
| The only event source I can use is the Application Level Event
| Source(RequestEventSource.Application), but this is not the one I
| need.
| Who can help me with this one?
|
| Stig De Feyter
|

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at

Mike,

Thanks for the answer. As you mentioned that "an event
will ALSO be raised out through the event source of name
MyRequestEventSource.Name", I understood that it is
possible to have multiple RequestEvenSources on a single
thread.

So I'll have to look in another direction to solve the
issue of how to use the "IsEnabledForType()". Maybe I do
need to instantiate every possible RequestEventSource (in
my remote application) to check if the tracing is enabled
for the specified EventSource. I thought I could access
the "only current running" RequestEventSource (which is
specified in the client application) to call
the "IsEnabledForType()"-method.

Maybe I could pass a parameter from the client
application to check if an event should actually be
raised or not (as you said), but is it also possible to
loop through all the "activated" EventSources (in the
remote application) that are specified in the calling
application (this way we can control it in the server
EI.config)-file)?

Thanks.
Stig De Feyter

[quoted text, click to view]
specified at

--------------------
|
| Mike,
|
| Thanks for the answer. As you mentioned that "an event
| will ALSO be raised out through the event source of name
| MyRequestEventSource.Name", I understood that it is
| possible to have multiple RequestEvenSources on a single
| thread.

You can have nested RequestTraces (and thus effectively nested
RequestEventSources), but the event is only raised through the EventSource
it is passed to and the currently active ("top of the stack" (however you
want to put it)) - RequestEventSource. It is not passed to all the
associated RequestEventSources seen. This came out of the design that we
only flowed around the currently active request trace information. We were
worried about flowing around the full stack as it could grow large and add
a lot of overhead to each remote call.

Now on the client machine, a RequestTrace could be started with a
RequestEventSource (RES) of name "A". When the call comes across to the
server and the event is raised down an ES of name "ES", EIF will try to
raise it down a RES of name "A" on the server machine. It searches a
private static table of RES to see if it can find a RES instance of name
"A", if not it instantiates one and raises the event down it. The
instantiation will cause the server app's EI.config to be queried for the
configuration of RES "A" and the event will be routed according to this
configuration.

I should say that in subsequent calls from client to server, the client
might start request traces with an RequestEventSource (RES) of name "B",
"C", etc. Each time the server will look up its RES of the same name and
raise it out according to its configuration for the RES in the servers
EI.config.

|
| So I'll have to look in another direction to solve the
| issue of how to use the "IsEnabledForType()". Maybe I do
| need to instantiate every possible RequestEventSource (in
| my remote application) to check if the tracing is enabled
| for the specified EventSource. I thought I could access
| the "only current running" RequestEventSource (which is
| specified in the client application) to call
| the "IsEnabledForType()"-method.
|

Hopefully the above reply - provides more insight on this.


| Maybe I could pass a parameter from the client
| application to check if an event should actually be
| raised or not (as you said), but is it also possible to
| loop through all the "activated" EventSources (in the
| remote application) that are specified in the calling
| application (this way we can control it in the server
| EI.config)-file)?
|

Its still unclear to me what you want. (Im a bit dense I guess). Maybe if I
make up an example - you can describe how you want it to work.

Say we have a stock buy/sell application. The application is distributed
and consists of a client part (installed on many client machines) and a
server part (installed on one server machine). The client application takes
input from user and displays results. The client application communicates
with the server application to buy and sell stock. There are two calls it
makes
void Buy()
void Sell()

You instrument both applications so they raise error, tracing events out
through the standard singleton "EventSource.Application" EventSource.
You create two RequestEventSources of name "BuyRequest" & "SellRequest" in
the client application.

The client code for requesting a buy / sell looks something like this

private static RequestEventSource BuyRequestEventSource = new
RequestEventSource("BuyRequest");

public void RequestBuy()
{
using (RequestTrace buyRequest = new RequestTrace(BuyRequestEventSource))
{
server.Buy()
}
}

private static RequestEventSource SellRequestEventSource = new
RequestEventSource("SellRequest");

public void RequestSell()
{
using (RequestTrace sellRequest = new
RequestTrace(SellRequestEventSource))
{
server.Sell()
}
}

Both the client EI.config would have three ES entries of name
"Application", "BuyRequest" & "SellRequest".
In both,
"Application" would be configured output error events to the Windows
Event Log (logSink) and tracing events would not be routed anywhere.
"BuyRequest" & "SellRequest" would be configured to output the events
nowhere.

Now given all this, what would you like to be able to do? I assume that you
want to be able to turn on the tracing events for a short while.


| Thanks.
| Stig De Feyter
|
| >-----Original Message-----
| >Hi there,
| >
| >First some background...
| >
| >When (on the client app) you go
| >
| > using (RequestTrace request = new RequestTrace
| (MyRequestEventSource))
| > {
| > // Calls to remoting objects start here
| > }
| >
| >The name of the request event source (i.e.
| MyRequestEventSource.Name) is
| >being put on the thread. It is this name (and some other
| information like
| >sequence count, request instance ID, etc) that is flowed
| across to the
| >remote objects.
| >
| >When an event is raised within the remote object (in the
| remote process),
| >the event will be also be raised out through the event
| source of name
| >MyRequestEventSource.Name.
| >
| >Note - The EI.config loaded in the remote process will
| determine where
| >events raised through MyRequestEventSource.Name are
| actually routed - it is
| >not the EI.config of the client process that initiated
| the request trace.
| >
| >
| >Now for your question....
| >
| >The CallContext.GetData() method is what you'd call to
| access the
| >LogicalCallContext. Attached is a sample that is
| pulling out the request
| >details an flowing them across web service calls (in the
| http headers).
| >
| >However, Im not sure I understand what you would pass
| into
| >IsEnabledForType and what you would expect it to return.
| >I suspect that you may want to leave the EI.config of
| the remote process
| >set to always log events and have some flag flow across
| from the client
| >process to indicate whether the event should actually be
| raised or not. Is
| >this correct?
| >
| >I hope this helps
| >
| >Mike
| >
| >--------------------
| >| Hi there,
| >|
| >| I'm currently using the EIF to trace messages in our
| remoting-enabled
| >| application. I implemented the RequestTrace-class to
| log context
| >| specific information (like ComPlusInfo).
| >| Now, I want to be able to use the "IsEnabledForType"
| method in my
| >| remote server application, but I don't know how to
| access the
| >| RequestEventSource of the calling application (which
| is necessary to
| >| execute the IsEnabledForType method).
| >|
| >| I use the following line of code (in my client
| application) to
| >| initiate the tracing:
| >|