Thanks, Claus. Is there anything I can do in the meantime? Is the fix in a current Camel build? If so, are there docs on how to update the Camel components in SM?
--Scott -----Original Message----- From: Claus Ibsen [mailto:[email protected]] Sent: Tuesday, January 18, 2011 7:56 AM To: [email protected] Subject: Re: Large(ish) message issue (CXFBC and Camel) On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen <[email protected]> wrote: > 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. > Correction, that would be the next FUSE ESB 4.3.0 release. I think there is a ESB 4.3.1 planned later this month/next month which will ship with Camel 2.6 (currently in progress). > 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.j >>> av >>> 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(Fragm >>> en >>> tStreamReader.java:68) >>> at >>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(StaxJbi >>> Wr >>> 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(ConvertBodyP >>> ro >>> cessor.java:57) >>> at >>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Processo >>> rT >>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50) >>> at >>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel >>> pe >>> r.java:70) >>> at >>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delega >>> te >>> AsyncProcessor.java:98) >>> at >>> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAs >>> yn >>> cProcessor.java:89) >>> at >>> org.apache.camel.management.InstrumentationProcessor.process(Instrum >>> en >>> tationProcessor.java:68) >>> at >>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel >>> pe >>> r.java:70) >>> at >>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delega >>> te >>> AsyncProcessor.java:98) >>> at >>> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAs >>> yn >>> cProcessor.java:89) >>> at >>> org.apache.camel.processor.interceptor.TraceInterceptor.process(Trac >>> eI >>> nterceptor.java:99) >>> at >>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel >>> pe >>> r.java:70) >>> at >>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delega >>> te >>> AsyncProcessor.java:98) >>> at >>> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAs >>> yn >>> cProcessor.java:89) >>> at >>> org.apache.camel.management.InstrumentationProcessor.process(Instrum >>> en >>> tationProcessor.java:68) >>> at >>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel >>> pe >>> r.java:70) >>> at >>> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandle >>> r( >>> RedeliveryErrorHandler.java:290) >>> at >>> org.apache.camel.processor.RedeliveryErrorHandler.process(Redelivery >>> Er >>> rorHandler.java:202) >>> at >>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java: >>> 256) >>> at >>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel >>> pe >>> 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(UnitOfWorkPro >>> ce >>> ssor.java:99) >>> at >>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel >>> pe >>> r.java:70) >>> at >>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delega >>> te >>> AsyncProcessor.java:98) >>> at >>> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAs >>> yn >>> cProcessor.java:89) >>> at >>> org.apache.camel.management.InstrumentationProcessor.process(Instrum >>> en >>> tationProcessor.java:68) >>> at >>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelProvid >>> er >>> Endpoint.java:109) >>> at >>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassLoade >>> r( >>> JbiBinding.java:116) >>> at >>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveProvid >>> er >>> Exchange(CamelProviderEndpoint.java:107) >>> at >>> org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelProvi >>> de >>> rEndpoint.java:85) >>> at >>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseL >>> if >>> eCycle.java:651) >>> at >>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(Asyn >>> cB >>> aseLifeCycle.java:606) >>> at >>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInTx( >>> As >>> yncBaseLifeCycle.java:501) >>> at >>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLifeC >>> yc >>> le.java:370) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExe >>> cu >>> 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-r >>>> ou 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-ro >>> ut 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/ > -- 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/
