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.
