camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Naira & Kobo <lekkie.ay...@gmail.com>
Subject Re: Camel Tracer impedes performance.
Date Thu, 17 Feb 2011 11:58:54 GMT


I am curious, is it the TraceEventHandler that impedes the performance or
the TraceInceptor  or the InterceptStrategy?

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.
-- 
View this message in context: http://camel.465427.n5.nabble.com/Camel-Tracer-impedes-performance-tp3389173p3389307.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Mime
View raw message