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/ > > -- View this message in context: http://www.nabble.com/Performance-and-MessageSupport.getBody-%281.6.0%29-tp22291841p22308896.html Sent from the Camel - Users mailing list archive at Nabble.com.
