camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] Commented: (CAMEL-2563) The Trace mechanism is inflexible and inefficient - specifically it doesn't enable custom tracing around a node.
Date Sat, 20 Mar 2010 08:43:46 GMT


Claus Ibsen commented on CAMEL-2563:


Good idea about the async behavior of the Tracer, even though you could do that by sending
to a seda endpoint, but then that means adding an additional route, which you may not _like_.

But again by having the existing Tracer a bit more easy to extend with strategy callbacks
allows you to do your own async persist to JPA as you like.
We could also add a option so Camel could let the existing send to destination occur async.

And the idea with a filter to skip tracing certain nodes is also a great idea. For starters
we could add a {{boolean shouldTrace(ProcessorDefinition node, Exchange exchange)}} method
which you can implement your own logic to indicate whether or not it should be traced.

Then later we can add a regexp kind pattern to the default Tracer to have that out of the

Its all a fair bit of work and hence we love contributions. But I have to stress that we must
have unit tests for this as the Tracer is actually more complex to get working correctly in
all the odd size combinations of routes there is out there. I know we got a few JIRA tickets
with issues currently.

> 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
>         Attachments: tracechanges.diff
>   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