[
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
Another version.
Extracts the traceExchange methods into a separate interface (TraceHandler) and
provides a default implementation (DefaultTraceHandler).
A single instance of the TraceHandler can be set on the Tracer and will be used
for all routes created from then on.
The DefaultTraceHandler takes the JpaTraceEventMessageClass as a String
argument, which allows custom JPA classes to be used easily.
The disadvantage of using the TraceHandler (as opposed to deriving from
TraceInterceptor and replacing that) is that you are working with a single
object across all nodes, routes and threads - if you want to have a instance
data per node you should derive from TraceInterceptor and use the
TraceInterceptorFactory.
The DefaultTraceHandler throws up an interesting issue:
It has to load the JpaTraceEventMessageClass dynamically, because it doesn't
know at compile time whether or not it should be used.
If that is done in a TraceHandler then it needs to synchronize on every call
(which could be an issue).
However now users could manually request a JpaTraceHandler, which could
statically load the JpaTraceEventMessageClass - it might even be possible to be
generic based on the class - but I couldn't make this the default because it
would be a breaking change.
Maybe the best approach is to make the default TraceInterceptor a subclass of
the DefaultTraceInterceptor that implements the existing behaviour and does not
use the TraceHandler at all.
Then if users want to use the TraceHandler mechanism they manually specify the
parent class TraceInterceptor (or the factory for it) which does use the
TraceHandler.
It sounds complex, but it's just a few lines in Spring.
Need more tests, and still considering the issue of filtering by node -
suggestions appreciated.
Any thoughts welcomed.
> 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, 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.
