camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Talbut (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CAMEL-2563) The Trace mechanism is inflexible and inefficient - specifically it doesn't enable custom tracing around a node.
Date Wed, 24 Mar 2010 20:13:07 GMT

     [ https://issues.apache.org/activemq/browse/CAMEL-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jim Talbut updated CAMEL-2563:
------------------------------

    Attachment: tracechanges.diff

I'm attaching a rather better patch.

Changes:
* There is now a TraceInterceptorFactory interface with a default implementation DefaultTraceInterceptorFactory.
* The Tracer class has get/setTraceInterceptorFactory.
* Tracer has got separate functions for performing the actual exchange, with In and Out exchange
traces identified.
* There is a unit test (three :) ).

Todo:
* Not looked at configuring it from Spring yet.
* Not sure whether the segregate into separate functions for the exchange should be behind
an interface rather than just a subclass.

Thoughts on Christian's requirements:
1. Filtering by node is complicated by the fact that the node you receive as an interceptor
may be another interceptor.
    My unit test walks the tree of DelegateProcessors to find the real node, but that will
only work if the interceptors are DelegateProcessors, and there is nothing to ensure that
they are.
2. Using custom JPA code works, that's precisely what I want to do.
3. I'm not sure of the logic of doing tracing in a separate thread - it's a sacrifice of maximum
throughput for reduced latency.
    Whatever you pass to the separate thread will have to be a self contained copy, which
with attachments could be large (unless you can make the attachments imutable objects?).
   It's made easier with my changes, but I haven't done anything towards it as such.

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


Mime
View raw message