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.
