camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Talbut <>
Subject Re: Camel Tracer impedes performance.
Date Thu, 17 Feb 2011 10:26:01 GMT
On 17/02/2011 10:01, Naira & Kobo wrote:
> Hi,
> I noticed that extending the camel tracer to log exchange data into the
> database impedes performance on the ESB.
> I followed the example in the camel samples, where I defined a direct
> endpoint
> <bean id="camelTracer"
> class="org.apache.camel.processor.interceptor.Tracer">
> 	    	<property name="destination" ref="traceEndpoint"/>
> 	    	<property name="logLevel" value="OFF"/>
> 	</bean>	
> <osgi:camelContext xmlns=""
> trace="true">
>    	<endpoint id="traceEndpoint" uri="direct:traceRoute"/>
>          <route>
>                <from ....../>
>                 ...............
>                <to ............./>
>          </route>
> 	<route>
>      	<from uri="direct:traceRoute"/>
>        	<bean ref="tracer" method="Log"/>
>      </route>
>    </osgi:camelContext>
> What I did was to create a custom bean that logs this tracemessage to
> database. I assume the process of calling this route is off the main route
> (meaning I assume its like an interceptor and should not in any way slow
> down the time it takes to travel from one node to another). But it seems it
> does in reality. As whenever I turn of the custom trace, it takes
> considerable  less time to complete a transaction and when its on, it takes
> more time.
> A background to this problem that might be helpful is the fact that,
> exchange message body type is a bean (and not string or xml). I noticed each
> time its going from one node to another, it implicitly tries to convert from
> bean to String, before handling the message to the direct endpoint. (May be
> its just my imagination)
> It is also noteworthy that the main route uses vm and the preferred endpoint
> uri while the log interfaces uses the direct uri.
> Is there another way, I can efficiently do this?
> kr.
Of course tracing impedes performance, it's got more to do :)

However the default tracing is particularly inefficient (because it's 
safe and copies the Exchange) and there are more efficient options if 
you don't mind taking more responsibility for what happens.
Look at writing a custom TraceEventHandler 

which you can then set with Tracer::setTraceHandler and take complete 
control of how tracing works.

There may be other, simpler, ways to get enough performance from the 
default tracing, but a custom TraceEventHandler should be the fastest 
you can get.


View raw message