Maybe we could add some kind of type converter cache to avoid the try ... catch work to improve the performance.
Willem paquettd wrote: > Thank you for trying to help. I'm attaching my config file here. As you can > see this is a contrived example I made to test performance (I used a similar > example with some other products). > > Essentially what's happening is a String is being sent with the > ProducerTemplate send method; setting the type to InOut. The string is > checked for lower case characters; and if it has any it goes to the > "capitalizer"; after that it goes to a reverser and truncator before finally > a timestamp is put into the header (before I sent it I put a timestamp as > well). I run this a few thousand times; using System.nanoTime for those > timestamps (while not real accurate I used the same thing with other COTS > and the relative differences are in time are larger than the clock > granularity) > > After I started seeing long processing times I used JProbe from Quest > Software to narrow down to the bottleneck we are talking about. JProbe tells > me that Exception is thrown 10 times processing one of these messages.... so > when I send 1000 messages 10,000 of those exceptions are being thrown and it > takes a very long time for the 1000 messages to get through. > > > <?xml version="1.0" encoding="UTF-8"?> > <beans xmlns="http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xmlns:camel="http://activemq.apache.org/camel/schema/spring"; > xsi:schemaLocation="http://www.springframework.org/schema/beans > > http://www.springframework.org/schema/beans/spring-beans.xsd > http://activemq.apache.org/camel/schema/spring > http://activemq.apache.org/camel/schema/spring/camel-spring.xsd";> > > <bean id="reverser" class="camel.test.StringReverser" /> > <bean id="capitalizer" class="camel.test.StringCapitalizer" /> > <bean id="truncater" class="camel.test.StringTruncater"> > <property name="length" value="10" /> > </bean> > <bean id="endTimestamper" > class="camel.test.transformers.HeaderTimestamper"> > <property name="headerKey" value="END_TIME"/> > </bean> > > <camelContext id="camel.test.camelcontext" > xmlns="http://activemq.apache.org/camel/schema/spring";> > <template id="myCamelTemplate" defaultEndpoint="direct:test" /> > > <route> > <from uri="direct:test" /> > <choice> > <when> > <simple>${body} regex > '.*[a-x].*'</simple> > <to uri="direct:capitalizeFirst" /> > </when> > <otherwise> > <to uri="direct:reverseAndTruncate" /> > </otherwise> > </choice> > </route> > > <route> > <from uri="direct:capitalizeFirst" /> > <bean ref="capitalizer" /> > <to uri="direct:reverseAndTruncate"/> > </route> > > <route> > <from uri="direct:reverseAndTruncate" /> > <bean ref="reverser" /> > <bean ref="truncater" /> > <to uri="bean:endTimestamper?method=timestamp"/> > </route> > </camelContext> > > <bean id="testDriver" class="camel.test.TestDriver"> > <property name="producerTemplate" ref="myCamelTemplate" /> > </bean> > </beans> > > > > Claus Ibsen-2 wrote: >> On Tue, Mar 3, 2009 at 1:17 AM, Willem Jiang <willem.ji...@gmail.com> >> wrote: >>> Hi, >>> >>> If you don't want the TypeConverter to get invovled , you could use >>> MessageSupport.getBody() directly. >> Yes I am wondering if he has a .convertBodyTo in the route, so we need >> to see this. >> >> Or some other endpoint/producer trying to get the body as a special >> type, eg InputStream etc. >> >> But the route would really help. >> >> >>> Willem >>> >>> >>> On Tue, Mar 3, 2009 at 1:43 AM, paquettd <dan.paque...@lmco.com> wrote: >>> >>>> I'm not sure if it makes a difference but I'm not using JMS anywhere. In >>>> fact >>>> in this test everything is using "direct". >>>> >>>> Is there something I can do in the Spring DSL to hint to Camel that >>>> there >>>> is >>>> no conversion necessary? >>>> >>>> >>>> Claus Ibsen-2 wrote: >>>>> On Mon, Mar 2, 2009 at 5:54 PM, paquettd <dan.paque...@lmco.com> >>>> wrote: >>>>>> I've been seeing some performance problems with Camel 1.6.0 (I have >>>> not >>>>>> tried >>>>>> this with previous versions yet). >>>>>> >>>>>> My profiler is pointing the finger at MessageSupport.getBody, >>>>>> TypeConverter.convertTo, and DefaultTypeConverter.findTypeConverter >>>>>> specifically >>>>>> >>>>>> findTypeConverter is always throwing a >>>>>> NoTypeConversionAvailableException; >>>>>> which is then being caught and ignored in MessageSupport.getBody; at >>>>>> which >>>>>> point processing continues successfully. >>>>> This should be normal in situations where you ask the body to be a >>>>> specific type which cannot be converted to. >>>>> To help this can you show your route and what kind of JMS messages are >>>>> you sending. >>>>> >>>>> Camel is payload type agnostics (eg dont have to be pure XML etc.) so >>>>> you can send whatever objects you like. >>>>> It has a rich type converter registry to be able to convert seamless >>>>> between types. >>>>> >>>>> This registry is loaded on demand, so you should make sure your start >>>>> profiling after Camel is "warm". >>>>> >>>>> >>>>> >>>>>> protected <T> T getBody(Class<T> type, Object body) is the specific >>>>>> getBody >>>>>> in question. >>>>>> >>>>>> Is this exception an expected behavior? It's weird how the catch >>>> block >>>>>> doesn't even log a warning. Should a converter have been found? My >>>>>> message >>>>>> payload is just a java.lang.String. >>>>> In the old days it returned null, but that did not work as the payload >>>>> you were trying to convert could be null, so it was a catch-22 >>>>> situation. >>>>> So we added the exception. >>>>> >>>>> But if throwing exception is expensive we could maybe add a has test >>>>> to avoid this exception being thrown and caught in the MessageSupport. >>>>> >>>>> The exception is also meant for end users so they get a good exception >>>>> detailing the problem if they try to convert something into eg, >>>>> MyFooClass and its not possible to convert to it. Instead of returning >>>>> a null value as result. >>>>> >>>>> >>>>>> I suspect I've done something wrong but I don't know where to start >>>>>> looking. >>>>>> I'm concerned with this; as I'm comparing Camel to some other message >>>>>> routing solutions. This is making Camel take 40 times longer than the >>>>>> competition and I want to make sure I do a fair comparison. >>>>> We are currently rewamping the internal API in Camel 2.0 that leads us >>>>> up to a point where we can do performance improvements when Camel >>>>> routes exchanges. >>>>> Currently it does a bit of defensive copying when it moves message >>>>> from node to node. The revamped API lets us do some more clever stuff >>>>> there to improve the speed. >>>>> >>>>> So if you are testing, eg. JMS -> JMS and want it to be really fast >>>>> then of course pure JMS to JMS is faster than eg over Camel as its a >>>>> very flexible and transport/protocol agnostic framework. But >>>>> performance improvements is on our roadmap in 2.1. >>>>> >>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> >>>> http://www.nabble.com/Performance-and-MessageSupport.getBody-%281.6.0%29-tp22291841p22291841.html >>>>>> Sent from the Camel - Users mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Claus Ibsen >>>>> Apache Camel Committer >>>>> >>>>> Open Source Integration: http://fusesource.com >>>>> Blog: http://davsclaus.blogspot.com/ >>>>> >>>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Performance-and-MessageSupport.getBody-%281.6.0%29-tp22291841p22292939.html >>>> Sent from the Camel - Users mailing list archive at Nabble.com. >>>> >>>> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> >> >
