On Mon, Mar 2, 2009 at 6:43 PM, 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? Can you show your route and what you send to the direct endpoint?
> > > 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/
