Avoiding type conversions with the direct component
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
Avoiding type conversions with the direct component
by huntc
::
Rate this Message:
Hi there,
Quick (probably dumb) question. I'm looking to avoid a type conversion while using the direct: component. I've been of the opinion that using the direct: component is a nice way to break up my routes into nicely separated chunks. However I now find that sending a body with one of my (large) POJOs takes several seconds. Having profiled things I see that there is a "NoTypeConversionAvailableException" and then the stack trace shows that the object is being converted to a string, which then goes on to call a lot of JSON code I have. Here's a sample of the stack trace: ... com.classactionpl.gml.Feature.toString() java.lang.String.valueOf(Object) java.lang.StringBuilder.append(Object) org.apache.camel.NoTypeConversionAvailableException.Any recommendations on how I should avoid this conversion? Kind regards,
|
|
|
Re: Avoiding type conversions with the direct component
by Claus Ibsen-2
::
Rate this Message:
Hi
Its the stream cache that forces this. Use the google search bar to search for stream cache and see how to disable it. On Tue, Jun 16, 2009 at 2:26 PM, huntc<huntc@...> wrote: > > Hi there, > > Quick (probably dumb) question. I'm looking to avoid a type conversion while > using the direct: component. > > I've been of the opinion that using the direct: component is a nice way to > break up my routes into nicely separated chunks. However I now find that > sending a body with one of my (large) POJOs takes several seconds. > > Having profiled things I see that there is a > "NoTypeConversionAvailableException" and then the stack trace shows that the > object is being converted to a string, which then goes on to call a lot of > JSON code I have. Here's a sample of the stack trace: > > > ... > com.classactionpl.gml.Feature.toString() > java.lang.String.valueOf(Object) > java.lang.StringBuilder.append(Object) > org.apache.camel.NoTypeConversionAvailableException.(Object, Class) > org.apache.camel.impl.converter.DefaultTypeConverter.doConvertTo(Class, > Exchange, Object) > org.apache.camel.impl.converter.DefaultTypeConverter.convertTo(Class, > Exchange, Object) > org.apache.camel.impl.MessageSupport.getBody(Class, Object) > org.apache.camel.impl.MessageSupport.getBody(Class) > org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, > AsyncCallback) > org.apache.camel.processor.DeadLetterChannel.process(Exchange, > AsyncCallback, DeadLetterChannel$RedeliveryData) > org.apache.camel.processor.DeadLetterChannel.process(Exchange, > AsyncCallback) > org.apache.camel.processor.Pipeline.process(Exchange, Exchange, > AsyncCallback, Iterator, AsyncProcessor) > org.apache.camel.processor.Pipeline.process(Exchange, AsyncCallback) > org.apache.camel.management.InstrumentationProcessor.process(Exchange, > AsyncCallback) > org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(Exchange, > AsyncCallback) > org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, > AsyncCallback) > org.apache.camel.processor.UnitOfWorkProcessor.process(Exchange, > AsyncCallback) > org.apache.camel.component.direct.DirectProducer.process(Exchange, > AsyncCallback) > org.apache.camel.processor.SendProcessor.process(Exchange, AsyncCallback) > org.apache.camel.management.InstrumentationProcessor.process(Exchange, > AsyncCallback) > org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(Exchange, > AsyncCallback) > org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, > AsyncCallback) > org.apache.camel.processor.DeadLetterChannel.process(Exchange, > AsyncCallback, DeadLetterChannel$RedeliveryData) > org.apache.camel.processor.DeadLetterChannel.process(Exchange, > AsyncCallback) > org.apache.camel.processor.Pipeline.process(Exchange, Exchange, > AsyncCallback, Iterator, AsyncProcessor) > org.apache.camel.processor.Pipeline.process(Exchange, AsyncCallback) > org.apache.camel.management.InstrumentationProcessor.process(Exchange, > AsyncCallback) > org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(Exchange, > AsyncCallback) > org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(Exchange, > AsyncCallback) > org.apache.camel.processor.UnitOfWorkProcessor.process(Exchange, > AsyncCallback) > org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessor, Exchange) > org.apache.camel.processor.DelegateAsyncProcessor.process(Exchange) > org.apache.camel.processor.loadbalancer.QueueLoadBalancer.process(Exchange) > org.apache.camel.component.quartz.QuartzEndpoint.onJobExecute(JobExecutionContext) > org.apache.camel.component.quartz.CamelJob.execute(JobExecutionContext) > org.quartz.core.JobRunShell.run() > org.quartz.simpl.SimpleThreadPool$WorkerThread.run() > > > Any recommendations on how I should avoid this conversion? > > Kind regards, > Christopher > -- > View this message in context: http://www.nabble.com/Avoiding-type-conversions-with-the-direct-component-tp24053271p24053271.html > Sent from the Camel - Users (activemq) mailing list archive at Nabble.com. > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus |
|
|
Re: Avoiding type conversions with the direct component
by huntc
::
Rate this Message:
Yes, it looks as though it is the stream cache, but what's interesting is that you can't disable the stream cache if you're using the default error handler:
http://www.nabble.com/Re%3A-StreamCaching-in-Camel-1.6-to22305858.html So you've effectively got to disable the error handler for a route if you don't want to use the stream cache. This seems kind of awkward... does Camel 2.0 improve this situation? |
|
|
Re: Avoiding type conversions with the direct component
by Claus Ibsen-2
::
Rate this Message:
On Tue, Jun 16, 2009 at 2:58 PM, huntc<huntc@...> wrote:
> > Yes, it looks as though it is the stream cache, but what's interesting is > that you can't disable the stream cache if you're using the default error > handler: > > http://www.nabble.com/Re%3A-StreamCaching-in-Camel-1.6-to22305858.html > > So you've effectively got to disable the error handler for a route if you > don't want to use the stream cache. > > This seems kind of awkward... does Camel 2.0 improve this situation? option to enable it per route. Then if people uses stream then they can enable the cache on demand in case they want to let Camel be able to error handling with redeliveris (as it need to read the stream more than once) or content based routing where you also need to read the content. > -- > View this message in context: http://www.nabble.com/Avoiding-type-conversions-with-the-direct-component-tp24053271p24053805.html > Sent from the Camel - Users (activemq) mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus |
| Free embeddable forum powered by Nabble | Forum Help |
