[
https://issues.apache.org/activemq/browse/CAMEL-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61841#action_61841
]
Claus Ibsen commented on CAMEL-3123:
------------------------------------
Yeah its a sequential test, but its still faster because each message caused
the property editor to be invoked about 4-6 times.
I add specialized type converters for StringBuffer/StringBuilder -> String +
Jetty specific as well, which removes the usage of the property editor being
used.
However I will add an internal cache to it because you may have other cases
where you want to convert a custom XXX object -> String which potentially can
use the property editor to find an editor, and hence the synchronized stuff and
as you write above some load class stuff as well.
Will commit this stuff after tests run is complete. Then you can maybe try it
out on your system? You need to build from the source yourself.
Yeah anything can break in OSGi. Don't assume it just works, that is the
attitude I use after seining so many issue with it.
> Performance/scalability issue for converter lookup
> --------------------------------------------------
>
> Key: CAMEL-3123
> URL: https://issues.apache.org/activemq/browse/CAMEL-3123
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 2.4.0
> Environment: Camel 2.4.0 on apache karaf 2.0.0
> Reporter: Stephan Siano
> Assignee: Claus Ibsen
>
> In a simple HTTP->HTTP proxy scenario (whith a Jetty or a servlet endpoint,
> that does not matter) I observe a very severe performance regression between
> Camel 2.2.0 (as in servicemix 4.2) and camel 2.4.0 running on a apache karaf
> 2.0.0 OSGi stack. On the same hardware I get a throughput of 3500 messages
> per second with Camel 2.2.0, but only 210 messages per second on Camel 2.4.0
> (both servlet->HTTP). If I replace the http endpoint with a log endpoint the
> throughput will be about 1500 messages per second in both cases.
> I have done some profiling for this: The active CPU times as shown in the
> profiler remain approximately the same for both versions, however if I
> monitor wait times, I get very long wait times for
> org.apache.camel.impl.DefaultMessage.getHeader(java.lang.String,java.lang.Class)
> calls. If I break this down I see the
> java.beans.PropertyEditorManager.findEditor(java.lang.Class) call in
> org.apache.camel.impl.converter.PropertyEditorTypeConverter.convertTo(java.lang.Class,java.lang.Object).
> The findEditor() method is synchronized and initializes some class loading
> which takes some time.
> Why is it necessary to instantiate the type converter for each message?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
