On Wed, Jan 19, 2011 at 1:59 PM, Scott Came <[email protected]> wrote: > Fuse ESB 4.3.0-03-00 is what I'm using...it contains Camel 2.4. If I > understand Claus correctly, I need Camel 2.6... >
No the bug is fixed in FUSE Camel 2.4. (latest version of FUSE 2.4 version). At Apache the bug is only to be fixed in the upcoming Camel 2.6 release. > -----Original Message----- > From: Willem Jiang [mailto:[email protected]] > Sent: Wednesday, January 19, 2011 2:02 AM > To: [email protected] > Subject: Re: Large(ish) message issue (CXFBC and Camel) > > Why don't you just download the Fuse ESB 4.3.0-fuse-03-00? > You don't need to build the component yourself. > > On 1/19/11 10:34 AM, Scott Came wrote: >> I've actually succeeded in building the 2011.01-SNAPSHOT version of >> servicemix-camel that's in SVN. I have the component .jar and installer >> .zip in my local maven repository now. >> >> Any reason why I shouldn't be able to install that in >> servicemix-4.3.0-fuse-03-00? Do I just drop the zip file in the deploy >> directory? Do I need to be worried about conflicts with the currently >> installed version of Camel (i.e., should I uninstall)? >> >> Excuse the newbie questions...is there a way to deploy this snapshot via the >> features mechanism? >> >> Anyway, if I can get this going I'd be happy to testdrive the >> 2011.01-SNAPSHOT build of servicemix-camel... >> >> Thanks. >> --Scott >> >> -----Original Message----- >> From: Scott Came [mailto:[email protected]] >> Sent: Tuesday, January 18, 2011 12:33 PM >> To: [email protected] >> Subject: RE: Large(ish) message issue (CXFBC and Camel) >> >> 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.jav >>>>> a >>>>> :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(Frag >>>>> m >>>>> en >>>>> tStreamReader.java:68) >>>>> at >>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(StaxJb >>>>> i >>>>> 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(MessageSuppor >>>>> t >>>>> .j >>>>> ava:103) >>>>> at >>>>> org.apache.camel.processor.ConvertBodyProcessor.process(ConvertBody >>>>> P >>>>> ro >>>>> cessor.java:57) >>>>> at >>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Process >>>>> o >>>>> rT >>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50) >>>>> at >>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHe >>>>> l >>>>> pe >>>>> r.java:70) >>>>> at >>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Deleg >>>>> a >>>>> te >>>>> AsyncProcessor.java:98) >>>>> at >>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateA >>>>> s >>>>> yn >>>>> cProcessor.java:89) >>>>> at >>>>> org.apache.camel.management.InstrumentationProcessor.process(Instru >>>>> m >>>>> en >>>>> tationProcessor.java:68) >>>>> at >>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHe >>>>> l >>>>> pe >>>>> r.java:70) >>>>> at >>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Deleg >>>>> a >>>>> te >>>>> AsyncProcessor.java:98) >>>>> at >>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateA >>>>> s >>>>> yn >>>>> cProcessor.java:89) >>>>> at >>>>> org.apache.camel.processor.interceptor.TraceInterceptor.process(Tra >>>>> c >>>>> eI >>>>> nterceptor.java:99) >>>>> at >>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHe >>>>> l >>>>> pe >>>>> r.java:70) >>>>> at >>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Deleg >>>>> a >>>>> te >>>>> AsyncProcessor.java:98) >>>>> at >>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateA >>>>> s >>>>> yn >>>>> cProcessor.java:89) >>>>> at >>>>> org.apache.camel.management.InstrumentationProcessor.process(Instru >>>>> m >>>>> en >>>>> tationProcessor.java:68) >>>>> at >>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHe >>>>> l >>>>> pe >>>>> r.java:70) >>>>> at >>>>> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandl >>>>> e >>>>> r( >>>>> RedeliveryErrorHandler.java:290) >>>>> at >>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Redeliver >>>>> y >>>>> Er >>>>> rorHandler.java:202) >>>>> at >>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java: >>>>> 256) >>>>> at >>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHe >>>>> l >>>>> 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(UnitOfWorkPr >>>>> o >>>>> ce >>>>> ssor.java:99) >>>>> at >>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHe >>>>> l >>>>> pe >>>>> r.java:70) >>>>> at >>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Deleg >>>>> a >>>>> te >>>>> AsyncProcessor.java:98) >>>>> at >>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateA >>>>> s >>>>> yn >>>>> cProcessor.java:89) >>>>> at >>>>> org.apache.camel.management.InstrumentationProcessor.process(Instru >>>>> m >>>>> en >>>>> tationProcessor.java:68) >>>>> at >>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelProvi >>>>> d >>>>> er >>>>> Endpoint.java:109) >>>>> at >>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassLoad >>>>> e >>>>> r( >>>>> JbiBinding.java:116) >>>>> at >>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveProvi >>>>> d >>>>> er >>>>> Exchange(CamelProviderEndpoint.java:107) >>>>> at >>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelProv >>>>> i >>>>> de >>>>> rEndpoint.java:85) >>>>> at >>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBase >>>>> L >>>>> if >>>>> eCycle.java:651) >>>>> at >>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(Asy >>>>> n >>>>> cB >>>>> aseLifeCycle.java:606) >>>>> at >>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInTx >>>>> ( >>>>> As >>>>> yncBaseLifeCycle.java:501) >>>>> at >>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLife >>>>> C >>>>> yc >>>>> le.java:370) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolEx >>>>> e >>>>> 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-r >>>>> o 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/ >> > > > -- > Willem > ---------------------------------- > FuseSource > Web: http://www.fusesource.com > Blog: http://willemjiang.blogspot.com (English) > http://jnn.javaeye.com (Chinese) > Twitter: willemjiang > > -- 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/
