You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by ext2 <xu...@tongtech.com> on 2010/12/02 03:53:03 UTC
Wast performance? Instrument Interceptor is wrapped twice for each processor.
Hi:
Each camel processor will be wrapped with Instrument Interceptor
twice. So for each process , the Instrument interceptor will be executed
twice.
It seems no use but waste performance;
Why? Or a bug?
Thanks for any suggestion.
Re: Wast performance? Instrument Interceptor is wrapped twice for
each processor.
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Dec 4, 2010 at 2:04 AM, ext2 <xu...@tongtech.com> wrote:
> Hi, Claus:
>
> It's a exciting feature. Hoping it will be available sooner;
>
> By the way, it seems the camel 3.0 decide to introduce some new features;
> While I am using camel, I often meet some requirement which I think if camel support it, things will be better;
>
> I always feel embarrassed to raise these question in camel community. Because these questions is somewhat coupling with OSGI environment, and they seems go too faraway from camel.
Dont be. We are all still learning the OSGi beast and how its best
used in the enterprise integration space. And with Camel we integrate
with OSGi out of the box, so we want it to work well together. Despite
that OSGi isn't on everybody's love list.
>
> But if the camel is gathering requirement, so I am wonder if I could post these questions freely in Camel Community? Following is some examples:
>
Yeah of course. I suggest that you post a new thread on each question
/ idea you have. Then its easier to keep discussion focused on that
particular idea.
> 1) Dynamic Configurable Component based on OSGI Configuration Admin:
> By change the OSGI Configuration at runtime, we could change the behavior of Camel Component(Even Endpoint)。
>
> 2) Dynamic Expression Service Processor: A Transformer, which could using a expression which is compiled from file's content; and even detecting the file's changing at runtime. When file changed, the language will be reload and recompiled; (just like JSP).
>
> 3)OSGI Component: which can directly expose camel route as a OSGI service. If so, we can using OSGI Framework as Service Infrastructure, and using camel as message mediator; and we could leave the JBI (a more heavily Service Infrastructure than OSGI) aside;
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
Posted by ext2 <xu...@tongtech.com>.
Hi, Claus:
It's a exciting feature. Hoping it will be available sooner;
By the way, it seems the camel 3.0 decide to introduce some new features;
While I am using camel, I often meet some requirement which I think if camel support it, things will be better;
I always feel embarrassed to raise these question in camel community. Because these questions is somewhat coupling with OSGI environment, and they seems go too faraway from camel.
But if the camel is gathering requirement, so I am wonder if I could post these questions freely in Camel Community? Following is some examples:
1) Dynamic Configurable Component based on OSGI Configuration Admin:
By change the OSGI Configuration at runtime, we could change the behavior of Camel Component(Even Endpoint)。
2) Dynamic Expression Service Processor: A Transformer, which could using a expression which is compiled from file's content; and even detecting the file's changing at runtime. When file changed, the language will be reload and recompiled; (just like JSP).
3)OSGI Component: which can directly expose camel route as a OSGI service. If so, we can using OSGI Framework as Service Infrastructure, and using camel as message mediator; and we could leave the JBI (a more heavily Service Infrastructure than OSGI) aside;
-----Original-----
Sender: Claus Ibsen [mailto:claus.ibsen@gmail.com]
Time: 2010/12/3 23:22
Receiver: users@camel.apache.org
Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
On Fri, Dec 3, 2010 at 4:17 PM, ext2 <xu...@tongtech.com> wrote:
> Thanks a lot.
> It's really a good news to support dynamic support at runtime;
>
> Actually, many management requirement need a runtime-dynamic-deciding features beside Instrument;
>
> For example: trace will be another example fro dynamic support: temporary to open the trace to check problem, and then close it to avoid performance waste;
>
> So I am wondering if camel 3.0 decide to support some common dynamic configuration mechanism or just support Instrument specially?
>
The idea is that its becomes very dynamic. For example you can deploy
a OSGi bundle which then adds interceptor the existing Camel routes
which already run.
Then when you are done you can just undeploy that interceptor etc.
It doesnt have to be only interceptor. For example you can add an
audit module, or a "message capture" module, which you can use with
some tooling to eg. reply messages and whatnot.
It just opens up for many new ideas you may want to do.
> Best regard
>
> ----Origin-----
> Sender: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Date: 2010/12/3日 21:34
> Receiver: users@camel.apache.org
> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
>
> On Fri, Dec 3, 2010 at 2:24 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> I did look at few examples. In your case, from looking at the log, it looks like it's wrapped twice, that's why is executed twice. The second number is always larger than the first. Since the Trace is an interceptor too, it looks like you got an instrument(trace(instrument(processor))). I will take a look today and see where the problem lies. In any event, your assumption is correct, instrumentation should not happen twice, and if does it is a bug.
>>
>> Thanks for pointing this out,
>> Hadrian
>
> We'll revisit this in Camel 3.0 where the idea is to make the
> interception/wrapper dynamic and decided at runtime, instead of laid
> out at route initialization time.
> The logic deciding to do this would then be easier to implement.
>
>
>>
>>
>> On Dec 3, 2010, at 7:15 AM, ext2 wrote:
>>
>>> Sorry, I forget to attach my tracing result;
>>>
>>> I am sure , it's wrapped twice;
>>> Because the Instrument Processor will trace the time only after
>>> processing. But one processor 's instrument result is traced twice;
>>>
>>> Following is my tracing output, you can check it.
>>>
>>> - bean: Recording duration: 23 millis for exchange: Exchange[Message: plain
>>> text]
>>> - bean: Recording duration: 52 millis for exchange: Exchange[Message: plain
>>> text]
>>> - to: Recording duration: 11 millis for exchange: Exchange[Message: plain
>>> text]
>>> - to: Recording duration: 18 millis for exchange: Exchange[Message: plain
>>> text]
>>> - bean: Recording duration: 11 millis for exchange: Exchange[Message: plain
>>> text]
>>> - bean: Recording duration: 48 millis for exchange: Exchange[Message: plain
>>> text]
>>> - route: Recording duration: 160 millis for exchange: Exchange[Message:
>>> plain text]
>>>
>>> -----Original -----
>>> Sender: ext2 [mailto:xuhb@tongtech.com]
>>> Date: 2010-12-3 19:23
>>> Receiver: users@camel.apache.org
>>> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
>>> each processor.
>>>
>>> Thanks Harian Zbarcea:
>>> Instrument will be useful. But being wrapped and execute twice for
>>> single processor will be a waste;
>>> Actually, I found this problem while debug and tracing a spring
>>> configured camel route. At least in Camel 2.4.0 and using spring, it real
>>> does wrap twice.
>>> Maybe you could take a moment to debug and tracking a camel route ,
>>> you will see it.
>>> Or,you can turning on the "TRACE" level for logging, and checking
>>> the Instrument Processor's output. You could see it;
>>> Following is my route:
>>> <route>
>>> <from uri="direct:from" />
>>> <bean id="id0" ref="bean1" method="normal" />
>>> <to id="id0_1" uri="mock:result" />
>>> <bean id="id1" ref="bean1" method="raiseError" />
>>> </route>
>>> But the trace result is : 2 of first bean, 2 of the "to" endpoint,
>>> 2 of the second bean and 1 for route;
>>>
>>> -----Origin -----
>>> Sender: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
>>> Date: 2010/12/2 22:21
>>> Receiver: users@camel.apache.org
>>> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
>>> each processor.
>>>
>>> The InstrumentationProcessor is a delegate processor (aka interceptor) that
>>> allows you do do before and after processing.
>>> It is not really invoked twice (or I have to see a test case that does that,
>>> the unit tests in camel I am aware of don't). It is invoked once, takes a
>>> start timestamp, it delegates processing to the inner processor and then
>>> takes the time diff and records it.
>>>
>>> Now with a DelegateProcessor all this call is synchronous. Being actually a
>>> DelegateAsyncProcessor, the call to the inner processor is done by the async
>>> engine (see AsyncProcessorHelper.process()) which calls asynchronously on
>>> the done() method. I assume this is what you see and interpret as a second
>>> call.
>>>
>>> This design is not wasting performance, quite to the contrary. It ensures a
>>> better use of resources and scales much better with higher message volume.
>>>
>>> I hope this helps,
>>> Hadrian
>>>
>>>
>>> On Dec 1, 2010, at 9:53 PM, ext2 wrote:
>>>
>>>> Hi:
>>>> Each camel processor will be wrapped with Instrument Interceptor
>>>> twice. So for each process , the Instrument interceptor will be executed
>>>> twice.
>>>> It seems no use but waste performance;
>>>> Why? Or a bug?
>>>> Thanks for any suggestion.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Wast performance? Instrument Interceptor is wrapped twice for
each processor.
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Dec 3, 2010 at 4:17 PM, ext2 <xu...@tongtech.com> wrote:
> Thanks a lot.
> It's really a good news to support dynamic support at runtime;
>
> Actually, many management requirement need a runtime-dynamic-deciding features beside Instrument;
>
> For example: trace will be another example fro dynamic support: temporary to open the trace to check problem, and then close it to avoid performance waste;
>
> So I am wondering if camel 3.0 decide to support some common dynamic configuration mechanism or just support Instrument specially?
>
The idea is that its becomes very dynamic. For example you can deploy
a OSGi bundle which then adds interceptor the existing Camel routes
which already run.
Then when you are done you can just undeploy that interceptor etc.
It doesnt have to be only interceptor. For example you can add an
audit module, or a "message capture" module, which you can use with
some tooling to eg. reply messages and whatnot.
It just opens up for many new ideas you may want to do.
> Best regard
>
> ----Origin-----
> Sender: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Date: 2010/12/3日 21:34
> Receiver: users@camel.apache.org
> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
>
> On Fri, Dec 3, 2010 at 2:24 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> I did look at few examples. In your case, from looking at the log, it looks like it's wrapped twice, that's why is executed twice. The second number is always larger than the first. Since the Trace is an interceptor too, it looks like you got an instrument(trace(instrument(processor))). I will take a look today and see where the problem lies. In any event, your assumption is correct, instrumentation should not happen twice, and if does it is a bug.
>>
>> Thanks for pointing this out,
>> Hadrian
>
> We'll revisit this in Camel 3.0 where the idea is to make the
> interception/wrapper dynamic and decided at runtime, instead of laid
> out at route initialization time.
> The logic deciding to do this would then be easier to implement.
>
>
>>
>>
>> On Dec 3, 2010, at 7:15 AM, ext2 wrote:
>>
>>> Sorry, I forget to attach my tracing result;
>>>
>>> I am sure , it's wrapped twice;
>>> Because the Instrument Processor will trace the time only after
>>> processing. But one processor 's instrument result is traced twice;
>>>
>>> Following is my tracing output, you can check it.
>>>
>>> - bean: Recording duration: 23 millis for exchange: Exchange[Message: plain
>>> text]
>>> - bean: Recording duration: 52 millis for exchange: Exchange[Message: plain
>>> text]
>>> - to: Recording duration: 11 millis for exchange: Exchange[Message: plain
>>> text]
>>> - to: Recording duration: 18 millis for exchange: Exchange[Message: plain
>>> text]
>>> - bean: Recording duration: 11 millis for exchange: Exchange[Message: plain
>>> text]
>>> - bean: Recording duration: 48 millis for exchange: Exchange[Message: plain
>>> text]
>>> - route: Recording duration: 160 millis for exchange: Exchange[Message:
>>> plain text]
>>>
>>> -----Original -----
>>> Sender: ext2 [mailto:xuhb@tongtech.com]
>>> Date: 2010-12-3 19:23
>>> Receiver: users@camel.apache.org
>>> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
>>> each processor.
>>>
>>> Thanks Harian Zbarcea:
>>> Instrument will be useful. But being wrapped and execute twice for
>>> single processor will be a waste;
>>> Actually, I found this problem while debug and tracing a spring
>>> configured camel route. At least in Camel 2.4.0 and using spring, it real
>>> does wrap twice.
>>> Maybe you could take a moment to debug and tracking a camel route ,
>>> you will see it.
>>> Or,you can turning on the "TRACE" level for logging, and checking
>>> the Instrument Processor's output. You could see it;
>>> Following is my route:
>>> <route>
>>> <from uri="direct:from" />
>>> <bean id="id0" ref="bean1" method="normal" />
>>> <to id="id0_1" uri="mock:result" />
>>> <bean id="id1" ref="bean1" method="raiseError" />
>>> </route>
>>> But the trace result is : 2 of first bean, 2 of the "to" endpoint,
>>> 2 of the second bean and 1 for route;
>>>
>>> -----Origin -----
>>> Sender: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
>>> Date: 2010/12/2 22:21
>>> Receiver: users@camel.apache.org
>>> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
>>> each processor.
>>>
>>> The InstrumentationProcessor is a delegate processor (aka interceptor) that
>>> allows you do do before and after processing.
>>> It is not really invoked twice (or I have to see a test case that does that,
>>> the unit tests in camel I am aware of don't). It is invoked once, takes a
>>> start timestamp, it delegates processing to the inner processor and then
>>> takes the time diff and records it.
>>>
>>> Now with a DelegateProcessor all this call is synchronous. Being actually a
>>> DelegateAsyncProcessor, the call to the inner processor is done by the async
>>> engine (see AsyncProcessorHelper.process()) which calls asynchronously on
>>> the done() method. I assume this is what you see and interpret as a second
>>> call.
>>>
>>> This design is not wasting performance, quite to the contrary. It ensures a
>>> better use of resources and scales much better with higher message volume.
>>>
>>> I hope this helps,
>>> Hadrian
>>>
>>>
>>> On Dec 1, 2010, at 9:53 PM, ext2 wrote:
>>>
>>>> Hi:
>>>> Each camel processor will be wrapped with Instrument Interceptor
>>>> twice. So for each process , the Instrument interceptor will be executed
>>>> twice.
>>>> It seems no use but waste performance;
>>>> Why? Or a bug?
>>>> Thanks for any suggestion.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
Posted by ext2 <xu...@tongtech.com>.
Thanks a lot.
It's really a good news to support dynamic support at runtime;
Actually, many management requirement need a runtime-dynamic-deciding features beside Instrument;
For example: trace will be another example fro dynamic support: temporary to open the trace to check problem, and then close it to avoid performance waste;
So I am wondering if camel 3.0 decide to support some common dynamic configuration mechanism or just support Instrument specially?
Best regard
----Origin-----
Sender: Claus Ibsen [mailto:claus.ibsen@gmail.com]
Date: 2010/12/3日 21:34
Receiver: users@camel.apache.org
Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
On Fri, Dec 3, 2010 at 2:24 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> I did look at few examples. In your case, from looking at the log, it looks like it's wrapped twice, that's why is executed twice. The second number is always larger than the first. Since the Trace is an interceptor too, it looks like you got an instrument(trace(instrument(processor))). I will take a look today and see where the problem lies. In any event, your assumption is correct, instrumentation should not happen twice, and if does it is a bug.
>
> Thanks for pointing this out,
> Hadrian
We'll revisit this in Camel 3.0 where the idea is to make the
interception/wrapper dynamic and decided at runtime, instead of laid
out at route initialization time.
The logic deciding to do this would then be easier to implement.
>
>
> On Dec 3, 2010, at 7:15 AM, ext2 wrote:
>
>> Sorry, I forget to attach my tracing result;
>>
>> I am sure , it's wrapped twice;
>> Because the Instrument Processor will trace the time only after
>> processing. But one processor 's instrument result is traced twice;
>>
>> Following is my tracing output, you can check it.
>>
>> - bean: Recording duration: 23 millis for exchange: Exchange[Message: plain
>> text]
>> - bean: Recording duration: 52 millis for exchange: Exchange[Message: plain
>> text]
>> - to: Recording duration: 11 millis for exchange: Exchange[Message: plain
>> text]
>> - to: Recording duration: 18 millis for exchange: Exchange[Message: plain
>> text]
>> - bean: Recording duration: 11 millis for exchange: Exchange[Message: plain
>> text]
>> - bean: Recording duration: 48 millis for exchange: Exchange[Message: plain
>> text]
>> - route: Recording duration: 160 millis for exchange: Exchange[Message:
>> plain text]
>>
>> -----Original -----
>> Sender: ext2 [mailto:xuhb@tongtech.com]
>> Date: 2010-12-3 19:23
>> Receiver: users@camel.apache.org
>> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
>> each processor.
>>
>> Thanks Harian Zbarcea:
>> Instrument will be useful. But being wrapped and execute twice for
>> single processor will be a waste;
>> Actually, I found this problem while debug and tracing a spring
>> configured camel route. At least in Camel 2.4.0 and using spring, it real
>> does wrap twice.
>> Maybe you could take a moment to debug and tracking a camel route ,
>> you will see it.
>> Or,you can turning on the "TRACE" level for logging, and checking
>> the Instrument Processor's output. You could see it;
>> Following is my route:
>> <route>
>> <from uri="direct:from" />
>> <bean id="id0" ref="bean1" method="normal" />
>> <to id="id0_1" uri="mock:result" />
>> <bean id="id1" ref="bean1" method="raiseError" />
>> </route>
>> But the trace result is : 2 of first bean, 2 of the "to" endpoint,
>> 2 of the second bean and 1 for route;
>>
>> -----Origin -----
>> Sender: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
>> Date: 2010/12/2 22:21
>> Receiver: users@camel.apache.org
>> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
>> each processor.
>>
>> The InstrumentationProcessor is a delegate processor (aka interceptor) that
>> allows you do do before and after processing.
>> It is not really invoked twice (or I have to see a test case that does that,
>> the unit tests in camel I am aware of don't). It is invoked once, takes a
>> start timestamp, it delegates processing to the inner processor and then
>> takes the time diff and records it.
>>
>> Now with a DelegateProcessor all this call is synchronous. Being actually a
>> DelegateAsyncProcessor, the call to the inner processor is done by the async
>> engine (see AsyncProcessorHelper.process()) which calls asynchronously on
>> the done() method. I assume this is what you see and interpret as a second
>> call.
>>
>> This design is not wasting performance, quite to the contrary. It ensures a
>> better use of resources and scales much better with higher message volume.
>>
>> I hope this helps,
>> Hadrian
>>
>>
>> On Dec 1, 2010, at 9:53 PM, ext2 wrote:
>>
>>> Hi:
>>> Each camel processor will be wrapped with Instrument Interceptor
>>> twice. So for each process , the Instrument interceptor will be executed
>>> twice.
>>> It seems no use but waste performance;
>>> Why? Or a bug?
>>> Thanks for any suggestion.
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Wast performance? Instrument Interceptor is wrapped twice for
each processor.
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Dec 3, 2010 at 2:24 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> I did look at few examples. In your case, from looking at the log, it looks like it's wrapped twice, that's why is executed twice. The second number is always larger than the first. Since the Trace is an interceptor too, it looks like you got an instrument(trace(instrument(processor))). I will take a look today and see where the problem lies. In any event, your assumption is correct, instrumentation should not happen twice, and if does it is a bug.
>
> Thanks for pointing this out,
> Hadrian
We'll revisit this in Camel 3.0 where the idea is to make the
interception/wrapper dynamic and decided at runtime, instead of laid
out at route initialization time.
The logic deciding to do this would then be easier to implement.
>
>
> On Dec 3, 2010, at 7:15 AM, ext2 wrote:
>
>> Sorry, I forget to attach my tracing result;
>>
>> I am sure , it's wrapped twice;
>> Because the Instrument Processor will trace the time only after
>> processing. But one processor 's instrument result is traced twice;
>>
>> Following is my tracing output, you can check it.
>>
>> - bean: Recording duration: 23 millis for exchange: Exchange[Message: plain
>> text]
>> - bean: Recording duration: 52 millis for exchange: Exchange[Message: plain
>> text]
>> - to: Recording duration: 11 millis for exchange: Exchange[Message: plain
>> text]
>> - to: Recording duration: 18 millis for exchange: Exchange[Message: plain
>> text]
>> - bean: Recording duration: 11 millis for exchange: Exchange[Message: plain
>> text]
>> - bean: Recording duration: 48 millis for exchange: Exchange[Message: plain
>> text]
>> - route: Recording duration: 160 millis for exchange: Exchange[Message:
>> plain text]
>>
>> -----Original -----
>> Sender: ext2 [mailto:xuhb@tongtech.com]
>> Date: 2010-12-3 19:23
>> Receiver: users@camel.apache.org
>> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
>> each processor.
>>
>> Thanks Harian Zbarcea:
>> Instrument will be useful. But being wrapped and execute twice for
>> single processor will be a waste;
>> Actually, I found this problem while debug and tracing a spring
>> configured camel route. At least in Camel 2.4.0 and using spring, it real
>> does wrap twice.
>> Maybe you could take a moment to debug and tracking a camel route ,
>> you will see it.
>> Or,you can turning on the "TRACE" level for logging, and checking
>> the Instrument Processor's output. You could see it;
>> Following is my route:
>> <route>
>> <from uri="direct:from" />
>> <bean id="id0" ref="bean1" method="normal" />
>> <to id="id0_1" uri="mock:result" />
>> <bean id="id1" ref="bean1" method="raiseError" />
>> </route>
>> But the trace result is : 2 of first bean, 2 of the "to" endpoint,
>> 2 of the second bean and 1 for route;
>>
>> -----Origin -----
>> Sender: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
>> Date: 2010/12/2 22:21
>> Receiver: users@camel.apache.org
>> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
>> each processor.
>>
>> The InstrumentationProcessor is a delegate processor (aka interceptor) that
>> allows you do do before and after processing.
>> It is not really invoked twice (or I have to see a test case that does that,
>> the unit tests in camel I am aware of don't). It is invoked once, takes a
>> start timestamp, it delegates processing to the inner processor and then
>> takes the time diff and records it.
>>
>> Now with a DelegateProcessor all this call is synchronous. Being actually a
>> DelegateAsyncProcessor, the call to the inner processor is done by the async
>> engine (see AsyncProcessorHelper.process()) which calls asynchronously on
>> the done() method. I assume this is what you see and interpret as a second
>> call.
>>
>> This design is not wasting performance, quite to the contrary. It ensures a
>> better use of resources and scales much better with higher message volume.
>>
>> I hope this helps,
>> Hadrian
>>
>>
>> On Dec 1, 2010, at 9:53 PM, ext2 wrote:
>>
>>> Hi:
>>> Each camel processor will be wrapped with Instrument Interceptor
>>> twice. So for each process , the Instrument interceptor will be executed
>>> twice.
>>> It seems no use but waste performance;
>>> Why? Or a bug?
>>> Thanks for any suggestion.
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I did look at few examples. In your case, from looking at the log, it looks like it's wrapped twice, that's why is executed twice. The second number is always larger than the first. Since the Trace is an interceptor too, it looks like you got an instrument(trace(instrument(processor))). I will take a look today and see where the problem lies. In any event, your assumption is correct, instrumentation should not happen twice, and if does it is a bug.
Thanks for pointing this out,
Hadrian
On Dec 3, 2010, at 7:15 AM, ext2 wrote:
> Sorry, I forget to attach my tracing result;
>
> I am sure , it's wrapped twice;
> Because the Instrument Processor will trace the time only after
> processing. But one processor 's instrument result is traced twice;
>
> Following is my tracing output, you can check it.
>
> - bean: Recording duration: 23 millis for exchange: Exchange[Message: plain
> text]
> - bean: Recording duration: 52 millis for exchange: Exchange[Message: plain
> text]
> - to: Recording duration: 11 millis for exchange: Exchange[Message: plain
> text]
> - to: Recording duration: 18 millis for exchange: Exchange[Message: plain
> text]
> - bean: Recording duration: 11 millis for exchange: Exchange[Message: plain
> text]
> - bean: Recording duration: 48 millis for exchange: Exchange[Message: plain
> text]
> - route: Recording duration: 160 millis for exchange: Exchange[Message:
> plain text]
>
> -----Original -----
> Sender: ext2 [mailto:xuhb@tongtech.com]
> Date: 2010-12-3 19:23
> Receiver: users@camel.apache.org
> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
> each processor.
>
> Thanks Harian Zbarcea:
> Instrument will be useful. But being wrapped and execute twice for
> single processor will be a waste;
> Actually, I found this problem while debug and tracing a spring
> configured camel route. At least in Camel 2.4.0 and using spring, it real
> does wrap twice.
> Maybe you could take a moment to debug and tracking a camel route ,
> you will see it.
> Or,you can turning on the "TRACE" level for logging, and checking
> the Instrument Processor's output. You could see it;
> Following is my route:
> <route>
> <from uri="direct:from" />
> <bean id="id0" ref="bean1" method="normal" />
> <to id="id0_1" uri="mock:result" />
> <bean id="id1" ref="bean1" method="raiseError" />
> </route>
> But the trace result is : 2 of first bean, 2 of the "to" endpoint,
> 2 of the second bean and 1 for route;
>
> -----Origin -----
> Sender: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
> Date: 2010/12/2 22:21
> Receiver: users@camel.apache.org
> Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
> each processor.
>
> The InstrumentationProcessor is a delegate processor (aka interceptor) that
> allows you do do before and after processing.
> It is not really invoked twice (or I have to see a test case that does that,
> the unit tests in camel I am aware of don't). It is invoked once, takes a
> start timestamp, it delegates processing to the inner processor and then
> takes the time diff and records it.
>
> Now with a DelegateProcessor all this call is synchronous. Being actually a
> DelegateAsyncProcessor, the call to the inner processor is done by the async
> engine (see AsyncProcessorHelper.process()) which calls asynchronously on
> the done() method. I assume this is what you see and interpret as a second
> call.
>
> This design is not wasting performance, quite to the contrary. It ensures a
> better use of resources and scales much better with higher message volume.
>
> I hope this helps,
> Hadrian
>
>
> On Dec 1, 2010, at 9:53 PM, ext2 wrote:
>
>> Hi:
>> Each camel processor will be wrapped with Instrument Interceptor
>> twice. So for each process , the Instrument interceptor will be executed
>> twice.
>> It seems no use but waste performance;
>> Why? Or a bug?
>> Thanks for any suggestion.
>>
>>
>>
>
>
>
>
>
Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
Posted by ext2 <xu...@tongtech.com>.
Sorry, I forget to attach my tracing result;
I am sure , it's wrapped twice;
Because the Instrument Processor will trace the time only after
processing. But one processor 's instrument result is traced twice;
Following is my tracing output, you can check it.
- bean: Recording duration: 23 millis for exchange: Exchange[Message: plain
text]
- bean: Recording duration: 52 millis for exchange: Exchange[Message: plain
text]
- to: Recording duration: 11 millis for exchange: Exchange[Message: plain
text]
- to: Recording duration: 18 millis for exchange: Exchange[Message: plain
text]
- bean: Recording duration: 11 millis for exchange: Exchange[Message: plain
text]
- bean: Recording duration: 48 millis for exchange: Exchange[Message: plain
text]
- route: Recording duration: 160 millis for exchange: Exchange[Message:
plain text]
-----Original -----
Sender: ext2 [mailto:xuhb@tongtech.com]
Date: 2010-12-3 19:23
Receiver: users@camel.apache.org
Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
each processor.
Thanks Harian Zbarcea:
Instrument will be useful. But being wrapped and execute twice for
single processor will be a waste;
Actually, I found this problem while debug and tracing a spring
configured camel route. At least in Camel 2.4.0 and using spring, it real
does wrap twice.
Maybe you could take a moment to debug and tracking a camel route ,
you will see it.
Or,you can turning on the "TRACE" level for logging, and checking
the Instrument Processor's output. You could see it;
Following is my route:
<route>
<from uri="direct:from" />
<bean id="id0" ref="bean1" method="normal" />
<to id="id0_1" uri="mock:result" />
<bean id="id1" ref="bean1" method="raiseError" />
</route>
But the trace result is : 2 of first bean, 2 of the "to" endpoint,
2 of the second bean and 1 for route;
-----Origin -----
Sender: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
Date: 2010/12/2 22:21
Receiver: users@camel.apache.org
Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
each processor.
The InstrumentationProcessor is a delegate processor (aka interceptor) that
allows you do do before and after processing.
It is not really invoked twice (or I have to see a test case that does that,
the unit tests in camel I am aware of don't). It is invoked once, takes a
start timestamp, it delegates processing to the inner processor and then
takes the time diff and records it.
Now with a DelegateProcessor all this call is synchronous. Being actually a
DelegateAsyncProcessor, the call to the inner processor is done by the async
engine (see AsyncProcessorHelper.process()) which calls asynchronously on
the done() method. I assume this is what you see and interpret as a second
call.
This design is not wasting performance, quite to the contrary. It ensures a
better use of resources and scales much better with higher message volume.
I hope this helps,
Hadrian
On Dec 1, 2010, at 9:53 PM, ext2 wrote:
> Hi:
> Each camel processor will be wrapped with Instrument Interceptor
> twice. So for each process , the Instrument interceptor will be executed
> twice.
> It seems no use but waste performance;
> Why? Or a bug?
> Thanks for any suggestion.
>
>
>
Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
Posted by ext2 <xu...@tongtech.com>.
Thanks Harian Zbarcea:
Instrument will be useful. But being wrapped and execute twice for
single processor will be a waste;
Actually, I found this problem while debug and tracing a spring
configured camel route. At least in Camel 2.4.0 and using spring, it real
does wrap twice.
Maybe you could take a moment to debug and tracking a camel route ,
you will see it.
Or,you can turning on the "TRACE" level for logging, and checking
the Instrument Processor's output. You could see it;
Following is my route:
<route>
<from uri="direct:from" />
<bean id="id0" ref="bean1" method="normal" />
<to id="id0_1" uri="mock:result" />
<bean id="id1" ref="bean1" method="raiseError" />
</route>
But the trace result is : 2 of first bean, 2 of the "to" endpoint,
2 of the second bean and 1 for route;
-----Origin -----
Sender: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
Date: 2010/12/2 22:21
Receiver: users@camel.apache.org
Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for
each processor.
The InstrumentationProcessor is a delegate processor (aka interceptor) that
allows you do do before and after processing.
It is not really invoked twice (or I have to see a test case that does that,
the unit tests in camel I am aware of don't). It is invoked once, takes a
start timestamp, it delegates processing to the inner processor and then
takes the time diff and records it.
Now with a DelegateProcessor all this call is synchronous. Being actually a
DelegateAsyncProcessor, the call to the inner processor is done by the async
engine (see AsyncProcessorHelper.process()) which calls asynchronously on
the done() method. I assume this is what you see and interpret as a second
call.
This design is not wasting performance, quite to the contrary. It ensures a
better use of resources and scales much better with higher message volume.
I hope this helps,
Hadrian
On Dec 1, 2010, at 9:53 PM, ext2 wrote:
> Hi:
> Each camel processor will be wrapped with Instrument Interceptor
> twice. So for each process , the Instrument interceptor will be executed
> twice.
> It seems no use but waste performance;
> Why? Or a bug?
> Thanks for any suggestion.
>
>
>
Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
Posted by Hadrian Zbarcea <hz...@gmail.com>.
The InstrumentationProcessor is a delegate processor (aka interceptor) that allows you do do before and after processing.
It is not really invoked twice (or I have to see a test case that does that, the unit tests in camel I am aware of don't). It is invoked once, takes a start timestamp, it delegates processing to the inner processor and then takes the time diff and records it.
Now with a DelegateProcessor all this call is synchronous. Being actually a DelegateAsyncProcessor, the call to the inner processor is done by the async engine (see AsyncProcessorHelper.process()) which calls asynchronously on the done() method. I assume this is what you see and interpret as a second call.
This design is not wasting performance, quite to the contrary. It ensures a better use of resources and scales much better with higher message volume.
I hope this helps,
Hadrian
On Dec 1, 2010, at 9:53 PM, ext2 wrote:
> Hi:
> Each camel processor will be wrapped with Instrument Interceptor
> twice. So for each process , the Instrument interceptor will be executed
> twice.
> It seems no use but waste performance;
> Why? Or a bug?
> Thanks for any suggestion.
>
>
>