camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Mueller (JIRA)" <>
Subject [jira] Commented: (CAMEL-2563) The Trace mechanism is inflexible and inefficient - specifically it doesn't enable custom tracing around a node.
Date Fri, 19 Mar 2010 18:23:54 GMT


Christian Mueller commented on CAMEL-2563:

Jim, currently we are also planed to implement our own TraceInterceptor which fits all our
needs. We have two requirements which the current implementation doesn't fit:
- (1) We want to limit the traced services. We do not want to see the calls to splitter(),
jaxb(), .... May be we could include and/or exclude services by its name per regExp configuration.
- (2) We want provide our own JPAEntity which also logs the headers and attachments in its
own tables.
- (3) Because of (2), the TraceInterceptor needs more time to persist the data and should
be executed in its own thread. -> The TraceInterceptor should not slow down the performance
of our services.

Could you also have an eye on that?
... and if you need help, please let me know...


> The Trace mechanism is inflexible and inefficient - specifically it doesn't enable custom
tracing around a node.
> ----------------------------------------------------------------------------------------------------------------
>                 Key: CAMEL-2563
>                 URL:
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.3.0
>         Environment: All.
>            Reporter: Jim Talbut
>            Priority: Minor
>             Fix For: Future
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
> What it won't let me do:
> I want to be able to correlate the "out" trace with the "in" trace, in one database row
without commiting the row until the route has completed.
> This requires a JPA transaction to exist around each of the nodes that are called.
> I'm finding that the transaction has ended by the time of the "out" trace.
> Inefficiencies:
> 1. It causes the construction of the new Exchange object and a bunch of String objects
that I don't want.
> 2. It causes the invocation of a new route, that is unnecessary.
> I think it would be better to:
> 1. Pass the class to use as the TraceInterceptor into Tracer.
> 2. Break the existing TraceInterceptor into two, a base class that tracks the RouteNodes
and a subclass that implements traceExchange.
> 3. Change traceExchange so that it returns an Object and pass that Object in to the call
to traceExchange for "out" traces.
> 4. Give the Tracer a payload object that can be used to pass information to the TraceInterceptor.
> 5. Change the various trace* functions to take in and return a payload Object.
> Custom users could then dervice from TraceInterceptor and override the trace* functions
as necessary (probably just traceExchange).
> I'm working on a patch.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message