On Tue, Jan 18, 2011 at 4:18 PM, Scott Came <[email protected]> wrote: > Thanks, Claus. > > I grepped my logs for AnnotationTypeConverterLoader and see a line like this: > > 16:52:10,678 | INFO | @qtp-727842206-0 | AnnotationTypeConverterLoader | > er.AnnotationTypeConverterLoader 66 | 72 - org.apache.camel.camel-core - > 2.4.0.fuse-02-00 | Found 3 packages with 0 @Converter classes to load > > Grepped for DefaultTypeConverter and see this: > > 16:52:10,680 | INFO | @qtp-727842206-0 | DefaultTypeConverter | > l.converter.DefaultTypeConverter 397 | 72 - org.apache.camel.camel-core - > 2.4.0.fuse-02-00 | Loaded 0 type converters in 0.003 seconds > > I'm guessing that's not good. I am running the current release version of > FUSE ESB (apache-servicemix-4.3.0-fuse-03-00). I'm not sure what version of > Camel is included, but I haven't done anything to update Camel outside of the > stock FUSE ESB distro. It looks from the above log message like it's Camel > 2.4.0.fuse-02-00. >
Yeah it should be fixed in FUSE ESB 4.3.1 which includes Camel 2.4.0-fuse-03-00 which has the fix. >From Camel 2.6 onwards we actually now will throw an exception on starting Camel if this situation happens again. Then it should be much easier for end user to spot something is wrong. > Thanks for your help. > --Scott > > -----Original Message----- > From: Claus Ibsen [mailto:[email protected]] > Sent: Monday, January 17, 2011 10:05 PM > To: [email protected] > Subject: Re: Large(ish) message issue (CXFBC and Camel) > > What versions of the products are you using? SMX / Camel? > And how do you startup the SMX container? > > I think there was a bug when using JBI with SMX 4.x that could lead to Camel > not being able to load type converters on startup (race condition when using > OSGi). This should be fixed in upcoming Apache SMX 4.3 release and already in > the latest FUSE ESB release. > > You should see something like this at INFO level logged by Camel on startup > (requires Camel 2.3 or better) > > 2011-01-18 07:05:00,519 [main ] INFO > AnnotationTypeConverterLoader - Found 3 packages with 19 @Converter classes > to load > 2011-01-18 07:05:00,567 [main ] INFO DefaultTypeConverter > - Loaded 150 type converters in 1.038 seconds > > > > On Tue, Jan 18, 2011 at 5:42 AM, Scott Came <[email protected]> wrote: >> Hi Freeman, thanks for the suggestion. >> >> I tried that and am seeing the same results. After consulting the Camel >> documentation about stream caching at >> http://camel.apache.org/stream-caching.html I tried various flavors of >> specifying it (e.g., specifying streamCache="true" on camelContext and >> streamCaching="true" and streamCache="true" on route)...none of those helped. >> >> I also tried removing the <to> element for the log message, and that didn't >> help either. >> >> It's like in the case of both <to uri="log..."> and <to uri="file..."> the >> stream from the jbi: endpoint is getting cut off after 1000-2000 bytes. >> Very strange. >> >> I set the log level to DEBUG, and I get a big nested stack trace at the >> expected place, with this as the last exception listed: >> >> Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected end of input >> block in start tag >> at [row,col {unknown-source}]: [51,20] >> at >> com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOB(StreamScanner.java:69 >> 6) >> at >> com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1 >> 062) >> at >> com.ctc.wstx.sr.StreamScanner.getNextCharFromCurrent(StreamScanner.jav >> a:807) >> at >> com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.ja >> va:2892) >> at >> com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java: >> 2783) >> at >> com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1048) >> at >> org.apache.servicemix.soap.util.stax.FragmentStreamReader.next(Fragmen >> tStreamReader.java:68) >> at >> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(StaxJbiWr >> apper.java:166) >> at >> org.apache.servicemix.soap.util.stax.StaxSource.parse(StaxSource.java: >> 116) >> ... 54 more >> >> Incidentally, the first exception (top of the stack) is this: >> >> org.apache.camel.InvalidPayloadException: No body available of type: >> java.lang.String but has value: >> org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207 of type: >> org.apache.servicemix.soap.util.stax.StaxSource on: Message: >> org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207. Caused by: >> No type converter available to convert from type: >> org.apache.servicemix.soap.util.stax.StaxSource to the required type: >> java.lang.String with value >> org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207. >> Exchange[Message: >> org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207]. Caused by: >> [org.apache.camel.NoTypeConversionAvailableException - No type >> converter available to convert from type: >> org.apache.servicemix.soap.util.stax.StaxSource to the required type: >> java.lang.String with value >> org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207] >> at >> org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSupport.j >> ava:103) >> at >> org.apache.camel.processor.ConvertBodyProcessor.process(ConvertBodyPro >> cessor.java:57) >> at >> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorT >> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50) >> at >> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelpe >> r.java:70) >> at >> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delegate >> AsyncProcessor.java:98) >> at >> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyn >> cProcessor.java:89) >> at >> org.apache.camel.management.InstrumentationProcessor.process(Instrumen >> tationProcessor.java:68) >> at >> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelpe >> r.java:70) >> at >> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delegate >> AsyncProcessor.java:98) >> at >> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyn >> cProcessor.java:89) >> at >> org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceI >> nterceptor.java:99) >> at >> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelpe >> r.java:70) >> at >> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delegate >> AsyncProcessor.java:98) >> at >> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyn >> cProcessor.java:89) >> at >> org.apache.camel.management.InstrumentationProcessor.process(Instrumen >> tationProcessor.java:68) >> at >> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelpe >> r.java:70) >> at >> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler( >> RedeliveryErrorHandler.java:290) >> at >> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryEr >> rorHandler.java:202) >> at >> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java: >> 256) >> at >> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelpe >> r.java:70) >> at org.apache.camel.processor.Pipeline.process(Pipeline.java:143) >> at org.apache.camel.processor.Pipeline.process(Pipeline.java:78) >> at >> org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProce >> ssor.java:99) >> at >> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelpe >> r.java:70) >> at >> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delegate >> AsyncProcessor.java:98) >> at >> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyn >> cProcessor.java:89) >> at >> org.apache.camel.management.InstrumentationProcessor.process(Instrumen >> tationProcessor.java:68) >> at >> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelProvider >> Endpoint.java:109) >> at >> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassLoader( >> JbiBinding.java:116) >> at >> org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveProvider >> Exchange(CamelProviderEndpoint.java:107) >> at >> org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelProvide >> rEndpoint.java:85) >> at >> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLif >> eCycle.java:651) >> at >> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncB >> aseLifeCycle.java:606) >> at >> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInTx(As >> yncBaseLifeCycle.java:501) >> at >> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLifeCyc >> le.java:370) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu >> tor.java:886) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. >> java:908) >> at java.lang.Thread.run(Thread.java:680) >> >> Any other ideas? >> >> Thanks. >> --Scott >> >> -----Original Message----- >> From: Freeman Fang [mailto:[email protected]] >> Sent: Monday, January 17, 2011 7:08 PM >> To: [email protected] >> Subject: Re: Large(ish) message issue (CXFBC and Camel) >> >> >> On 2011-1-18, at 上午10:41, Scott Came wrote: >> >>> I am seeing some strange behavior when using Camel to route from a >>> JBI endpoint (cxfbc) to a file using the Camel file component. >>> >>> Here is the scenario. >>> >>> I have created a JBI CXFBC service unit with WSDL. I have also >>> created a Camel service unit, with a very simple route: it routes >>> from the CXFBC endpoint to a file with a route that looks like this: >>> >>> <camelContext id="camel" xmlns="http://camel.apache.org/schema/ >>> spring"> >>> <route> >>> <from >>> uri="jbi:endpoint:http://it.ojp.gov/global/services/tsc-encounter-rou >>> t er/RouterService/RouterServiceEndpoint >>> "/> >>> <to uri="log:gov.ojp.it.TSCEncounterRouterLog?showBody=false"/> >>> <convertBodyTo type="java.lang.String"/> >>> <to uri="file:/Users/scott/Desktop/router-output"/> >>> </route> >>> </camelContext> >>> >>> I bundle these to SUs into an SA and deploy. Everything deploys fine. >>> >>> I then use SOAPUI to send test messages. >>> >>> If I send a very small message...say, no bigger than a couple hundred >>> bytes, to the RouterServiceEndpoint, everything works fine. >>> I see the log message in the log, and the file gets written to my >>> router-output directory. >>> >>> However, when I increase the message size beyond a certain point (not >>> sure exactly where it is...somewhere around 2000-3000 bytes) I start >>> getting messages like: >>> >>> Unexpected end of input block in start tag at [row,col {unknown- >>> source}]: [51,20] >>> >>> The underlying exception seems to be a >>> com.ctc.wstx.exc.WstcEOFException. >>> >>> If I try subsequent invocations of the service, I get a similar >>> error, though the referenced place in the stream is often a little >>> different (e.g., [51, 25] or [55, 10]). So it seems like the parser >>> is getting to a different place in the stream each time before it fails. >>> >>> I have put TCPMon in the middle and verified that the entire message >>> is getting to the server, although the server side is not closing the >>> connection when the exception occurs. >>> >>> I am 100% sure the content being sent is valid XML. >>> >>> Interestingly, if I take out the <to> part of the route to the file >>> component, everything works fine...I get the simple log message (note >>> that I am not logging the body content), and the connection closes in >>> TCPMon. However, if I switch to logging the body content (i.e., take >>> off the ?showBody=false option), I get similar errors as when I try >>> to write out the file. >> This looks like a stream already get consumed issue for me, how about >> you just >> >> How about you just change your router like <camelContext id="camel" >> xmlns="http://camel.apache.org/schema/spring";> >> <route streamCache="true" > >> <from >> uri="jbi:endpoint:http://it.ojp.gov/global/services/tsc-encounter-rout >> er/RouterService/RouterServiceEndpoint >> "/> >> <to uri="log:gov.ojp.it.TSCEncounterRouterLog?showBody=false"/> >> <convertBodyTo type="java.lang.String"/> >> <to uri="file:/Users/scott/Desktop/router-output"/> >> </route> >> </camelContext> >> >> Freeman >> >>> I have tried taking out the <convertBodyTo...> element, but that >>> results in a different exception...something about no appropriate >>> converter being found. >>> >>> It would be somewhat difficult for me to attach a full example, as >>> the content of the large message is somewhat sensitive/proprietary, >>> but I could do that if I absolutely needed to. I'm hoping there is >>> some simple configuration setting I need to tweak to handle bigger >>> messages (though a 2K or 3K message is by no means large...) >>> >>> Thanks for any help you can offer. >>> >>> --Scott >> >> >> -- >> Freeman Fang >> >> ------------------------ >> >> FuseSource: http://fusesource.com >> blog: http://freemanfang.blogspot.com >> twitter: http://twitter.com/freemanfang Apache >> Servicemix:http://servicemix.apache.org >> Apache Cxf: http://cxf.apache.org >> Apache Karaf: http://karaf.apache.org >> Apache Felix: http://felix.apache.org >> >> > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: [email protected] > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ > > -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
