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...
-----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
