Hi, If you don't want the TypeConverter to get invovled , you could use MessageSupport.getBody() directly.
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. > >
