On 17/02/2011 11:58, Naira & Kobo wrote:
I am curious, is it the TraceEventHandler that impedes the performance or
the TraceInceptor or the InterceptStrategy?
Well it's definitely not the TraceEventHandler, because unless you
provide one, there isn't one.
Beyond saying that if you want a definitive answer you should profile it
(I can guarantee that tracing has an impact, but whether it's even
measurable or not will depend on a great many factors).
Also everything else that follows is shaky and may be completely wrong
(I hope someone will point it out if it is).
The InterceptStrategy for tracing is called Tracer
(org.apache.camel.processor.interceptor.Tracer).
The strategy doesn't really do very much, it just sits there as
configuration device - it holds the parameters that you can set for
tracing and it creates trace interceptors for any routes that it is told
about.
So if you were to profile it you wouldn't spend much time in Tracer.
A TraceInterceptor is set up for every node in the route and any
performance impact from tracing must come within it's "process" method.
The process method does nothing for some nodes, and the rest of it is
concerned with either setting up some tracking data or calling the right
tracing methods.
Most of the tracing methods call both logExchange and traceExchange,
either of which could be expensive (but one would hope that logging is
cheap, so I'm going to ignore it).
So the guts of it all is the traceExchange function, called in the
TraceInterceptor of ever 'important' node (typically being those you set
up) in your route.
The traceExchange function copies the exchange and then feeds it to the
trace route (which, by default, is in the same thread, I think).
So the expensive bit is likely to be in that route processing, and if
you want to reduce the impact I think you need to reduce the latency of
that route.
Jim
If the differences in the usage of these classes are clear to you, can you
please explain to me how they differ?
I assume, when there is a new exchange on a node, the TraceInterceptor
intercepts the message using a strategy defined by the InterceptStrategy
(This I assume should actually create a new thread and get a copy of the
exchange. At this point I assume the main Exchange, should not try to
transform exchange message to suite the interceptor). I also assume it is
after the Trace Interceptor accepts the message, then the TraceEventHandler
'd attempt to "handle" or process the trace event.
At this time, the main exchange should not be impeded (meaning, messages
should be forwarded to subsequent nodes/endpoints without it being blocked
by the the trace processing).
Again, these are my assumptions. Kindly help clarify what are, and what are
not. Basically, all I want to do is, allow original message to continue
being processed then use a separate thread handle traces. This way, my
original transaction will not be blocked by the tracer and it can still be
completed as if the tracer were not turned on. How long its takes traces to
be log is not a big deal as it is a trace, so it can take for as long it
wants to - reasonably though.
