[jira] Commented: (CAMEL-2563) The Trace mechanism is inflexible and inefficient - specifically it doesn't enable custom tracing around a node.

["Christian Mueller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/CAMEL-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58338#action_58338 ] 

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...

Regards,
Christian

> The Trace mechanism is inflexible and inefficient - specifically it doesn't enable custom tracing around a node.
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-2563
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-2563
>             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.