camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject AW: Camel Tracer impedes performance.
Date Thu, 17 Feb 2011 12:08:59 GMT
Perhaps you should use a seda queue 

<endpoint id="traceEndpoint" uri="seda:traceRoute? waitForTaskToComplete=Never "/>

    	<from uri="seda:traceRoute"/>
      	<bean ref="tracer" method="Log"/>

The direct endpoint you used is always synchronous so this may cause the performance hit.
You may also want to use a jms topic for tracing. This way you can even combine the traces
of several servers. 
You can then attach one listener that writes to the db but also easily plug in e.g. a live
monitoring console.


-----Urspr√ľngliche Nachricht-----
Von: Naira & Kobo [] 
Gesendet: Donnerstag, 17. Februar 2011 12:59
Betreff: Re: Camel Tracer impedes performance.

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
View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message