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:696)
> at
> com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1062)
> at
> com.ctc.wstx.sr.StreamScanner.getNextCharFromCurrent(StreamScanner.java:807)
> at
> com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java: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(FragmentStreamReader.java:68)
> at
> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(StaxJbiWrapper.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.java:103)
> at
> org.apache.camel.processor.ConvertBodyProcessor.process(ConvertBodyProcessor.java:57)
> at
> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorToAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:70)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:68)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:70)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)
> at
> org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:99)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:70)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:68)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:70)
> at
> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:290)
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:202)
> at
> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:256)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.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(UnitOfWorkProcessor.java:99)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:70)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:68)
> at
> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelProviderEndpoint.java:109)
> at
> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassLoader(JbiBinding.java:116)
> at
> org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveProviderExchange(CamelProviderEndpoint.java:107)
> at
> org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelProviderEndpoint.java:85)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:651)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:606)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInTx(AsyncBaseLifeCycle.java:501)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLifeCycle.java:370)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.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-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>
>>
>> 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-router/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/
