You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Scott Came <sc...@search.org> on 2011/01/18 03:41:46 UTC
Large(ish) message issue (CXFBC and Camel)
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-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>
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.
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
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Willem Jiang <wi...@gmail.com>.
On 1/29/11 10:16 AM, Freeman Fang wrote:
>
> On 2011-1-29, at 上午8:52, Scott Came wrote:
>
>> Willem:
>>
>> Hopefully this will be addressed at some point? Are you suggesting
>> that Servicemix 4 won't support accessing Camel SUs via JBI?
> SMX4 support JBI, so the jbi camel su still works, you can take a look
> at camel example shipped with kit.
>>
>> I really would like to use JBI for my application, to take advantage
>> of the NMR. I don't see how I would do that if I deployed the Camel
>> route in a bundle.
> However use camel route bundle directly, you still can take advantage of
> the nmr, as smx4 provide a camel-nmr[1] component, which let you use nmr
> in your camel router directly, you needn't JBI stuff in this cas. You
> can take a look at camel-nmr and cxf-camel-nmr examples shipped with
> smx4 kit.
> [1]http://camel.apache.org/nmr.html
>
> Freeman
>>
>> I did rebuild the Camel service engine as part of my build from
>> source, so I would expect that everything would pick up the latest
>> version of Camel.
Camel 2.6.0 is released, can you updated the servicemix to pick up it
and run the test?
>>
>> Thanks.
>> --Scott
>>
>> -----Original Message-----
>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>> Sent: Thursday, January 27, 2011 4:06 AM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> Hi Scott
>>
>> I just realize you were using the old JBI stuff.
>> As you are using ServiceMix 4.x, I suggest you put the camel route
>> into a bundle instead create a Camel Service Engine SU for the route.
>>
>> As the Camel Service Engine also have a lib which has the camel-core
>> and camel-spring, I'm not sure it cause the issue that you met.
>>
>> Willem
>>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Freeman Fang <fr...@gmail.com>.
On 2011-1-29, at 上午8:52, Scott Came wrote:
> Willem:
>
> Hopefully this will be addressed at some point? Are you suggesting
> that Servicemix 4 won't support accessing Camel SUs via JBI?
SMX4 support JBI, so the jbi camel su still works, you can take a look
at camel example shipped with kit.
>
> I really would like to use JBI for my application, to take advantage
> of the NMR. I don't see how I would do that if I deployed the Camel
> route in a bundle.
However use camel route bundle directly, you still can take advantage
of the nmr, as smx4 provide a camel-nmr[1] component, which let you
use nmr in your camel router directly, you needn't JBI stuff in this
cas. You can take a look at camel-nmr and cxf-camel-nmr examples
shipped with smx4 kit.
[1]http://camel.apache.org/nmr.html
Freeman
>
> I did rebuild the Camel service engine as part of my build from
> source, so I would expect that everything would pick up the latest
> version of Camel.
>
> Thanks.
> --Scott
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com]
> Sent: Thursday, January 27, 2011 4:06 AM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> Hi Scott
>
> I just realize you were using the old JBI stuff.
> As you are using ServiceMix 4.x, I suggest you put the camel route
> into a bundle instead create a Camel Service Engine SU for the route.
>
> As the Camel Service Engine also have a lib which has the camel-core
> and camel-spring, I'm not sure it cause the issue that you met.
>
> Willem
>
> On 1/27/11 9:49 AM, Scott Came wrote:
>> Willem (and list):
>>
>> I just checked out the smx4 features, nmr, and components source
>> trees (trunk) today and built all three. Servicemix starts and
>> runs fine. I noted that the components are dependent on Camel
>> 2.6.0 (at least it appears that way to me):
>>
>> 126:servicemix scott$ find system | grep camel system/org/apache/
>> camel
>> system/org/apache/camel/camel-core
>> system/org/apache/camel/camel-core/2.6-SNAPSHOT
>> system/org/apache/camel/camel-core/2.6-SNAPSHOT/camel-core-2.6-
>> SNAPSHO
>> T.jar
>> system/org/apache/camel/camel-spring
>> system/org/apache/camel/camel-spring/2.6-SNAPSHOT
>> system/org/apache/camel/camel-spring/2.6-SNAPSHOT/camel-spring-2.6-
>> SNA
>> PSHOT.jar
>> system/org/apache/camel/karaf
>> system/org/apache/camel/karaf/apache-camel
>> system/org/apache/camel/karaf/apache-camel/2.6-SNAPSHOT
>> system/org/apache/camel/karaf/apache-camel/2.6-SNAPSHOT/apache-
>> camel-2
>> .6-SNAPSHOT-features.xml system/org/apache/servicemix/servicemix-
>> camel
>> system/org/apache/servicemix/servicemix-camel/2011.01-SNAPSHOT
>> system/org/apache/servicemix/servicemix-camel/2011.01-SNAPSHOT/
>> service
>> mix-camel-2011.01-SNAPSHOT.jar
>>
>> and...
>>
>> karaf@root> osgi:list | grep camel
>> [ 68] [Active ] [ ] [ ] [ 60] camel-core
>> (2.6.0.SNAPSHOT)
>> [ 75] [Active ] [ ] [ ] [ 60] camel-spring
>> (2.6.0.SNAPSHOT)
>> karaf@root> osgi:list | grep Camel
>> [ 169] [Active ] [Created ] [ ] [ 60] Apache
>> ServiceMix :: Components :: Camel Service Engine (2011.01.0.SNAPSHOT)
>> karaf@root>
>>
>> However, when I deploy my service assembly and send the larger
>> message in, I see the same behavior as with Camel 2.4 that's build
>> into Fuse ESB 4.3.0-03-00. Do I need to do anything explicit to
>> have the build include the latest version of Camel in which this
>> bug is supposedly fixed?
>>
>> I also noted that the log messages that Claus suggested I should
>> see are not showing up (grepping the log for
>> AnnotationTypeConverterLoader and DefaultTypeConverter returns no
>> lines, and my log level is set at INFO...) Is this a sign of a
>> problem with my build? I do see the following in the log:
>>
>> 17:45:52,176 | INFO | rint Extender: 1 |
>> OsgiSpringCamelContext | e.camel.impl.DefaultCamelContext
>> 1293 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Apache
>> Camel 2.6-SNAPSHOT (CamelContext: camel) is starting
>> 17:45:52,320 | INFO | rint Extender: 1 |
>> Activator | BundleTypeConverterLoader
>> $Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT |
>> Found 1 @Converter classes to load
>> 17:45:52,324 | INFO | rint Extender: 1 |
>> Activator | BundleTypeConverterLoader
>> $Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT |
>> Found 1 @Converter classes to load
>> 17:45:52,380 | INFO | rint Extender: 1 |
>> Activator | BundleTypeConverterLoader
>> $Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT |
>> Found 13 @Converter classes to load
>>
>> Thanks.
>> --Scott
>>
>> -----Original Message-----
>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>> Sent: Monday, January 24, 2011 10:48 PM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> Hi Scott,
>>
>> I'm sorry I didn't aware you are using servicemix-camel component
>> (JBI) version. In this case the upgrading will be more complicated.
>> You need to updated the servicemix-camel lib with the new version
>> of camel-spring.
>>
>> Fortunately we just cut Camel 2.6.0 and it will be part of Apache
>> ServiceMix new version very soon. And we are releasing a new
>> version of Fuse ESB 4.3.1 this week.
>>
>> Willem
>>
>> On 1/24/11 9:53 AM, Scott Came wrote:
>>> Willem:
>>>
>>> I did my best to understand what you suggested I do, but I'm not
>>> confident that I'm doing it right. Here is what I did:
>>>
>>> -- I shut down servicemix
>>>
>>> -- I downloaded the jar
>>> http://repo.fusesource.com/nexus/content/groups/public-snapshots/
>>> org/
>>> a
>>> pache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-
>>> fuse-
>>> 2
>>> 0110118.002228-16.jar
>>>
>>> -- I extracted the contents of that jar to a temporary directory
>>>
>>> -- I extracted the contents of the camel-spring-2.4.0-fuse-02-00,
>>> and
>>> copied its META-INF/MANIFEST.MF file to the META-INF directory of
>>> the
>>> extracted snapshot jar
>>>
>>> -- I re-jarred the snapshot
>>>
>>> -- I deleted the camel-sprint-2.4.0-fuse-02-00.jar from
>>> $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>>>
>>> -- I copied the snapshot jar (with the updated MANIFEST.MF) into
>>> $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>>>
>>> -- I deleted my $SMX_HOME/data directory
>>>
>>> -- I restarted servicemix
>>>
>>> After these steps, servicemix seems to start normally. Osgi:list:
>>>
>>> [ 153] [Active ] [Created ] [ ] [ 60] Apache
>>> ServiceMix :: Components :: Camel Service Engine
>>> (2010.02.0.fuse-02-00)
>>>
>>> Jbi:list
>>>
>>> [Started ] [servicemix-camel ]
>>>
>>> However, when I deploy my service assembly, I get a stack trace
>>> (see attached).
>>>
>>> Is this sequence of steps what you intended me to try? Any idea
>>> what's going wrong and where?
>>>
>>> Alternatively...is this version of camel-spring already included in
>>> some snapshot version of the entire FUSE ESB? If so, would it
>>> likely
>>> work better for me just to check out the ESB shapshot and build it?
>>> If so, are there instructions somewhere for finding the source
>>> repository and checking out the snapshot? (I looked at
>>> http://fusesource.com/forge/projects/fuseesb/source which says to
>>> use
>>> Subversion as such: svn co
>>> http://fusesource.com/forge/svn/fuseesb/trunk fuseesb; however,
>>> when
>>> I do, I get "svn: URL 'http://fusesource.com/forge/svn/fuseesb/
>>> trunk'
>>> doesn't exist".)
>>>
>>> Either way, I think I can offer some value to the project here by
>>> testing the new camel version, but I'm kinda stuck as a newcomer
>>> to the platform on some of these issues. Any help you can offer
>>> would be much appreciated.
>>>
>>> Thanks.
>>> --Scott
>>>
>>> -----Original Message-----
>>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>>> Sent: Thursday, January 20, 2011 10:02 PM
>>> To: users@servicemix.apache.org
>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>
>>> Yeah, you may need to hack the META-INF/manifest file yourself if
>>> you don't want to massage the bundle version complains yourself.
>>>
>>> The sample way download the snapshot jar and replace the manifest
>>> file of camel-spring 2.4.0-fuse-02-00.jar, and place the jar into
>>> the $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-
>>> fuse-01-00, restart the servicemix after deleting the $SMX_HOME/
>>> data.
>>>
>>> Willem
>>>
>>> On 1/20/11 8:56 PM, Scott Came wrote:
>>>> Thanks, Willem, I'll give that a try.
>>>>
>>>> Again apologies for my newbie questions, but I couldn't find any
>>>> docs on this question: If I'm to install this component, what do
>>>> I need to uninstall first to avoid conflicts? I have read things
>>>> about not having multiple versions of Camel-* going at the same
>>>> time...
>>>>
>>>> Also I assume I just download this jar and drop it in the deploy
>>>> directory...correct?
>>>>
>>>> Thanks much.
>>>> --Scott
>>>>
>>>> -----Original Message-----
>>>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>>>> Sent: Wednesday, January 19, 2011 9:36 PM
>>>> To: users@servicemix.apache.org
>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>
>>>> On 1/19/11 10:15 PM, Claus Ibsen wrote:
>>>>> On Wed, Jan 19, 2011 at 2:26 PM, Scott
>>>>> Came<sc...@search.org> wrote:
>>>>>> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From
>>>>>> the log messages I included in my message yesterday, it looks
>>>>>> like
>>>>>> my install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log
>>>>>> message:>>>> 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.)
>>>>>>
>>>>>> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so
>>>>>> is that now available in the Fuse ESB 4.3.0-03-00 download (I
>>>>>> just installed ESB 4.3.0-03-00 late last week)?
>>>>>>
>>>>>> If not, is there something else that's causing the type
>>>>>> converters not to get loaded?
>>>>>>
>>>>>
>>>>> Its this bug which was fixed dec-20-2010
>>>>> http://fusesource.com/issues/browse/MR-392
>>>>>
>>>>> And -03 hasn't been released yet.
>>>> Maybe you can consider to try out the camel-spring 2.4.0-fuse-
>>>> SNAPSHOT[1] which has the fix?
>>>>
>>>> [1]http://repo.fusesource.com/nexus/content/groups/public-
>>>> snapshots/
>>>> o
>>>> r
>>>> g/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-
>>>> spring-2.4.0-f
>>>> u
>>>> s
>>>> e-20110118.002228-16.jar
>>>>
>>>>>
>>>>>
>>>>>> Thanks for all your help...
>>>>>> --Scott
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>>> Sent: Wednesday, January 19, 2011 5:14 AM
>>>>>> To: users@servicemix.apache.org
>>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>>
>>>>>> On Wed, Jan 19, 2011 at 1:59 PM, Scott
>>>>>> Came<sc...@search.org> 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:willem.jiang@gmail.com]
>>>>>>> Sent: Wednesday, January 19, 2011 2:02 AM
>>>>>>> To: users@servicemix.apache.org
>>>>>>> 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:scott.came@search.org]
>>>>>>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>>>>>>> To: users@servicemix.apache.org
>>>>>>>> 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:claus.ibsen@gmail.com]
>>>>>>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>>>>>>> To: users@servicemix.apache.org
>>>>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>>>>
>>>>>>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<claus.ibsen@gmail.com
>>>>>>>> > wrote:
>>>>>>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<scott.came@search.org
>>>>>>>>> > 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:claus.ibsen@gmail.com]
>>>>>>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>>>>>>> To: users@servicemix.apache.org
>>>>>>>>>> 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<scott.came@search.org
>>>>>>>>>> > 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.
>>>>>>>>>>> ja
>>>>>>>>>>> v
>>>>>>>>>>> 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:
>>>>>>>>>>> 1
>>>>>>>>>>> 0
>>>>>>>>>>> 48
>>>>>>>>>>> )
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.servicemix.soap.util.stax.FragmentStreamReader.nex
>>>>>>>>>>> t
>>>>>>>>>>> (
>>>>>>>>>>> F
>>>>>>>>>>> ra
>>>>>>>>>>> g
>>>>>>>>>>> m
>>>>>>>>>>> en
>>>>>>>>>>> tStreamReader.java:68)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(
>>>>>>>>>>> S
>>>>>>>>>>> t
>>>>>>>>>>> a
>>>>>>>>>>> xJ
>>>>>>>>>>> b
>>>>>>>>>>> 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(Message
>>>>>>>>>>> S
>>>>>>>>>>> u
>>>>>>>>>>> p
>>>>>>>>>>> po
>>>>>>>>>>> r
>>>>>>>>>>> t
>>>>>>>>>>> .j
>>>>>>>>>>> ava:103)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.ConvertBodyProcessor.process(Conve
>>>>>>>>>>> r
>>>>>>>>>>> t
>>>>>>>>>>> B
>>>>>>>>>>> od
>>>>>>>>>>> y
>>>>>>>>>>> P
>>>>>>>>>>> ro
>>>>>>>>>>> cessor.java:57)
>>>>>>>>>>> at
>>>>>>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter
>>>>>>>>>>> $P
>>>>>>>>>>> r
>>>>>>>>>>> o
>>>>>>>>>>> c
>>>>>>>>>>> es
>>>>>>>>>>> s
>>>>>>>>>>> o
>>>>>>>>>>> rT
>>>>>>>>>>> oAsyncProcessorBridge
>>>>>>>>>>> .process(AsyncProcessorTypeConverter.java:50)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>>> s
>>>>>>>>>>> s
>>>>>>>>>>> o
>>>>>>>>>>> rH
>>>>>>>>>>> e
>>>>>>>>>>> l
>>>>>>>>>>> pe
>>>>>>>>>>> r.java:70)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.DelegateAsyncProcessor.processNext
>>>>>>>>>>> (
>>>>>>>>>>> D
>>>>>>>>>>> e
>>>>>>>>>>> le
>>>>>>>>>>> g
>>>>>>>>>>> a
>>>>>>>>>>> te
>>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.DelegateAsyncProcessor.process(Del
>>>>>>>>>>> e
>>>>>>>>>>> g
>>>>>>>>>>> a
>>>>>>>>>>> te
>>>>>>>>>>> A
>>>>>>>>>>> s
>>>>>>>>>>> yn
>>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.management.InstrumentationProcessor.process(
>>>>>>>>>>> I
>>>>>>>>>>> n
>>>>>>>>>>> s
>>>>>>>>>>> tr
>>>>>>>>>>> u
>>>>>>>>>>> m
>>>>>>>>>>> en
>>>>>>>>>>> tationProcessor.java:68)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>>> s
>>>>>>>>>>> s
>>>>>>>>>>> o
>>>>>>>>>>> rH
>>>>>>>>>>> e
>>>>>>>>>>> l
>>>>>>>>>>> pe
>>>>>>>>>>> r.java:70)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.DelegateAsyncProcessor.processNext
>>>>>>>>>>> (
>>>>>>>>>>> D
>>>>>>>>>>> e
>>>>>>>>>>> le
>>>>>>>>>>> g
>>>>>>>>>>> a
>>>>>>>>>>> te
>>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.DelegateAsyncProcessor.process(Del
>>>>>>>>>>> e
>>>>>>>>>>> g
>>>>>>>>>>> a
>>>>>>>>>>> te
>>>>>>>>>>> A
>>>>>>>>>>> s
>>>>>>>>>>> yn
>>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.interceptor.TraceInterceptor.proce
>>>>>>>>>>> s
>>>>>>>>>>> s
>>>>>>>>>>> (
>>>>>>>>>>> Tr
>>>>>>>>>>> a
>>>>>>>>>>> c
>>>>>>>>>>> eI
>>>>>>>>>>> nterceptor.java:99)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>>> s
>>>>>>>>>>> s
>>>>>>>>>>> o
>>>>>>>>>>> rH
>>>>>>>>>>> e
>>>>>>>>>>> l
>>>>>>>>>>> pe
>>>>>>>>>>> r.java:70)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.DelegateAsyncProcessor.processNext
>>>>>>>>>>> (
>>>>>>>>>>> D
>>>>>>>>>>> e
>>>>>>>>>>> le
>>>>>>>>>>> g
>>>>>>>>>>> a
>>>>>>>>>>> te
>>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.DelegateAsyncProcessor.process(Del
>>>>>>>>>>> e
>>>>>>>>>>> g
>>>>>>>>>>> a
>>>>>>>>>>> te
>>>>>>>>>>> A
>>>>>>>>>>> s
>>>>>>>>>>> yn
>>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.management.InstrumentationProcessor.process(
>>>>>>>>>>> I
>>>>>>>>>>> n
>>>>>>>>>>> s
>>>>>>>>>>> tr
>>>>>>>>>>> u
>>>>>>>>>>> m
>>>>>>>>>>> en
>>>>>>>>>>> tationProcessor.java:68)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>>> s
>>>>>>>>>>> s
>>>>>>>>>>> o
>>>>>>>>>>> rH
>>>>>>>>>>> e
>>>>>>>>>>> l
>>>>>>>>>>> pe
>>>>>>>>>>> r.java:70)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.RedeliveryErrorHandler.processErro
>>>>>>>>>>> r
>>>>>>>>>>> H
>>>>>>>>>>> a
>>>>>>>>>>> nd
>>>>>>>>>>> l
>>>>>>>>>>> e
>>>>>>>>>>> r(
>>>>>>>>>>> RedeliveryErrorHandler.java:290)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.RedeliveryErrorHandler.process(Red
>>>>>>>>>>> e
>>>>>>>>>>> l
>>>>>>>>>>> i
>>>>>>>>>>> ve
>>>>>>>>>>> r
>>>>>>>>>>> y
>>>>>>>>>>> Er
>>>>>>>>>>> rorHandler.java:202)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache
>>>>>>>>>>> .camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>>>>>>> 256)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>>> s
>>>>>>>>>>> s
>>>>>>>>>>> o
>>>>>>>>>>> rH
>>>>>>>>>>> e
>>>>>>>>>>> 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(UnitOf
>>>>>>>>>>> W
>>>>>>>>>>> o
>>>>>>>>>>> r
>>>>>>>>>>> kP
>>>>>>>>>>> r
>>>>>>>>>>> o
>>>>>>>>>>> ce
>>>>>>>>>>> ssor.java:99)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>>> s
>>>>>>>>>>> s
>>>>>>>>>>> o
>>>>>>>>>>> rH
>>>>>>>>>>> e
>>>>>>>>>>> l
>>>>>>>>>>> pe
>>>>>>>>>>> r.java:70)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.DelegateAsyncProcessor.processNext
>>>>>>>>>>> (
>>>>>>>>>>> D
>>>>>>>>>>> e
>>>>>>>>>>> le
>>>>>>>>>>> g
>>>>>>>>>>> a
>>>>>>>>>>> te
>>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.processor.DelegateAsyncProcessor.process(Del
>>>>>>>>>>> e
>>>>>>>>>>> g
>>>>>>>>>>> a
>>>>>>>>>>> te
>>>>>>>>>>> A
>>>>>>>>>>> s
>>>>>>>>>>> yn
>>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.camel.management.InstrumentationProcessor.process(
>>>>>>>>>>> I
>>>>>>>>>>> n
>>>>>>>>>>> s
>>>>>>>>>>> tr
>>>>>>>>>>> u
>>>>>>>>>>> m
>>>>>>>>>>> en
>>>>>>>>>>> tationProcessor.java:68)
>>>>>>>>>>> at
>>>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint
>>>>>>>>>>> $1.call(Came
>>>>>>>>>>> l
>>>>>>>>>>> P
>>>>>>>>>>> r
>>>>>>>>>>> ov
>>>>>>>>>>> i
>>>>>>>>>>> d
>>>>>>>>>>> er
>>>>>>>>>>> Endpoint.java:109)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.servicemix.camel.JbiBinding.runWithCamelContextCla
>>>>>>>>>>> s
>>>>>>>>>>> s
>>>>>>>>>>> L
>>>>>>>>>>> oa
>>>>>>>>>>> d
>>>>>>>>>>> e
>>>>>>>>>>> r(
>>>>>>>>>>> JbiBinding.java:116)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.servicemix.camel.CamelProviderEndpoint.handleActiv
>>>>>>>>>>> e
>>>>>>>>>>> P
>>>>>>>>>>> r
>>>>>>>>>>> ov
>>>>>>>>>>> i
>>>>>>>>>>> d
>>>>>>>>>>> er
>>>>>>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.servicemix.camel.CamelProviderEndpoint.process(Cam
>>>>>>>>>>> e
>>>>>>>>>>> l
>>>>>>>>>>> P
>>>>>>>>>>> ro
>>>>>>>>>>> v
>>>>>>>>>>> i
>>>>>>>>>>> de
>>>>>>>>>>> rEndpoint.java:85)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.servicemix.common.AsyncBaseLifeCycle.doProcess(Asy
>>>>>>>>>>> n
>>>>>>>>>>> c
>>>>>>>>>>> B
>>>>>>>>>>> as
>>>>>>>>>>> e
>>>>>>>>>>> L
>>>>>>>>>>> if
>>>>>>>>>>> eCycle.java:651)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.servicemix.common.AsyncBaseLifeCycle.processExchan
>>>>>>>>>>> g
>>>>>>>>>>> e
>>>>>>>>>>> (
>>>>>>>>>>> As
>>>>>>>>>>> y
>>>>>>>>>>> n
>>>>>>>>>>> cB
>>>>>>>>>>> aseLifeCycle.java:606)
>>>>>>>>>>> at
>>>>>>>>>>> org
>>>>>>>>>>> .apache.servicemix.common.AsyncBaseLifeCycle.processExchan
>>>>>>>>>>> g
>>>>>>>>>>> e
>>>>>>>>>>> I
>>>>>>>>>>> nT
>>>>>>>>>>> x
>>>>>>>>>>> (
>>>>>>>>>>> As
>>>>>>>>>>> yncBaseLifeCycle.java:501)
>>>>>>>>>>> at
>>>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle
>>>>>>>>>>> $2.run(AsyncBa
>>>>>>>>>>> s
>>>>>>>>>>> e
>>>>>>>>>>> L
>>>>>>>>>>> if
>>>>>>>>>>> e
>>>>>>>>>>> C
>>>>>>>>>>> yc
>>>>>>>>>>> le.java:370)
>>>>>>>>>>> at
>>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor
>>>>>>>>>>> $Worker.runTask(Thread
>>>>>>>>>>> P
>>>>>>>>>>> o
>>>>>>>>>>> o
>>>>>>>>>>> lE
>>>>>>>>>>> x
>>>>>>>>>>> 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:freeman.fang@gmail.com]
>>>>>>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>>>>>>> To: users@servicemix.apache.org
>>>>>>>>>>> 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-
>>>>>>>>>>>> enco
>>>>>>>>>>>> u
>>>>>>>>>>>> n
>>>>>>>>>>>> t
>>>>>>>>>>>> er
>>>>>>>>>>>> - 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-
>>>>>>>>>>> encou
>>>>>>>>>>> n
>>>>>>>>>>> t
>>>>>>>>>>> e
>>>>>>>>>>> r- 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: cibsen@fusesource.com
>>>>>>>>>> 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: cibsen@fusesource.com
>>>>>>>>> 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: cibsen@fusesource.com
>>>>>>>> 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: cibsen@fusesource.com
>>>>>> 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
>>>>
>>>
>>>
>>> --
>>> Willem
>>> ----------------------------------
>>> FuseSource
>>> Web: http://www.fusesource.com
>>> Blog: http://willemjiang.blogspot.com (English)
>>> http://jnn.javaeye.com (Chinese)
>>> Twitter: willemjiang
>>>
>>
>>
>> --
>> Willem
>> ----------------------------------
>> FuseSource
>> Web: http://www.fusesource.com
>> Blog: http://willemjiang.blogspot.com (English)
>> http://jnn.javaeye.com (Chinese)
>> Twitter: willemjiang
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
--
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
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
Willem:
Hopefully this will be addressed at some point? Are you suggesting that Servicemix 4 won't support accessing Camel SUs via JBI?
I really would like to use JBI for my application, to take advantage of the NMR. I don't see how I would do that if I deployed the Camel route in a bundle.
I did rebuild the Camel service engine as part of my build from source, so I would expect that everything would pick up the latest version of Camel.
Thanks.
--Scott
-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com]
Sent: Thursday, January 27, 2011 4:06 AM
To: users@servicemix.apache.org
Subject: Re: Large(ish) message issue (CXFBC and Camel)
Hi Scott
I just realize you were using the old JBI stuff.
As you are using ServiceMix 4.x, I suggest you put the camel route into a bundle instead create a Camel Service Engine SU for the route.
As the Camel Service Engine also have a lib which has the camel-core and camel-spring, I'm not sure it cause the issue that you met.
Willem
On 1/27/11 9:49 AM, Scott Came wrote:
> Willem (and list):
>
> I just checked out the smx4 features, nmr, and components source trees (trunk) today and built all three. Servicemix starts and runs fine. I noted that the components are dependent on Camel 2.6.0 (at least it appears that way to me):
>
> 126:servicemix scott$ find system | grep camel system/org/apache/camel
> system/org/apache/camel/camel-core
> system/org/apache/camel/camel-core/2.6-SNAPSHOT
> system/org/apache/camel/camel-core/2.6-SNAPSHOT/camel-core-2.6-SNAPSHO
> T.jar
> system/org/apache/camel/camel-spring
> system/org/apache/camel/camel-spring/2.6-SNAPSHOT
> system/org/apache/camel/camel-spring/2.6-SNAPSHOT/camel-spring-2.6-SNA
> PSHOT.jar
> system/org/apache/camel/karaf
> system/org/apache/camel/karaf/apache-camel
> system/org/apache/camel/karaf/apache-camel/2.6-SNAPSHOT
> system/org/apache/camel/karaf/apache-camel/2.6-SNAPSHOT/apache-camel-2
> .6-SNAPSHOT-features.xml system/org/apache/servicemix/servicemix-camel
> system/org/apache/servicemix/servicemix-camel/2011.01-SNAPSHOT
> system/org/apache/servicemix/servicemix-camel/2011.01-SNAPSHOT/service
> mix-camel-2011.01-SNAPSHOT.jar
>
> and...
>
> karaf@root> osgi:list | grep camel
> [ 68] [Active ] [ ] [ ] [ 60] camel-core (2.6.0.SNAPSHOT)
> [ 75] [Active ] [ ] [ ] [ 60] camel-spring (2.6.0.SNAPSHOT)
> karaf@root> osgi:list | grep Camel
> [ 169] [Active ] [Created ] [ ] [ 60] Apache ServiceMix :: Components :: Camel Service Engine (2011.01.0.SNAPSHOT)
> karaf@root>
>
> However, when I deploy my service assembly and send the larger message in, I see the same behavior as with Camel 2.4 that's build into Fuse ESB 4.3.0-03-00. Do I need to do anything explicit to have the build include the latest version of Camel in which this bug is supposedly fixed?
>
> I also noted that the log messages that Claus suggested I should see are not showing up (grepping the log for AnnotationTypeConverterLoader and DefaultTypeConverter returns no lines, and my log level is set at INFO...) Is this a sign of a problem with my build? I do see the following in the log:
>
> 17:45:52,176 | INFO | rint Extender: 1 | OsgiSpringCamelContext | e.camel.impl.DefaultCamelContext 1293 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Apache Camel 2.6-SNAPSHOT (CamelContext: camel) is starting
> 17:45:52,320 | INFO | rint Extender: 1 | Activator | BundleTypeConverterLoader$Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Found 1 @Converter classes to load
> 17:45:52,324 | INFO | rint Extender: 1 | Activator | BundleTypeConverterLoader$Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Found 1 @Converter classes to load
> 17:45:52,380 | INFO | rint Extender: 1 | Activator | BundleTypeConverterLoader$Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Found 13 @Converter classes to load
>
> Thanks.
> --Scott
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com]
> Sent: Monday, January 24, 2011 10:48 PM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> Hi Scott,
>
> I'm sorry I didn't aware you are using servicemix-camel component (JBI) version. In this case the upgrading will be more complicated.
> You need to updated the servicemix-camel lib with the new version of camel-spring.
>
> Fortunately we just cut Camel 2.6.0 and it will be part of Apache ServiceMix new version very soon. And we are releasing a new version of Fuse ESB 4.3.1 this week.
>
> Willem
>
> On 1/24/11 9:53 AM, Scott Came wrote:
>> Willem:
>>
>> I did my best to understand what you suggested I do, but I'm not confident that I'm doing it right. Here is what I did:
>>
>> -- I shut down servicemix
>>
>> -- I downloaded the jar
>> http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/
>> a
>> pache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-
>> 2
>> 0110118.002228-16.jar
>>
>> -- I extracted the contents of that jar to a temporary directory
>>
>> -- I extracted the contents of the camel-spring-2.4.0-fuse-02-00, and
>> copied its META-INF/MANIFEST.MF file to the META-INF directory of the
>> extracted snapshot jar
>>
>> -- I re-jarred the snapshot
>>
>> -- I deleted the camel-sprint-2.4.0-fuse-02-00.jar from
>> $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>>
>> -- I copied the snapshot jar (with the updated MANIFEST.MF) into
>> $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>>
>> -- I deleted my $SMX_HOME/data directory
>>
>> -- I restarted servicemix
>>
>> After these steps, servicemix seems to start normally. Osgi:list:
>>
>> [ 153] [Active ] [Created ] [ ] [ 60] Apache ServiceMix :: Components :: Camel Service Engine (2010.02.0.fuse-02-00)
>>
>> Jbi:list
>>
>> [Started ] [servicemix-camel ]
>>
>> However, when I deploy my service assembly, I get a stack trace (see attached).
>>
>> Is this sequence of steps what you intended me to try? Any idea what's going wrong and where?
>>
>> Alternatively...is this version of camel-spring already included in
>> some snapshot version of the entire FUSE ESB? If so, would it likely
>> work better for me just to check out the ESB shapshot and build it?
>> If so, are there instructions somewhere for finding the source
>> repository and checking out the snapshot? (I looked at
>> http://fusesource.com/forge/projects/fuseesb/source which says to use
>> Subversion as such: svn co
>> http://fusesource.com/forge/svn/fuseesb/trunk fuseesb; however, when
>> I do, I get "svn: URL 'http://fusesource.com/forge/svn/fuseesb/trunk'
>> doesn't exist".)
>>
>> Either way, I think I can offer some value to the project here by testing the new camel version, but I'm kinda stuck as a newcomer to the platform on some of these issues. Any help you can offer would be much appreciated.
>>
>> Thanks.
>> --Scott
>>
>> -----Original Message-----
>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>> Sent: Thursday, January 20, 2011 10:02 PM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> Yeah, you may need to hack the META-INF/manifest file yourself if you don't want to massage the bundle version complains yourself.
>>
>> The sample way download the snapshot jar and replace the manifest file of camel-spring 2.4.0-fuse-02-00.jar, and place the jar into the $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-01-00, restart the servicemix after deleting the $SMX_HOME/data.
>>
>> Willem
>>
>> On 1/20/11 8:56 PM, Scott Came wrote:
>>> Thanks, Willem, I'll give that a try.
>>>
>>> Again apologies for my newbie questions, but I couldn't find any docs on this question: If I'm to install this component, what do I need to uninstall first to avoid conflicts? I have read things about not having multiple versions of Camel-* going at the same time...
>>>
>>> Also I assume I just download this jar and drop it in the deploy directory...correct?
>>>
>>> Thanks much.
>>> --Scott
>>>
>>> -----Original Message-----
>>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>>> Sent: Wednesday, January 19, 2011 9:36 PM
>>> To: users@servicemix.apache.org
>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>
>>> On 1/19/11 10:15 PM, Claus Ibsen wrote:
>>>> On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<sc...@search.org> wrote:
>>>>> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From
>>>>> the log messages I included in my message yesterday, it looks like
>>>>> my install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log
>>>>> message:>>>> 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.)
>>>>>
>>>>> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
>>>>>
>>>>> If not, is there something else that's causing the type converters not to get loaded?
>>>>>
>>>>
>>>> Its this bug which was fixed dec-20-2010
>>>> http://fusesource.com/issues/browse/MR-392
>>>>
>>>> And -03 hasn't been released yet.
>>> Maybe you can consider to try out the camel-spring 2.4.0-fuse-SNAPSHOT[1] which has the fix?
>>>
>>> [1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/
>>> o
>>> r
>>> g/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-f
>>> u
>>> s
>>> e-20110118.002228-16.jar
>>>
>>>>
>>>>
>>>>> Thanks for all your help...
>>>>> --Scott
>>>>>
>>>>> -----Original Message-----
>>>>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>> Sent: Wednesday, January 19, 2011 5:14 AM
>>>>> To: users@servicemix.apache.org
>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>
>>>>> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<sc...@search.org> 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:willem.jiang@gmail.com]
>>>>>> Sent: Wednesday, January 19, 2011 2:02 AM
>>>>>> To: users@servicemix.apache.org
>>>>>> 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:scott.came@search.org]
>>>>>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>>>>>> To: users@servicemix.apache.org
>>>>>>> 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:claus.ibsen@gmail.com]
>>>>>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>>>>>> To: users@servicemix.apache.org
>>>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>>>
>>>>>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>>>>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>>>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>>>>>> To: users@servicemix.apache.org
>>>>>>>>> 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<sc...@search.org> 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.
>>>>>>>>>> ja
>>>>>>>>>> v
>>>>>>>>>> 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:
>>>>>>>>>> 1
>>>>>>>>>> 0
>>>>>>>>>> 48
>>>>>>>>>> )
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.soap.util.stax.FragmentStreamReader.nex
>>>>>>>>>> t
>>>>>>>>>> (
>>>>>>>>>> F
>>>>>>>>>> ra
>>>>>>>>>> g
>>>>>>>>>> m
>>>>>>>>>> en
>>>>>>>>>> tStreamReader.java:68)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(
>>>>>>>>>> S
>>>>>>>>>> t
>>>>>>>>>> a
>>>>>>>>>> xJ
>>>>>>>>>> b
>>>>>>>>>> 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(Message
>>>>>>>>>> S
>>>>>>>>>> u
>>>>>>>>>> p
>>>>>>>>>> po
>>>>>>>>>> r
>>>>>>>>>> t
>>>>>>>>>> .j
>>>>>>>>>> ava:103)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(Conve
>>>>>>>>>> r
>>>>>>>>>> t
>>>>>>>>>> B
>>>>>>>>>> od
>>>>>>>>>> y
>>>>>>>>>> P
>>>>>>>>>> ro
>>>>>>>>>> cessor.java:57)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$P
>>>>>>>>>> r
>>>>>>>>>> o
>>>>>>>>>> c
>>>>>>>>>> es
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rT
>>>>>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>> s
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> pe
>>>>>>>>>> r.java:70)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext
>>>>>>>>>> (
>>>>>>>>>> D
>>>>>>>>>> e
>>>>>>>>>> le
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Del
>>>>>>>>>> e
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> A
>>>>>>>>>> s
>>>>>>>>>> yn
>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(
>>>>>>>>>> I
>>>>>>>>>> n
>>>>>>>>>> s
>>>>>>>>>> tr
>>>>>>>>>> u
>>>>>>>>>> m
>>>>>>>>>> en
>>>>>>>>>> tationProcessor.java:68)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>> s
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> pe
>>>>>>>>>> r.java:70)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext
>>>>>>>>>> (
>>>>>>>>>> D
>>>>>>>>>> e
>>>>>>>>>> le
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Del
>>>>>>>>>> e
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> A
>>>>>>>>>> s
>>>>>>>>>> yn
>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.proce
>>>>>>>>>> s
>>>>>>>>>> s
>>>>>>>>>> (
>>>>>>>>>> Tr
>>>>>>>>>> a
>>>>>>>>>> c
>>>>>>>>>> eI
>>>>>>>>>> nterceptor.java:99)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>> s
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> pe
>>>>>>>>>> r.java:70)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext
>>>>>>>>>> (
>>>>>>>>>> D
>>>>>>>>>> e
>>>>>>>>>> le
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Del
>>>>>>>>>> e
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> A
>>>>>>>>>> s
>>>>>>>>>> yn
>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(
>>>>>>>>>> I
>>>>>>>>>> n
>>>>>>>>>> s
>>>>>>>>>> tr
>>>>>>>>>> u
>>>>>>>>>> m
>>>>>>>>>> en
>>>>>>>>>> tationProcessor.java:68)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>> s
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> pe
>>>>>>>>>> r.java:70)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processErro
>>>>>>>>>> r
>>>>>>>>>> H
>>>>>>>>>> a
>>>>>>>>>> nd
>>>>>>>>>> l
>>>>>>>>>> e
>>>>>>>>>> r(
>>>>>>>>>> RedeliveryErrorHandler.java:290)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Red
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> i
>>>>>>>>>> ve
>>>>>>>>>> r
>>>>>>>>>> y
>>>>>>>>>> Er
>>>>>>>>>> rorHandler.java:202)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>>>>>> 256)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>> s
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> 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(UnitOf
>>>>>>>>>> W
>>>>>>>>>> o
>>>>>>>>>> r
>>>>>>>>>> kP
>>>>>>>>>> r
>>>>>>>>>> o
>>>>>>>>>> ce
>>>>>>>>>> ssor.java:99)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProce
>>>>>>>>>> s
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> pe
>>>>>>>>>> r.java:70)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext
>>>>>>>>>> (
>>>>>>>>>> D
>>>>>>>>>> e
>>>>>>>>>> le
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Del
>>>>>>>>>> e
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> A
>>>>>>>>>> s
>>>>>>>>>> yn
>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(
>>>>>>>>>> I
>>>>>>>>>> n
>>>>>>>>>> s
>>>>>>>>>> tr
>>>>>>>>>> u
>>>>>>>>>> m
>>>>>>>>>> en
>>>>>>>>>> tationProcessor.java:68)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(Came
>>>>>>>>>> l
>>>>>>>>>> P
>>>>>>>>>> r
>>>>>>>>>> ov
>>>>>>>>>> i
>>>>>>>>>> d
>>>>>>>>>> er
>>>>>>>>>> Endpoint.java:109)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextCla
>>>>>>>>>> s
>>>>>>>>>> s
>>>>>>>>>> L
>>>>>>>>>> oa
>>>>>>>>>> d
>>>>>>>>>> e
>>>>>>>>>> r(
>>>>>>>>>> JbiBinding.java:116)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActiv
>>>>>>>>>> e
>>>>>>>>>> P
>>>>>>>>>> r
>>>>>>>>>> ov
>>>>>>>>>> i
>>>>>>>>>> d
>>>>>>>>>> er
>>>>>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(Cam
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> P
>>>>>>>>>> ro
>>>>>>>>>> v
>>>>>>>>>> i
>>>>>>>>>> de
>>>>>>>>>> rEndpoint.java:85)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(Asy
>>>>>>>>>> n
>>>>>>>>>> c
>>>>>>>>>> B
>>>>>>>>>> as
>>>>>>>>>> e
>>>>>>>>>> L
>>>>>>>>>> if
>>>>>>>>>> eCycle.java:651)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchan
>>>>>>>>>> g
>>>>>>>>>> e
>>>>>>>>>> (
>>>>>>>>>> As
>>>>>>>>>> y
>>>>>>>>>> n
>>>>>>>>>> cB
>>>>>>>>>> aseLifeCycle.java:606)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchan
>>>>>>>>>> g
>>>>>>>>>> e
>>>>>>>>>> I
>>>>>>>>>> nT
>>>>>>>>>> x
>>>>>>>>>> (
>>>>>>>>>> As
>>>>>>>>>> yncBaseLifeCycle.java:501)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBa
>>>>>>>>>> s
>>>>>>>>>> e
>>>>>>>>>> L
>>>>>>>>>> if
>>>>>>>>>> e
>>>>>>>>>> C
>>>>>>>>>> yc
>>>>>>>>>> le.java:370)
>>>>>>>>>> at
>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Thread
>>>>>>>>>> P
>>>>>>>>>> o
>>>>>>>>>> o
>>>>>>>>>> lE
>>>>>>>>>> x
>>>>>>>>>> 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:freeman.fang@gmail.com]
>>>>>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>>>>>> To: users@servicemix.apache.org
>>>>>>>>>> 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-enco
>>>>>>>>>>> u
>>>>>>>>>>> n
>>>>>>>>>>> t
>>>>>>>>>>> er
>>>>>>>>>>> - 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-encou
>>>>>>>>>> n
>>>>>>>>>> t
>>>>>>>>>> e
>>>>>>>>>> r- 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: cibsen@fusesource.com
>>>>>>>>> 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: cibsen@fusesource.com
>>>>>>>> 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: cibsen@fusesource.com
>>>>>>> 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: cibsen@fusesource.com
>>>>> 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
>>>
>>
>>
>> --
>> Willem
>> ----------------------------------
>> FuseSource
>> Web: http://www.fusesource.com
>> Blog: http://willemjiang.blogspot.com (English)
>> http://jnn.javaeye.com (Chinese)
>> Twitter: willemjiang
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Willem Jiang <wi...@gmail.com>.
Hi Scott
I just realize you were using the old JBI stuff.
As you are using ServiceMix 4.x, I suggest you put the camel route into
a bundle instead create a Camel Service Engine SU for the route.
As the Camel Service Engine also have a lib which has the camel-core and
camel-spring, I'm not sure it cause the issue that you met.
Willem
On 1/27/11 9:49 AM, Scott Came wrote:
> Willem (and list):
>
> I just checked out the smx4 features, nmr, and components source trees (trunk) today and built all three. Servicemix starts and runs fine. I noted that the components are dependent on Camel 2.6.0 (at least it appears that way to me):
>
> 126:servicemix scott$ find system | grep camel
> system/org/apache/camel
> system/org/apache/camel/camel-core
> system/org/apache/camel/camel-core/2.6-SNAPSHOT
> system/org/apache/camel/camel-core/2.6-SNAPSHOT/camel-core-2.6-SNAPSHOT.jar
> system/org/apache/camel/camel-spring
> system/org/apache/camel/camel-spring/2.6-SNAPSHOT
> system/org/apache/camel/camel-spring/2.6-SNAPSHOT/camel-spring-2.6-SNAPSHOT.jar
> system/org/apache/camel/karaf
> system/org/apache/camel/karaf/apache-camel
> system/org/apache/camel/karaf/apache-camel/2.6-SNAPSHOT
> system/org/apache/camel/karaf/apache-camel/2.6-SNAPSHOT/apache-camel-2.6-SNAPSHOT-features.xml
> system/org/apache/servicemix/servicemix-camel
> system/org/apache/servicemix/servicemix-camel/2011.01-SNAPSHOT
> system/org/apache/servicemix/servicemix-camel/2011.01-SNAPSHOT/servicemix-camel-2011.01-SNAPSHOT.jar
>
> and...
>
> karaf@root> osgi:list | grep camel
> [ 68] [Active ] [ ] [ ] [ 60] camel-core (2.6.0.SNAPSHOT)
> [ 75] [Active ] [ ] [ ] [ 60] camel-spring (2.6.0.SNAPSHOT)
> karaf@root> osgi:list | grep Camel
> [ 169] [Active ] [Created ] [ ] [ 60] Apache ServiceMix :: Components :: Camel Service Engine (2011.01.0.SNAPSHOT)
> karaf@root>
>
> However, when I deploy my service assembly and send the larger message in, I see the same behavior as with Camel 2.4 that's build into Fuse ESB 4.3.0-03-00. Do I need to do anything explicit to have the build include the latest version of Camel in which this bug is supposedly fixed?
>
> I also noted that the log messages that Claus suggested I should see are not showing up (grepping the log for AnnotationTypeConverterLoader and DefaultTypeConverter returns no lines, and my log level is set at INFO...) Is this a sign of a problem with my build? I do see the following in the log:
>
> 17:45:52,176 | INFO | rint Extender: 1 | OsgiSpringCamelContext | e.camel.impl.DefaultCamelContext 1293 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Apache Camel 2.6-SNAPSHOT (CamelContext: camel) is starting
> 17:45:52,320 | INFO | rint Extender: 1 | Activator | BundleTypeConverterLoader$Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Found 1 @Converter classes to load
> 17:45:52,324 | INFO | rint Extender: 1 | Activator | BundleTypeConverterLoader$Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Found 1 @Converter classes to load
> 17:45:52,380 | INFO | rint Extender: 1 | Activator | BundleTypeConverterLoader$Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Found 13 @Converter classes to load
>
> Thanks.
> --Scott
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com]
> Sent: Monday, January 24, 2011 10:48 PM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> Hi Scott,
>
> I'm sorry I didn't aware you are using servicemix-camel component (JBI) version. In this case the upgrading will be more complicated.
> You need to updated the servicemix-camel lib with the new version of camel-spring.
>
> Fortunately we just cut Camel 2.6.0 and it will be part of Apache ServiceMix new version very soon. And we are releasing a new version of Fuse ESB 4.3.1 this week.
>
> Willem
>
> On 1/24/11 9:53 AM, Scott Came wrote:
>> Willem:
>>
>> I did my best to understand what you suggested I do, but I'm not confident that I'm doing it right. Here is what I did:
>>
>> -- I shut down servicemix
>>
>> -- I downloaded the jar
>> http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/a
>> pache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-2
>> 0110118.002228-16.jar
>>
>> -- I extracted the contents of that jar to a temporary directory
>>
>> -- I extracted the contents of the camel-spring-2.4.0-fuse-02-00, and
>> copied its META-INF/MANIFEST.MF file to the META-INF directory of the
>> extracted snapshot jar
>>
>> -- I re-jarred the snapshot
>>
>> -- I deleted the camel-sprint-2.4.0-fuse-02-00.jar from
>> $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>>
>> -- I copied the snapshot jar (with the updated MANIFEST.MF) into
>> $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>>
>> -- I deleted my $SMX_HOME/data directory
>>
>> -- I restarted servicemix
>>
>> After these steps, servicemix seems to start normally. Osgi:list:
>>
>> [ 153] [Active ] [Created ] [ ] [ 60] Apache ServiceMix :: Components :: Camel Service Engine (2010.02.0.fuse-02-00)
>>
>> Jbi:list
>>
>> [Started ] [servicemix-camel ]
>>
>> However, when I deploy my service assembly, I get a stack trace (see attached).
>>
>> Is this sequence of steps what you intended me to try? Any idea what's going wrong and where?
>>
>> Alternatively...is this version of camel-spring already included in
>> some snapshot version of the entire FUSE ESB? If so, would it likely
>> work better for me just to check out the ESB shapshot and build it?
>> If so, are there instructions somewhere for finding the source
>> repository and checking out the snapshot? (I looked at
>> http://fusesource.com/forge/projects/fuseesb/source which says to use
>> Subversion as such: svn co
>> http://fusesource.com/forge/svn/fuseesb/trunk fuseesb; however, when
>> I do, I get "svn: URL 'http://fusesource.com/forge/svn/fuseesb/trunk'
>> doesn't exist".)
>>
>> Either way, I think I can offer some value to the project here by testing the new camel version, but I'm kinda stuck as a newcomer to the platform on some of these issues. Any help you can offer would be much appreciated.
>>
>> Thanks.
>> --Scott
>>
>> -----Original Message-----
>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>> Sent: Thursday, January 20, 2011 10:02 PM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> Yeah, you may need to hack the META-INF/manifest file yourself if you don't want to massage the bundle version complains yourself.
>>
>> The sample way download the snapshot jar and replace the manifest file of camel-spring 2.4.0-fuse-02-00.jar, and place the jar into the $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-01-00, restart the servicemix after deleting the $SMX_HOME/data.
>>
>> Willem
>>
>> On 1/20/11 8:56 PM, Scott Came wrote:
>>> Thanks, Willem, I'll give that a try.
>>>
>>> Again apologies for my newbie questions, but I couldn't find any docs on this question: If I'm to install this component, what do I need to uninstall first to avoid conflicts? I have read things about not having multiple versions of Camel-* going at the same time...
>>>
>>> Also I assume I just download this jar and drop it in the deploy directory...correct?
>>>
>>> Thanks much.
>>> --Scott
>>>
>>> -----Original Message-----
>>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>>> Sent: Wednesday, January 19, 2011 9:36 PM
>>> To: users@servicemix.apache.org
>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>
>>> On 1/19/11 10:15 PM, Claus Ibsen wrote:
>>>> On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<sc...@search.org> wrote:
>>>>> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From
>>>>> the log messages I included in my message yesterday, it looks like
>>>>> my install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log
>>>>> message:>>>> 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.)
>>>>>
>>>>> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
>>>>>
>>>>> If not, is there something else that's causing the type converters not to get loaded?
>>>>>
>>>>
>>>> Its this bug which was fixed dec-20-2010
>>>> http://fusesource.com/issues/browse/MR-392
>>>>
>>>> And -03 hasn't been released yet.
>>> Maybe you can consider to try out the camel-spring 2.4.0-fuse-SNAPSHOT[1] which has the fix?
>>>
>>> [1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/o
>>> r
>>> g/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fu
>>> s
>>> e-20110118.002228-16.jar
>>>
>>>>
>>>>
>>>>> Thanks for all your help...
>>>>> --Scott
>>>>>
>>>>> -----Original Message-----
>>>>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>>> Sent: Wednesday, January 19, 2011 5:14 AM
>>>>> To: users@servicemix.apache.org
>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>
>>>>> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<sc...@search.org> 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:willem.jiang@gmail.com]
>>>>>> Sent: Wednesday, January 19, 2011 2:02 AM
>>>>>> To: users@servicemix.apache.org
>>>>>> 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:scott.came@search.org]
>>>>>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>>>>>> To: users@servicemix.apache.org
>>>>>>> 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:claus.ibsen@gmail.com]
>>>>>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>>>>>> To: users@servicemix.apache.org
>>>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>>>
>>>>>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>>>>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>>>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>>>>>> To: users@servicemix.apache.org
>>>>>>>>> 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<sc...@search.org> 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.
>>>>>>>>>> ja
>>>>>>>>>> v
>>>>>>>>>> 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:
>>>>>>>>>> 1
>>>>>>>>>> 0
>>>>>>>>>> 48
>>>>>>>>>> )
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.soap.util.stax.FragmentStreamReader.next
>>>>>>>>>> (
>>>>>>>>>> F
>>>>>>>>>> ra
>>>>>>>>>> g
>>>>>>>>>> m
>>>>>>>>>> en
>>>>>>>>>> tStreamReader.java:68)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(S
>>>>>>>>>> t
>>>>>>>>>> a
>>>>>>>>>> xJ
>>>>>>>>>> b
>>>>>>>>>> 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(MessageS
>>>>>>>>>> u
>>>>>>>>>> p
>>>>>>>>>> po
>>>>>>>>>> r
>>>>>>>>>> t
>>>>>>>>>> .j
>>>>>>>>>> ava:103)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(Conver
>>>>>>>>>> t
>>>>>>>>>> B
>>>>>>>>>> od
>>>>>>>>>> y
>>>>>>>>>> P
>>>>>>>>>> ro
>>>>>>>>>> cessor.java:57)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Pr
>>>>>>>>>> o
>>>>>>>>>> c
>>>>>>>>>> es
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rT
>>>>>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> pe
>>>>>>>>>> r.java:70)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>>> D
>>>>>>>>>> e
>>>>>>>>>> le
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> A
>>>>>>>>>> s
>>>>>>>>>> yn
>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(I
>>>>>>>>>> n
>>>>>>>>>> s
>>>>>>>>>> tr
>>>>>>>>>> u
>>>>>>>>>> m
>>>>>>>>>> en
>>>>>>>>>> tationProcessor.java:68)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> pe
>>>>>>>>>> r.java:70)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>>> D
>>>>>>>>>> e
>>>>>>>>>> le
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> A
>>>>>>>>>> s
>>>>>>>>>> yn
>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.proces
>>>>>>>>>> s
>>>>>>>>>> (
>>>>>>>>>> Tr
>>>>>>>>>> a
>>>>>>>>>> c
>>>>>>>>>> eI
>>>>>>>>>> nterceptor.java:99)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> pe
>>>>>>>>>> r.java:70)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>>> D
>>>>>>>>>> e
>>>>>>>>>> le
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> A
>>>>>>>>>> s
>>>>>>>>>> yn
>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(I
>>>>>>>>>> n
>>>>>>>>>> s
>>>>>>>>>> tr
>>>>>>>>>> u
>>>>>>>>>> m
>>>>>>>>>> en
>>>>>>>>>> tationProcessor.java:68)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> pe
>>>>>>>>>> r.java:70)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processError
>>>>>>>>>> H
>>>>>>>>>> a
>>>>>>>>>> nd
>>>>>>>>>> l
>>>>>>>>>> e
>>>>>>>>>> r(
>>>>>>>>>> RedeliveryErrorHandler.java:290)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Rede
>>>>>>>>>> l
>>>>>>>>>> i
>>>>>>>>>> ve
>>>>>>>>>> r
>>>>>>>>>> y
>>>>>>>>>> Er
>>>>>>>>>> rorHandler.java:202)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>>>>>> 256)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> 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(UnitOfW
>>>>>>>>>> o
>>>>>>>>>> r
>>>>>>>>>> kP
>>>>>>>>>> r
>>>>>>>>>> o
>>>>>>>>>> ce
>>>>>>>>>> ssor.java:99)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>>> s
>>>>>>>>>> o
>>>>>>>>>> rH
>>>>>>>>>> e
>>>>>>>>>> l
>>>>>>>>>> pe
>>>>>>>>>> r.java:70)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>>> D
>>>>>>>>>> e
>>>>>>>>>> le
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>>> g
>>>>>>>>>> a
>>>>>>>>>> te
>>>>>>>>>> A
>>>>>>>>>> s
>>>>>>>>>> yn
>>>>>>>>>> cProcessor.java:89)
>>>>>>>>>> at
>>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(I
>>>>>>>>>> n
>>>>>>>>>> s
>>>>>>>>>> tr
>>>>>>>>>> u
>>>>>>>>>> m
>>>>>>>>>> en
>>>>>>>>>> tationProcessor.java:68)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(Camel
>>>>>>>>>> P
>>>>>>>>>> r
>>>>>>>>>> ov
>>>>>>>>>> i
>>>>>>>>>> d
>>>>>>>>>> er
>>>>>>>>>> Endpoint.java:109)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClas
>>>>>>>>>> s
>>>>>>>>>> L
>>>>>>>>>> oa
>>>>>>>>>> d
>>>>>>>>>> e
>>>>>>>>>> r(
>>>>>>>>>> JbiBinding.java:116)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActive
>>>>>>>>>> P
>>>>>>>>>> r
>>>>>>>>>> ov
>>>>>>>>>> i
>>>>>>>>>> d
>>>>>>>>>> er
>>>>>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(Came
>>>>>>>>>> l
>>>>>>>>>> P
>>>>>>>>>> ro
>>>>>>>>>> v
>>>>>>>>>> i
>>>>>>>>>> de
>>>>>>>>>> rEndpoint.java:85)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(Asyn
>>>>>>>>>> c
>>>>>>>>>> B
>>>>>>>>>> as
>>>>>>>>>> e
>>>>>>>>>> L
>>>>>>>>>> if
>>>>>>>>>> eCycle.java:651)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchang
>>>>>>>>>> e
>>>>>>>>>> (
>>>>>>>>>> As
>>>>>>>>>> y
>>>>>>>>>> n
>>>>>>>>>> cB
>>>>>>>>>> aseLifeCycle.java:606)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchang
>>>>>>>>>> e
>>>>>>>>>> I
>>>>>>>>>> nT
>>>>>>>>>> x
>>>>>>>>>> (
>>>>>>>>>> As
>>>>>>>>>> yncBaseLifeCycle.java:501)
>>>>>>>>>> at
>>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBas
>>>>>>>>>> e
>>>>>>>>>> L
>>>>>>>>>> if
>>>>>>>>>> e
>>>>>>>>>> C
>>>>>>>>>> yc
>>>>>>>>>> le.java:370)
>>>>>>>>>> at
>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadP
>>>>>>>>>> o
>>>>>>>>>> o
>>>>>>>>>> lE
>>>>>>>>>> x
>>>>>>>>>> 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:freeman.fang@gmail.com]
>>>>>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>>>>>> To: users@servicemix.apache.org
>>>>>>>>>> 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-encou
>>>>>>>>>>> n
>>>>>>>>>>> t
>>>>>>>>>>> er
>>>>>>>>>>> - 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-encoun
>>>>>>>>>> t
>>>>>>>>>> e
>>>>>>>>>> r- 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: cibsen@fusesource.com
>>>>>>>>> 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: cibsen@fusesource.com
>>>>>>>> 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: cibsen@fusesource.com
>>>>>>> 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: cibsen@fusesource.com
>>>>> 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
>>>
>>
>>
>> --
>> Willem
>> ----------------------------------
>> FuseSource
>> Web: http://www.fusesource.com
>> Blog: http://willemjiang.blogspot.com (English)
>> http://jnn.javaeye.com (Chinese)
>> Twitter: willemjiang
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
Thanks, Willem, I'll watch for these new versions and try the out when they're ready.
-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com]
Sent: Monday, January 24, 2011 10:48 PM
To: users@servicemix.apache.org
Subject: Re: Large(ish) message issue (CXFBC and Camel)
Hi Scott,
I'm sorry I didn't aware you are using servicemix-camel component (JBI) version. In this case the upgrading will be more complicated.
You need to updated the servicemix-camel lib with the new version of camel-spring.
Fortunately we just cut Camel 2.6.0 and it will be part of Apache ServiceMix new version very soon. And we are releasing a new version of Fuse ESB 4.3.1 this week.
Willem
On 1/24/11 9:53 AM, Scott Came wrote:
> Willem:
>
> I did my best to understand what you suggested I do, but I'm not confident that I'm doing it right. Here is what I did:
>
> -- I shut down servicemix
>
> -- I downloaded the jar
> http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/a
> pache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-2
> 0110118.002228-16.jar
>
> -- I extracted the contents of that jar to a temporary directory
>
> -- I extracted the contents of the camel-spring-2.4.0-fuse-02-00, and
> copied its META-INF/MANIFEST.MF file to the META-INF directory of the
> extracted snapshot jar
>
> -- I re-jarred the snapshot
>
> -- I deleted the camel-sprint-2.4.0-fuse-02-00.jar from
> $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>
> -- I copied the snapshot jar (with the updated MANIFEST.MF) into
> $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>
> -- I deleted my $SMX_HOME/data directory
>
> -- I restarted servicemix
>
> After these steps, servicemix seems to start normally. Osgi:list:
>
> [ 153] [Active ] [Created ] [ ] [ 60] Apache ServiceMix :: Components :: Camel Service Engine (2010.02.0.fuse-02-00)
>
> Jbi:list
>
> [Started ] [servicemix-camel ]
>
> However, when I deploy my service assembly, I get a stack trace (see attached).
>
> Is this sequence of steps what you intended me to try? Any idea what's going wrong and where?
>
> Alternatively...is this version of camel-spring already included in
> some snapshot version of the entire FUSE ESB? If so, would it likely
> work better for me just to check out the ESB shapshot and build it?
> If so, are there instructions somewhere for finding the source
> repository and checking out the snapshot? (I looked at
> http://fusesource.com/forge/projects/fuseesb/source which says to use
> Subversion as such: svn co
> http://fusesource.com/forge/svn/fuseesb/trunk fuseesb; however, when
> I do, I get "svn: URL 'http://fusesource.com/forge/svn/fuseesb/trunk'
> doesn't exist".)
>
> Either way, I think I can offer some value to the project here by testing the new camel version, but I'm kinda stuck as a newcomer to the platform on some of these issues. Any help you can offer would be much appreciated.
>
> Thanks.
> --Scott
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com]
> Sent: Thursday, January 20, 2011 10:02 PM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> Yeah, you may need to hack the META-INF/manifest file yourself if you don't want to massage the bundle version complains yourself.
>
> The sample way download the snapshot jar and replace the manifest file of camel-spring 2.4.0-fuse-02-00.jar, and place the jar into the $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-01-00, restart the servicemix after deleting the $SMX_HOME/data.
>
> Willem
>
> On 1/20/11 8:56 PM, Scott Came wrote:
>> Thanks, Willem, I'll give that a try.
>>
>> Again apologies for my newbie questions, but I couldn't find any docs on this question: If I'm to install this component, what do I need to uninstall first to avoid conflicts? I have read things about not having multiple versions of Camel-* going at the same time...
>>
>> Also I assume I just download this jar and drop it in the deploy directory...correct?
>>
>> Thanks much.
>> --Scott
>>
>> -----Original Message-----
>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>> Sent: Wednesday, January 19, 2011 9:36 PM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> On 1/19/11 10:15 PM, Claus Ibsen wrote:
>>> On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<sc...@search.org> wrote:
>>>> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From
>>>> the log messages I included in my message yesterday, it looks like
>>>> my install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log
>>>> message:>>>> 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.)
>>>>
>>>> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
>>>>
>>>> If not, is there something else that's causing the type converters not to get loaded?
>>>>
>>>
>>> Its this bug which was fixed dec-20-2010
>>> http://fusesource.com/issues/browse/MR-392
>>>
>>> And -03 hasn't been released yet.
>> Maybe you can consider to try out the camel-spring 2.4.0-fuse-SNAPSHOT[1] which has the fix?
>>
>> [1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/o
>> r
>> g/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fu
>> s
>> e-20110118.002228-16.jar
>>
>>>
>>>
>>>> Thanks for all your help...
>>>> --Scott
>>>>
>>>> -----Original Message-----
>>>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>> Sent: Wednesday, January 19, 2011 5:14 AM
>>>> To: users@servicemix.apache.org
>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>
>>>> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<sc...@search.org> 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:willem.jiang@gmail.com]
>>>>> Sent: Wednesday, January 19, 2011 2:02 AM
>>>>> To: users@servicemix.apache.org
>>>>> 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:scott.came@search.org]
>>>>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>>>>> To: users@servicemix.apache.org
>>>>>> 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:claus.ibsen@gmail.com]
>>>>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>>>>> To: users@servicemix.apache.org
>>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>>
>>>>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>>>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>>>>> To: users@servicemix.apache.org
>>>>>>>> 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<sc...@search.org> 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.
>>>>>>>>> ja
>>>>>>>>> v
>>>>>>>>> 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:
>>>>>>>>> 1
>>>>>>>>> 0
>>>>>>>>> 48
>>>>>>>>> )
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.soap.util.stax.FragmentStreamReader.next
>>>>>>>>> (
>>>>>>>>> F
>>>>>>>>> ra
>>>>>>>>> g
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tStreamReader.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(S
>>>>>>>>> t
>>>>>>>>> a
>>>>>>>>> xJ
>>>>>>>>> b
>>>>>>>>> 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(MessageS
>>>>>>>>> u
>>>>>>>>> p
>>>>>>>>> po
>>>>>>>>> r
>>>>>>>>> t
>>>>>>>>> .j
>>>>>>>>> ava:103)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(Conver
>>>>>>>>> t
>>>>>>>>> B
>>>>>>>>> od
>>>>>>>>> y
>>>>>>>>> P
>>>>>>>>> ro
>>>>>>>>> cessor.java:57)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Pr
>>>>>>>>> o
>>>>>>>>> c
>>>>>>>>> es
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rT
>>>>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>> D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(I
>>>>>>>>> n
>>>>>>>>> s
>>>>>>>>> tr
>>>>>>>>> u
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tationProcessor.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>> D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.proces
>>>>>>>>> s
>>>>>>>>> (
>>>>>>>>> Tr
>>>>>>>>> a
>>>>>>>>> c
>>>>>>>>> eI
>>>>>>>>> nterceptor.java:99)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>> D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(I
>>>>>>>>> n
>>>>>>>>> s
>>>>>>>>> tr
>>>>>>>>> u
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tationProcessor.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processError
>>>>>>>>> H
>>>>>>>>> a
>>>>>>>>> nd
>>>>>>>>> l
>>>>>>>>> e
>>>>>>>>> r(
>>>>>>>>> RedeliveryErrorHandler.java:290)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Rede
>>>>>>>>> l
>>>>>>>>> i
>>>>>>>>> ve
>>>>>>>>> r
>>>>>>>>> y
>>>>>>>>> Er
>>>>>>>>> rorHandler.java:202)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>>>>> 256)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> 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(UnitOfW
>>>>>>>>> o
>>>>>>>>> r
>>>>>>>>> kP
>>>>>>>>> r
>>>>>>>>> o
>>>>>>>>> ce
>>>>>>>>> ssor.java:99)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>> D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(I
>>>>>>>>> n
>>>>>>>>> s
>>>>>>>>> tr
>>>>>>>>> u
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tationProcessor.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(Camel
>>>>>>>>> P
>>>>>>>>> r
>>>>>>>>> ov
>>>>>>>>> i
>>>>>>>>> d
>>>>>>>>> er
>>>>>>>>> Endpoint.java:109)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClas
>>>>>>>>> s
>>>>>>>>> L
>>>>>>>>> oa
>>>>>>>>> d
>>>>>>>>> e
>>>>>>>>> r(
>>>>>>>>> JbiBinding.java:116)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActive
>>>>>>>>> P
>>>>>>>>> r
>>>>>>>>> ov
>>>>>>>>> i
>>>>>>>>> d
>>>>>>>>> er
>>>>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(Came
>>>>>>>>> l
>>>>>>>>> P
>>>>>>>>> ro
>>>>>>>>> v
>>>>>>>>> i
>>>>>>>>> de
>>>>>>>>> rEndpoint.java:85)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(Asyn
>>>>>>>>> c
>>>>>>>>> B
>>>>>>>>> as
>>>>>>>>> e
>>>>>>>>> L
>>>>>>>>> if
>>>>>>>>> eCycle.java:651)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchang
>>>>>>>>> e
>>>>>>>>> (
>>>>>>>>> As
>>>>>>>>> y
>>>>>>>>> n
>>>>>>>>> cB
>>>>>>>>> aseLifeCycle.java:606)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchang
>>>>>>>>> e
>>>>>>>>> I
>>>>>>>>> nT
>>>>>>>>> x
>>>>>>>>> (
>>>>>>>>> As
>>>>>>>>> yncBaseLifeCycle.java:501)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBas
>>>>>>>>> e
>>>>>>>>> L
>>>>>>>>> if
>>>>>>>>> e
>>>>>>>>> C
>>>>>>>>> yc
>>>>>>>>> le.java:370)
>>>>>>>>> at
>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadP
>>>>>>>>> o
>>>>>>>>> o
>>>>>>>>> lE
>>>>>>>>> x
>>>>>>>>> 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:freeman.fang@gmail.com]
>>>>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>>>>> To: users@servicemix.apache.org
>>>>>>>>> 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-encou
>>>>>>>>>> n
>>>>>>>>>> t
>>>>>>>>>> er
>>>>>>>>>> - 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-encoun
>>>>>>>>> t
>>>>>>>>> e
>>>>>>>>> r- 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: cibsen@fusesource.com
>>>>>>>> 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: cibsen@fusesource.com
>>>>>>> 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: cibsen@fusesource.com
>>>>>> 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: cibsen@fusesource.com
>>>> 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
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
Willem (and list):
I just checked out the smx4 features, nmr, and components source trees (trunk) today and built all three. Servicemix starts and runs fine. I noted that the components are dependent on Camel 2.6.0 (at least it appears that way to me):
126:servicemix scott$ find system | grep camel
system/org/apache/camel
system/org/apache/camel/camel-core
system/org/apache/camel/camel-core/2.6-SNAPSHOT
system/org/apache/camel/camel-core/2.6-SNAPSHOT/camel-core-2.6-SNAPSHOT.jar
system/org/apache/camel/camel-spring
system/org/apache/camel/camel-spring/2.6-SNAPSHOT
system/org/apache/camel/camel-spring/2.6-SNAPSHOT/camel-spring-2.6-SNAPSHOT.jar
system/org/apache/camel/karaf
system/org/apache/camel/karaf/apache-camel
system/org/apache/camel/karaf/apache-camel/2.6-SNAPSHOT
system/org/apache/camel/karaf/apache-camel/2.6-SNAPSHOT/apache-camel-2.6-SNAPSHOT-features.xml
system/org/apache/servicemix/servicemix-camel
system/org/apache/servicemix/servicemix-camel/2011.01-SNAPSHOT
system/org/apache/servicemix/servicemix-camel/2011.01-SNAPSHOT/servicemix-camel-2011.01-SNAPSHOT.jar
and...
karaf@root> osgi:list | grep camel
[ 68] [Active ] [ ] [ ] [ 60] camel-core (2.6.0.SNAPSHOT)
[ 75] [Active ] [ ] [ ] [ 60] camel-spring (2.6.0.SNAPSHOT)
karaf@root> osgi:list | grep Camel
[ 169] [Active ] [Created ] [ ] [ 60] Apache ServiceMix :: Components :: Camel Service Engine (2011.01.0.SNAPSHOT)
karaf@root>
However, when I deploy my service assembly and send the larger message in, I see the same behavior as with Camel 2.4 that's build into Fuse ESB 4.3.0-03-00. Do I need to do anything explicit to have the build include the latest version of Camel in which this bug is supposedly fixed?
I also noted that the log messages that Claus suggested I should see are not showing up (grepping the log for AnnotationTypeConverterLoader and DefaultTypeConverter returns no lines, and my log level is set at INFO...) Is this a sign of a problem with my build? I do see the following in the log:
17:45:52,176 | INFO | rint Extender: 1 | OsgiSpringCamelContext | e.camel.impl.DefaultCamelContext 1293 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Apache Camel 2.6-SNAPSHOT (CamelContext: camel) is starting
17:45:52,320 | INFO | rint Extender: 1 | Activator | BundleTypeConverterLoader$Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Found 1 @Converter classes to load
17:45:52,324 | INFO | rint Extender: 1 | Activator | BundleTypeConverterLoader$Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Found 1 @Converter classes to load
17:45:52,380 | INFO | rint Extender: 1 | Activator | BundleTypeConverterLoader$Loader 325 | 68 - org.apache.camel.camel-core - 2.6.0.SNAPSHOT | Found 13 @Converter classes to load
Thanks.
--Scott
-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com]
Sent: Monday, January 24, 2011 10:48 PM
To: users@servicemix.apache.org
Subject: Re: Large(ish) message issue (CXFBC and Camel)
Hi Scott,
I'm sorry I didn't aware you are using servicemix-camel component (JBI) version. In this case the upgrading will be more complicated.
You need to updated the servicemix-camel lib with the new version of camel-spring.
Fortunately we just cut Camel 2.6.0 and it will be part of Apache ServiceMix new version very soon. And we are releasing a new version of Fuse ESB 4.3.1 this week.
Willem
On 1/24/11 9:53 AM, Scott Came wrote:
> Willem:
>
> I did my best to understand what you suggested I do, but I'm not confident that I'm doing it right. Here is what I did:
>
> -- I shut down servicemix
>
> -- I downloaded the jar
> http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/a
> pache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-2
> 0110118.002228-16.jar
>
> -- I extracted the contents of that jar to a temporary directory
>
> -- I extracted the contents of the camel-spring-2.4.0-fuse-02-00, and
> copied its META-INF/MANIFEST.MF file to the META-INF directory of the
> extracted snapshot jar
>
> -- I re-jarred the snapshot
>
> -- I deleted the camel-sprint-2.4.0-fuse-02-00.jar from
> $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>
> -- I copied the snapshot jar (with the updated MANIFEST.MF) into
> $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>
> -- I deleted my $SMX_HOME/data directory
>
> -- I restarted servicemix
>
> After these steps, servicemix seems to start normally. Osgi:list:
>
> [ 153] [Active ] [Created ] [ ] [ 60] Apache ServiceMix :: Components :: Camel Service Engine (2010.02.0.fuse-02-00)
>
> Jbi:list
>
> [Started ] [servicemix-camel ]
>
> However, when I deploy my service assembly, I get a stack trace (see attached).
>
> Is this sequence of steps what you intended me to try? Any idea what's going wrong and where?
>
> Alternatively...is this version of camel-spring already included in
> some snapshot version of the entire FUSE ESB? If so, would it likely
> work better for me just to check out the ESB shapshot and build it?
> If so, are there instructions somewhere for finding the source
> repository and checking out the snapshot? (I looked at
> http://fusesource.com/forge/projects/fuseesb/source which says to use
> Subversion as such: svn co
> http://fusesource.com/forge/svn/fuseesb/trunk fuseesb; however, when
> I do, I get "svn: URL 'http://fusesource.com/forge/svn/fuseesb/trunk'
> doesn't exist".)
>
> Either way, I think I can offer some value to the project here by testing the new camel version, but I'm kinda stuck as a newcomer to the platform on some of these issues. Any help you can offer would be much appreciated.
>
> Thanks.
> --Scott
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com]
> Sent: Thursday, January 20, 2011 10:02 PM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> Yeah, you may need to hack the META-INF/manifest file yourself if you don't want to massage the bundle version complains yourself.
>
> The sample way download the snapshot jar and replace the manifest file of camel-spring 2.4.0-fuse-02-00.jar, and place the jar into the $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-01-00, restart the servicemix after deleting the $SMX_HOME/data.
>
> Willem
>
> On 1/20/11 8:56 PM, Scott Came wrote:
>> Thanks, Willem, I'll give that a try.
>>
>> Again apologies for my newbie questions, but I couldn't find any docs on this question: If I'm to install this component, what do I need to uninstall first to avoid conflicts? I have read things about not having multiple versions of Camel-* going at the same time...
>>
>> Also I assume I just download this jar and drop it in the deploy directory...correct?
>>
>> Thanks much.
>> --Scott
>>
>> -----Original Message-----
>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>> Sent: Wednesday, January 19, 2011 9:36 PM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> On 1/19/11 10:15 PM, Claus Ibsen wrote:
>>> On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<sc...@search.org> wrote:
>>>> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From
>>>> the log messages I included in my message yesterday, it looks like
>>>> my install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log
>>>> message:>>>> 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.)
>>>>
>>>> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
>>>>
>>>> If not, is there something else that's causing the type converters not to get loaded?
>>>>
>>>
>>> Its this bug which was fixed dec-20-2010
>>> http://fusesource.com/issues/browse/MR-392
>>>
>>> And -03 hasn't been released yet.
>> Maybe you can consider to try out the camel-spring 2.4.0-fuse-SNAPSHOT[1] which has the fix?
>>
>> [1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/o
>> r
>> g/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fu
>> s
>> e-20110118.002228-16.jar
>>
>>>
>>>
>>>> Thanks for all your help...
>>>> --Scott
>>>>
>>>> -----Original Message-----
>>>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>> Sent: Wednesday, January 19, 2011 5:14 AM
>>>> To: users@servicemix.apache.org
>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>
>>>> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<sc...@search.org> 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:willem.jiang@gmail.com]
>>>>> Sent: Wednesday, January 19, 2011 2:02 AM
>>>>> To: users@servicemix.apache.org
>>>>> 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:scott.came@search.org]
>>>>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>>>>> To: users@servicemix.apache.org
>>>>>> 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:claus.ibsen@gmail.com]
>>>>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>>>>> To: users@servicemix.apache.org
>>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>>
>>>>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>>>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>>>>> To: users@servicemix.apache.org
>>>>>>>> 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<sc...@search.org> 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.
>>>>>>>>> ja
>>>>>>>>> v
>>>>>>>>> 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:
>>>>>>>>> 1
>>>>>>>>> 0
>>>>>>>>> 48
>>>>>>>>> )
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.soap.util.stax.FragmentStreamReader.next
>>>>>>>>> (
>>>>>>>>> F
>>>>>>>>> ra
>>>>>>>>> g
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tStreamReader.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(S
>>>>>>>>> t
>>>>>>>>> a
>>>>>>>>> xJ
>>>>>>>>> b
>>>>>>>>> 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(MessageS
>>>>>>>>> u
>>>>>>>>> p
>>>>>>>>> po
>>>>>>>>> r
>>>>>>>>> t
>>>>>>>>> .j
>>>>>>>>> ava:103)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(Conver
>>>>>>>>> t
>>>>>>>>> B
>>>>>>>>> od
>>>>>>>>> y
>>>>>>>>> P
>>>>>>>>> ro
>>>>>>>>> cessor.java:57)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Pr
>>>>>>>>> o
>>>>>>>>> c
>>>>>>>>> es
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rT
>>>>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>> D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(I
>>>>>>>>> n
>>>>>>>>> s
>>>>>>>>> tr
>>>>>>>>> u
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tationProcessor.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>> D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.proces
>>>>>>>>> s
>>>>>>>>> (
>>>>>>>>> Tr
>>>>>>>>> a
>>>>>>>>> c
>>>>>>>>> eI
>>>>>>>>> nterceptor.java:99)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>> D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(I
>>>>>>>>> n
>>>>>>>>> s
>>>>>>>>> tr
>>>>>>>>> u
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tationProcessor.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processError
>>>>>>>>> H
>>>>>>>>> a
>>>>>>>>> nd
>>>>>>>>> l
>>>>>>>>> e
>>>>>>>>> r(
>>>>>>>>> RedeliveryErrorHandler.java:290)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Rede
>>>>>>>>> l
>>>>>>>>> i
>>>>>>>>> ve
>>>>>>>>> r
>>>>>>>>> y
>>>>>>>>> Er
>>>>>>>>> rorHandler.java:202)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>>>>> 256)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> 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(UnitOfW
>>>>>>>>> o
>>>>>>>>> r
>>>>>>>>> kP
>>>>>>>>> r
>>>>>>>>> o
>>>>>>>>> ce
>>>>>>>>> ssor.java:99)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProces
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(
>>>>>>>>> D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Dele
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(I
>>>>>>>>> n
>>>>>>>>> s
>>>>>>>>> tr
>>>>>>>>> u
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tationProcessor.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(Camel
>>>>>>>>> P
>>>>>>>>> r
>>>>>>>>> ov
>>>>>>>>> i
>>>>>>>>> d
>>>>>>>>> er
>>>>>>>>> Endpoint.java:109)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClas
>>>>>>>>> s
>>>>>>>>> L
>>>>>>>>> oa
>>>>>>>>> d
>>>>>>>>> e
>>>>>>>>> r(
>>>>>>>>> JbiBinding.java:116)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActive
>>>>>>>>> P
>>>>>>>>> r
>>>>>>>>> ov
>>>>>>>>> i
>>>>>>>>> d
>>>>>>>>> er
>>>>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(Came
>>>>>>>>> l
>>>>>>>>> P
>>>>>>>>> ro
>>>>>>>>> v
>>>>>>>>> i
>>>>>>>>> de
>>>>>>>>> rEndpoint.java:85)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(Asyn
>>>>>>>>> c
>>>>>>>>> B
>>>>>>>>> as
>>>>>>>>> e
>>>>>>>>> L
>>>>>>>>> if
>>>>>>>>> eCycle.java:651)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchang
>>>>>>>>> e
>>>>>>>>> (
>>>>>>>>> As
>>>>>>>>> y
>>>>>>>>> n
>>>>>>>>> cB
>>>>>>>>> aseLifeCycle.java:606)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchang
>>>>>>>>> e
>>>>>>>>> I
>>>>>>>>> nT
>>>>>>>>> x
>>>>>>>>> (
>>>>>>>>> As
>>>>>>>>> yncBaseLifeCycle.java:501)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBas
>>>>>>>>> e
>>>>>>>>> L
>>>>>>>>> if
>>>>>>>>> e
>>>>>>>>> C
>>>>>>>>> yc
>>>>>>>>> le.java:370)
>>>>>>>>> at
>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadP
>>>>>>>>> o
>>>>>>>>> o
>>>>>>>>> lE
>>>>>>>>> x
>>>>>>>>> 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:freeman.fang@gmail.com]
>>>>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>>>>> To: users@servicemix.apache.org
>>>>>>>>> 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-encou
>>>>>>>>>> n
>>>>>>>>>> t
>>>>>>>>>> er
>>>>>>>>>> - 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-encoun
>>>>>>>>> t
>>>>>>>>> e
>>>>>>>>> r- 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: cibsen@fusesource.com
>>>>>>>> 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: cibsen@fusesource.com
>>>>>>> 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: cibsen@fusesource.com
>>>>>> 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: cibsen@fusesource.com
>>>> 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
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Willem Jiang <wi...@gmail.com>.
Hi Scott,
I'm sorry I didn't aware you are using servicemix-camel component (JBI)
version. In this case the upgrading will be more complicated.
You need to updated the servicemix-camel lib with the new version of
camel-spring.
Fortunately we just cut Camel 2.6.0 and it will be part of Apache
ServiceMix new version very soon. And we are releasing a new version of
Fuse ESB 4.3.1 this week.
Willem
On 1/24/11 9:53 AM, Scott Came wrote:
> Willem:
>
> I did my best to understand what you suggested I do, but I'm not confident that I'm doing it right. Here is what I did:
>
> -- I shut down servicemix
>
> -- I downloaded the jar http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-20110118.002228-16.jar
>
> -- I extracted the contents of that jar to a temporary directory
>
> -- I extracted the contents of the camel-spring-2.4.0-fuse-02-00, and copied its META-INF/MANIFEST.MF file to the META-INF directory of the extracted snapshot jar
>
> -- I re-jarred the snapshot
>
> -- I deleted the camel-sprint-2.4.0-fuse-02-00.jar from $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>
> -- I copied the snapshot jar (with the updated MANIFEST.MF) into $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
>
> -- I deleted my $SMX_HOME/data directory
>
> -- I restarted servicemix
>
> After these steps, servicemix seems to start normally. Osgi:list:
>
> [ 153] [Active ] [Created ] [ ] [ 60] Apache ServiceMix :: Components :: Camel Service Engine (2010.02.0.fuse-02-00)
>
> Jbi:list
>
> [Started ] [servicemix-camel ]
>
> However, when I deploy my service assembly, I get a stack trace (see attached).
>
> Is this sequence of steps what you intended me to try? Any idea what's going wrong and where?
>
> Alternatively...is this version of camel-spring already included in some snapshot version of the entire FUSE ESB? If so, would it likely work better for me just to check out the ESB shapshot and build it? If so, are there instructions somewhere for finding the source repository and checking out the snapshot? (I looked at http://fusesource.com/forge/projects/fuseesb/source which says to use Subversion as such: svn co http://fusesource.com/forge/svn/fuseesb/trunk fuseesb; however, when I do, I get "svn: URL 'http://fusesource.com/forge/svn/fuseesb/trunk' doesn't exist".)
>
> Either way, I think I can offer some value to the project here by testing the new camel version, but I'm kinda stuck as a newcomer to the platform on some of these issues. Any help you can offer would be much appreciated.
>
> Thanks.
> --Scott
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com]
> Sent: Thursday, January 20, 2011 10:02 PM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> Yeah, you may need to hack the META-INF/manifest file yourself if you don't want to massage the bundle version complains yourself.
>
> The sample way download the snapshot jar and replace the manifest file of camel-spring 2.4.0-fuse-02-00.jar, and place the jar into the $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-01-00, restart the servicemix after deleting the $SMX_HOME/data.
>
> Willem
>
> On 1/20/11 8:56 PM, Scott Came wrote:
>> Thanks, Willem, I'll give that a try.
>>
>> Again apologies for my newbie questions, but I couldn't find any docs on this question: If I'm to install this component, what do I need to uninstall first to avoid conflicts? I have read things about not having multiple versions of Camel-* going at the same time...
>>
>> Also I assume I just download this jar and drop it in the deploy directory...correct?
>>
>> Thanks much.
>> --Scott
>>
>> -----Original Message-----
>> From: Willem Jiang [mailto:willem.jiang@gmail.com]
>> Sent: Wednesday, January 19, 2011 9:36 PM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> On 1/19/11 10:15 PM, Claus Ibsen wrote:
>>> On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<sc...@search.org> wrote:
>>>> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From the
>>>> log messages I included in my message yesterday, it looks like my
>>>> install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log
>>>> message:>>>> 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.)
>>>>
>>>> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
>>>>
>>>> If not, is there something else that's causing the type converters not to get loaded?
>>>>
>>>
>>> Its this bug which was fixed dec-20-2010
>>> http://fusesource.com/issues/browse/MR-392
>>>
>>> And -03 hasn't been released yet.
>> Maybe you can consider to try out the camel-spring 2.4.0-fuse-SNAPSHOT[1] which has the fix?
>>
>> [1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/or
>> g/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fus
>> e-20110118.002228-16.jar
>>
>>>
>>>
>>>> Thanks for all your help...
>>>> --Scott
>>>>
>>>> -----Original Message-----
>>>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>>> Sent: Wednesday, January 19, 2011 5:14 AM
>>>> To: users@servicemix.apache.org
>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>
>>>> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<sc...@search.org> 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:willem.jiang@gmail.com]
>>>>> Sent: Wednesday, January 19, 2011 2:02 AM
>>>>> To: users@servicemix.apache.org
>>>>> 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:scott.came@search.org]
>>>>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>>>>> To: users@servicemix.apache.org
>>>>>> 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:claus.ibsen@gmail.com]
>>>>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>>>>> To: users@servicemix.apache.org
>>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>>
>>>>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>>>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>>>>> To: users@servicemix.apache.org
>>>>>>>> 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<sc...@search.org> 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.
>>>>>>>>> ja
>>>>>>>>> v
>>>>>>>>> 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:1
>>>>>>>>> 0
>>>>>>>>> 48
>>>>>>>>> )
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.soap.util.stax.FragmentStreamReader.next(
>>>>>>>>> F
>>>>>>>>> ra
>>>>>>>>> g
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tStreamReader.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(St
>>>>>>>>> a
>>>>>>>>> xJ
>>>>>>>>> b
>>>>>>>>> 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(MessageSu
>>>>>>>>> p
>>>>>>>>> po
>>>>>>>>> r
>>>>>>>>> t
>>>>>>>>> .j
>>>>>>>>> ava:103)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(Convert
>>>>>>>>> B
>>>>>>>>> od
>>>>>>>>> y
>>>>>>>>> P
>>>>>>>>> ro
>>>>>>>>> cessor.java:57)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Pro
>>>>>>>>> c
>>>>>>>>> es
>>>>>>>>> s
>>>>>>>>> o
>>>>>>>>> rT
>>>>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(In
>>>>>>>>> s
>>>>>>>>> tr
>>>>>>>>> u
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tationProcessor.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.process
>>>>>>>>> (
>>>>>>>>> Tr
>>>>>>>>> a
>>>>>>>>> c
>>>>>>>>> eI
>>>>>>>>> nterceptor.java:99)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(In
>>>>>>>>> s
>>>>>>>>> tr
>>>>>>>>> u
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tationProcessor.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processErrorH
>>>>>>>>> a
>>>>>>>>> nd
>>>>>>>>> l
>>>>>>>>> e
>>>>>>>>> r(
>>>>>>>>> RedeliveryErrorHandler.java:290)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Redel
>>>>>>>>> i
>>>>>>>>> ve
>>>>>>>>> r
>>>>>>>>> y
>>>>>>>>> Er
>>>>>>>>> rorHandler.java:202)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>>>>> 256)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> 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(UnitOfWo
>>>>>>>>> r
>>>>>>>>> kP
>>>>>>>>> r
>>>>>>>>> o
>>>>>>>>> ce
>>>>>>>>> ssor.java:99)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>>> o
>>>>>>>>> rH
>>>>>>>>> e
>>>>>>>>> l
>>>>>>>>> pe
>>>>>>>>> r.java:70)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
>>>>>>>>> e
>>>>>>>>> le
>>>>>>>>> g
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> AsyncProcessor.java:98)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
>>>>>>>>> a
>>>>>>>>> te
>>>>>>>>> A
>>>>>>>>> s
>>>>>>>>> yn
>>>>>>>>> cProcessor.java:89)
>>>>>>>>> at
>>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(In
>>>>>>>>> s
>>>>>>>>> tr
>>>>>>>>> u
>>>>>>>>> m
>>>>>>>>> en
>>>>>>>>> tationProcessor.java:68)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelP
>>>>>>>>> r
>>>>>>>>> ov
>>>>>>>>> i
>>>>>>>>> d
>>>>>>>>> er
>>>>>>>>> Endpoint.java:109)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClass
>>>>>>>>> L
>>>>>>>>> oa
>>>>>>>>> d
>>>>>>>>> e
>>>>>>>>> r(
>>>>>>>>> JbiBinding.java:116)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveP
>>>>>>>>> r
>>>>>>>>> ov
>>>>>>>>> i
>>>>>>>>> d
>>>>>>>>> er
>>>>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(Camel
>>>>>>>>> P
>>>>>>>>> ro
>>>>>>>>> v
>>>>>>>>> i
>>>>>>>>> de
>>>>>>>>> rEndpoint.java:85)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(Async
>>>>>>>>> B
>>>>>>>>> as
>>>>>>>>> e
>>>>>>>>> L
>>>>>>>>> if
>>>>>>>>> eCycle.java:651)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange
>>>>>>>>> (
>>>>>>>>> As
>>>>>>>>> y
>>>>>>>>> n
>>>>>>>>> cB
>>>>>>>>> aseLifeCycle.java:606)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange
>>>>>>>>> I
>>>>>>>>> nT
>>>>>>>>> x
>>>>>>>>> (
>>>>>>>>> As
>>>>>>>>> yncBaseLifeCycle.java:501)
>>>>>>>>> at
>>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBase
>>>>>>>>> L
>>>>>>>>> if
>>>>>>>>> e
>>>>>>>>> C
>>>>>>>>> yc
>>>>>>>>> le.java:370)
>>>>>>>>> at
>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPo
>>>>>>>>> o
>>>>>>>>> lE
>>>>>>>>> x
>>>>>>>>> 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:freeman.fang@gmail.com]
>>>>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>>>>> To: users@servicemix.apache.org
>>>>>>>>> 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-encoun
>>>>>>>>>> t
>>>>>>>>>> er
>>>>>>>>>> - 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-encount
>>>>>>>>> e
>>>>>>>>> r- 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: cibsen@fusesource.com
>>>>>>>> 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: cibsen@fusesource.com
>>>>>>> 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: cibsen@fusesource.com
>>>>>> 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: cibsen@fusesource.com
>>>> 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
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
Willem:
I did my best to understand what you suggested I do, but I'm not confident that I'm doing it right. Here is what I did:
-- I shut down servicemix
-- I downloaded the jar http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-20110118.002228-16.jar
-- I extracted the contents of that jar to a temporary directory
-- I extracted the contents of the camel-spring-2.4.0-fuse-02-00, and copied its META-INF/MANIFEST.MF file to the META-INF directory of the extracted snapshot jar
-- I re-jarred the snapshot
-- I deleted the camel-sprint-2.4.0-fuse-02-00.jar from $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
-- I copied the snapshot jar (with the updated MANIFEST.MF) into $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-02-00
-- I deleted my $SMX_HOME/data directory
-- I restarted servicemix
After these steps, servicemix seems to start normally. Osgi:list:
[ 153] [Active ] [Created ] [ ] [ 60] Apache ServiceMix :: Components :: Camel Service Engine (2010.02.0.fuse-02-00)
Jbi:list
[Started ] [servicemix-camel ]
However, when I deploy my service assembly, I get a stack trace (see attached).
Is this sequence of steps what you intended me to try? Any idea what's going wrong and where?
Alternatively...is this version of camel-spring already included in some snapshot version of the entire FUSE ESB? If so, would it likely work better for me just to check out the ESB shapshot and build it? If so, are there instructions somewhere for finding the source repository and checking out the snapshot? (I looked at http://fusesource.com/forge/projects/fuseesb/source which says to use Subversion as such: svn co http://fusesource.com/forge/svn/fuseesb/trunk fuseesb; however, when I do, I get "svn: URL 'http://fusesource.com/forge/svn/fuseesb/trunk' doesn't exist".)
Either way, I think I can offer some value to the project here by testing the new camel version, but I'm kinda stuck as a newcomer to the platform on some of these issues. Any help you can offer would be much appreciated.
Thanks.
--Scott
-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com]
Sent: Thursday, January 20, 2011 10:02 PM
To: users@servicemix.apache.org
Subject: Re: Large(ish) message issue (CXFBC and Camel)
Yeah, you may need to hack the META-INF/manifest file yourself if you don't want to massage the bundle version complains yourself.
The sample way download the snapshot jar and replace the manifest file of camel-spring 2.4.0-fuse-02-00.jar, and place the jar into the $SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-01-00, restart the servicemix after deleting the $SMX_HOME/data.
Willem
On 1/20/11 8:56 PM, Scott Came wrote:
> Thanks, Willem, I'll give that a try.
>
> Again apologies for my newbie questions, but I couldn't find any docs on this question: If I'm to install this component, what do I need to uninstall first to avoid conflicts? I have read things about not having multiple versions of Camel-* going at the same time...
>
> Also I assume I just download this jar and drop it in the deploy directory...correct?
>
> Thanks much.
> --Scott
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com]
> Sent: Wednesday, January 19, 2011 9:36 PM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> On 1/19/11 10:15 PM, Claus Ibsen wrote:
>> On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<sc...@search.org> wrote:
>>> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From the
>>> log messages I included in my message yesterday, it looks like my
>>> install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log
>>> message:>>>> 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.)
>>>
>>> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
>>>
>>> If not, is there something else that's causing the type converters not to get loaded?
>>>
>>
>> Its this bug which was fixed dec-20-2010
>> http://fusesource.com/issues/browse/MR-392
>>
>> And -03 hasn't been released yet.
> Maybe you can consider to try out the camel-spring 2.4.0-fuse-SNAPSHOT[1] which has the fix?
>
> [1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/or
> g/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fus
> e-20110118.002228-16.jar
>
>>
>>
>>> Thanks for all your help...
>>> --Scott
>>>
>>> -----Original Message-----
>>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>> Sent: Wednesday, January 19, 2011 5:14 AM
>>> To: users@servicemix.apache.org
>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>
>>> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<sc...@search.org> 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:willem.jiang@gmail.com]
>>>> Sent: Wednesday, January 19, 2011 2:02 AM
>>>> To: users@servicemix.apache.org
>>>> 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:scott.came@search.org]
>>>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>>>> To: users@servicemix.apache.org
>>>>> 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:claus.ibsen@gmail.com]
>>>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>>>> To: users@servicemix.apache.org
>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>
>>>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>>>> To: users@servicemix.apache.org
>>>>>>> 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<sc...@search.org> 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.
>>>>>>>> ja
>>>>>>>> v
>>>>>>>> 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:1
>>>>>>>> 0
>>>>>>>> 48
>>>>>>>> )
>>>>>>>> at
>>>>>>>> org.apache.servicemix.soap.util.stax.FragmentStreamReader.next(
>>>>>>>> F
>>>>>>>> ra
>>>>>>>> g
>>>>>>>> m
>>>>>>>> en
>>>>>>>> tStreamReader.java:68)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(St
>>>>>>>> a
>>>>>>>> xJ
>>>>>>>> b
>>>>>>>> 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(MessageSu
>>>>>>>> p
>>>>>>>> po
>>>>>>>> r
>>>>>>>> t
>>>>>>>> .j
>>>>>>>> ava:103)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(Convert
>>>>>>>> B
>>>>>>>> od
>>>>>>>> y
>>>>>>>> P
>>>>>>>> ro
>>>>>>>> cessor.java:57)
>>>>>>>> at
>>>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Pro
>>>>>>>> c
>>>>>>>> es
>>>>>>>> s
>>>>>>>> o
>>>>>>>> rT
>>>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>> o
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> l
>>>>>>>> pe
>>>>>>>> r.java:70)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
>>>>>>>> e
>>>>>>>> le
>>>>>>>> g
>>>>>>>> a
>>>>>>>> te
>>>>>>>> AsyncProcessor.java:98)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
>>>>>>>> a
>>>>>>>> te
>>>>>>>> A
>>>>>>>> s
>>>>>>>> yn
>>>>>>>> cProcessor.java:89)
>>>>>>>> at
>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(In
>>>>>>>> s
>>>>>>>> tr
>>>>>>>> u
>>>>>>>> m
>>>>>>>> en
>>>>>>>> tationProcessor.java:68)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>> o
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> l
>>>>>>>> pe
>>>>>>>> r.java:70)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
>>>>>>>> e
>>>>>>>> le
>>>>>>>> g
>>>>>>>> a
>>>>>>>> te
>>>>>>>> AsyncProcessor.java:98)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
>>>>>>>> a
>>>>>>>> te
>>>>>>>> A
>>>>>>>> s
>>>>>>>> yn
>>>>>>>> cProcessor.java:89)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.process
>>>>>>>> (
>>>>>>>> Tr
>>>>>>>> a
>>>>>>>> c
>>>>>>>> eI
>>>>>>>> nterceptor.java:99)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>> o
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> l
>>>>>>>> pe
>>>>>>>> r.java:70)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
>>>>>>>> e
>>>>>>>> le
>>>>>>>> g
>>>>>>>> a
>>>>>>>> te
>>>>>>>> AsyncProcessor.java:98)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
>>>>>>>> a
>>>>>>>> te
>>>>>>>> A
>>>>>>>> s
>>>>>>>> yn
>>>>>>>> cProcessor.java:89)
>>>>>>>> at
>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(In
>>>>>>>> s
>>>>>>>> tr
>>>>>>>> u
>>>>>>>> m
>>>>>>>> en
>>>>>>>> tationProcessor.java:68)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>> o
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> l
>>>>>>>> pe
>>>>>>>> r.java:70)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processErrorH
>>>>>>>> a
>>>>>>>> nd
>>>>>>>> l
>>>>>>>> e
>>>>>>>> r(
>>>>>>>> RedeliveryErrorHandler.java:290)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Redel
>>>>>>>> i
>>>>>>>> ve
>>>>>>>> r
>>>>>>>> y
>>>>>>>> Er
>>>>>>>> rorHandler.java:202)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>>>> 256)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>> o
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> 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(UnitOfWo
>>>>>>>> r
>>>>>>>> kP
>>>>>>>> r
>>>>>>>> o
>>>>>>>> ce
>>>>>>>> ssor.java:99)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcess
>>>>>>>> o
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> l
>>>>>>>> pe
>>>>>>>> r.java:70)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(D
>>>>>>>> e
>>>>>>>> le
>>>>>>>> g
>>>>>>>> a
>>>>>>>> te
>>>>>>>> AsyncProcessor.java:98)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Deleg
>>>>>>>> a
>>>>>>>> te
>>>>>>>> A
>>>>>>>> s
>>>>>>>> yn
>>>>>>>> cProcessor.java:89)
>>>>>>>> at
>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(In
>>>>>>>> s
>>>>>>>> tr
>>>>>>>> u
>>>>>>>> m
>>>>>>>> en
>>>>>>>> tationProcessor.java:68)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelP
>>>>>>>> r
>>>>>>>> ov
>>>>>>>> i
>>>>>>>> d
>>>>>>>> er
>>>>>>>> Endpoint.java:109)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClass
>>>>>>>> L
>>>>>>>> oa
>>>>>>>> d
>>>>>>>> e
>>>>>>>> r(
>>>>>>>> JbiBinding.java:116)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveP
>>>>>>>> r
>>>>>>>> ov
>>>>>>>> i
>>>>>>>> d
>>>>>>>> er
>>>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(Camel
>>>>>>>> P
>>>>>>>> ro
>>>>>>>> v
>>>>>>>> i
>>>>>>>> de
>>>>>>>> rEndpoint.java:85)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(Async
>>>>>>>> B
>>>>>>>> as
>>>>>>>> e
>>>>>>>> L
>>>>>>>> if
>>>>>>>> eCycle.java:651)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange
>>>>>>>> (
>>>>>>>> As
>>>>>>>> y
>>>>>>>> n
>>>>>>>> cB
>>>>>>>> aseLifeCycle.java:606)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange
>>>>>>>> I
>>>>>>>> nT
>>>>>>>> x
>>>>>>>> (
>>>>>>>> As
>>>>>>>> yncBaseLifeCycle.java:501)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBase
>>>>>>>> L
>>>>>>>> if
>>>>>>>> e
>>>>>>>> C
>>>>>>>> yc
>>>>>>>> le.java:370)
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPo
>>>>>>>> o
>>>>>>>> lE
>>>>>>>> x
>>>>>>>> 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:freeman.fang@gmail.com]
>>>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>>>> To: users@servicemix.apache.org
>>>>>>>> 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-encoun
>>>>>>>>> t
>>>>>>>>> er
>>>>>>>>> - 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-encount
>>>>>>>> e
>>>>>>>> r- 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: cibsen@fusesource.com
>>>>>>> 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: cibsen@fusesource.com
>>>>>> 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: cibsen@fusesource.com
>>>>> 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: cibsen@fusesource.com
>>> 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
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Willem Jiang <wi...@gmail.com>.
Yeah, you may need to hack the META-INF/manifest file yourself if you
don't want to massage the bundle version complains yourself.
The sample way download the snapshot jar and replace the manifest file
of camel-spring 2.4.0-fuse-02-00.jar, and place the jar into the
$SMX_HOME/system/org/apache/camel/camel-spring/2.4.0-fuse-01-00, restart
the servicemix after deleting the $SMX_HOME/data.
Willem
On 1/20/11 8:56 PM, Scott Came wrote:
> Thanks, Willem, I'll give that a try.
>
> Again apologies for my newbie questions, but I couldn't find any docs on this question: If I'm to install this component, what do I need to uninstall first to avoid conflicts? I have read things about not having multiple versions of Camel-* going at the same time...
>
> Also I assume I just download this jar and drop it in the deploy directory...correct?
>
> Thanks much.
> --Scott
>
> -----Original Message-----
> From: Willem Jiang [mailto:willem.jiang@gmail.com]
> Sent: Wednesday, January 19, 2011 9:36 PM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> On 1/19/11 10:15 PM, Claus Ibsen wrote:
>> On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<sc...@search.org> wrote:
>>> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From the
>>> log messages I included in my message yesterday, it looks like my
>>> install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log
>>> message:>>>> 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.)
>>>
>>> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
>>>
>>> If not, is there something else that's causing the type converters not to get loaded?
>>>
>>
>> Its this bug which was fixed dec-20-2010
>> http://fusesource.com/issues/browse/MR-392
>>
>> And -03 hasn't been released yet.
> Maybe you can consider to try out the camel-spring 2.4.0-fuse-SNAPSHOT[1] which has the fix?
>
> [1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-20110118.002228-16.jar
>
>>
>>
>>> Thanks for all your help...
>>> --Scott
>>>
>>> -----Original Message-----
>>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>>> Sent: Wednesday, January 19, 2011 5:14 AM
>>> To: users@servicemix.apache.org
>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>
>>> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<sc...@search.org> 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:willem.jiang@gmail.com]
>>>> Sent: Wednesday, January 19, 2011 2:02 AM
>>>> To: users@servicemix.apache.org
>>>> 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:scott.came@search.org]
>>>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>>>> To: users@servicemix.apache.org
>>>>> 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:claus.ibsen@gmail.com]
>>>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>>>> To: users@servicemix.apache.org
>>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>>
>>>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>>>> To: users@servicemix.apache.org
>>>>>>> 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<sc...@search.org> 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.
>>>>>>>> ja
>>>>>>>> v
>>>>>>>> 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:10
>>>>>>>> 48
>>>>>>>> )
>>>>>>>> at
>>>>>>>> org.apache.servicemix.soap.util.stax.FragmentStreamReader.next(F
>>>>>>>> ra
>>>>>>>> g
>>>>>>>> m
>>>>>>>> en
>>>>>>>> tStreamReader.java:68)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(Sta
>>>>>>>> xJ
>>>>>>>> b
>>>>>>>> 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(MessageSup
>>>>>>>> po
>>>>>>>> r
>>>>>>>> t
>>>>>>>> .j
>>>>>>>> ava:103)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(ConvertB
>>>>>>>> od
>>>>>>>> y
>>>>>>>> P
>>>>>>>> ro
>>>>>>>> cessor.java:57)
>>>>>>>> at
>>>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Proc
>>>>>>>> es
>>>>>>>> s
>>>>>>>> o
>>>>>>>> rT
>>>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> l
>>>>>>>> pe
>>>>>>>> r.java:70)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De
>>>>>>>> le
>>>>>>>> g
>>>>>>>> a
>>>>>>>> te
>>>>>>>> AsyncProcessor.java:98)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega
>>>>>>>> te
>>>>>>>> A
>>>>>>>> s
>>>>>>>> yn
>>>>>>>> cProcessor.java:89)
>>>>>>>> at
>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Ins
>>>>>>>> tr
>>>>>>>> u
>>>>>>>> m
>>>>>>>> en
>>>>>>>> tationProcessor.java:68)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> l
>>>>>>>> pe
>>>>>>>> r.java:70)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De
>>>>>>>> le
>>>>>>>> g
>>>>>>>> a
>>>>>>>> te
>>>>>>>> AsyncProcessor.java:98)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega
>>>>>>>> te
>>>>>>>> A
>>>>>>>> s
>>>>>>>> yn
>>>>>>>> cProcessor.java:89)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.process(
>>>>>>>> Tr
>>>>>>>> a
>>>>>>>> c
>>>>>>>> eI
>>>>>>>> nterceptor.java:99)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> l
>>>>>>>> pe
>>>>>>>> r.java:70)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De
>>>>>>>> le
>>>>>>>> g
>>>>>>>> a
>>>>>>>> te
>>>>>>>> AsyncProcessor.java:98)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega
>>>>>>>> te
>>>>>>>> A
>>>>>>>> s
>>>>>>>> yn
>>>>>>>> cProcessor.java:89)
>>>>>>>> at
>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Ins
>>>>>>>> tr
>>>>>>>> u
>>>>>>>> m
>>>>>>>> en
>>>>>>>> tationProcessor.java:68)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> l
>>>>>>>> pe
>>>>>>>> r.java:70)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHa
>>>>>>>> nd
>>>>>>>> l
>>>>>>>> e
>>>>>>>> r(
>>>>>>>> RedeliveryErrorHandler.java:290)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Redeli
>>>>>>>> ve
>>>>>>>> r
>>>>>>>> y
>>>>>>>> Er
>>>>>>>> rorHandler.java:202)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>>>> 256)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> 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(UnitOfWor
>>>>>>>> kP
>>>>>>>> r
>>>>>>>> o
>>>>>>>> ce
>>>>>>>> ssor.java:99)
>>>>>>>> at
>>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>>> rH
>>>>>>>> e
>>>>>>>> l
>>>>>>>> pe
>>>>>>>> r.java:70)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De
>>>>>>>> le
>>>>>>>> g
>>>>>>>> a
>>>>>>>> te
>>>>>>>> AsyncProcessor.java:98)
>>>>>>>> at
>>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega
>>>>>>>> te
>>>>>>>> A
>>>>>>>> s
>>>>>>>> yn
>>>>>>>> cProcessor.java:89)
>>>>>>>> at
>>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Ins
>>>>>>>> tr
>>>>>>>> u
>>>>>>>> m
>>>>>>>> en
>>>>>>>> tationProcessor.java:68)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelPr
>>>>>>>> ov
>>>>>>>> i
>>>>>>>> d
>>>>>>>> er
>>>>>>>> Endpoint.java:109)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassL
>>>>>>>> oa
>>>>>>>> d
>>>>>>>> e
>>>>>>>> r(
>>>>>>>> JbiBinding.java:116)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActivePr
>>>>>>>> ov
>>>>>>>> i
>>>>>>>> d
>>>>>>>> er
>>>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelP
>>>>>>>> ro
>>>>>>>> v
>>>>>>>> i
>>>>>>>> de
>>>>>>>> rEndpoint.java:85)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncB
>>>>>>>> as
>>>>>>>> e
>>>>>>>> L
>>>>>>>> if
>>>>>>>> eCycle.java:651)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(
>>>>>>>> As
>>>>>>>> y
>>>>>>>> n
>>>>>>>> cB
>>>>>>>> aseLifeCycle.java:606)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeI
>>>>>>>> nT
>>>>>>>> x
>>>>>>>> (
>>>>>>>> As
>>>>>>>> yncBaseLifeCycle.java:501)
>>>>>>>> at
>>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseL
>>>>>>>> if
>>>>>>>> e
>>>>>>>> C
>>>>>>>> yc
>>>>>>>> le.java:370)
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoo
>>>>>>>> lE
>>>>>>>> x
>>>>>>>> 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:freeman.fang@gmail.com]
>>>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>>>> To: users@servicemix.apache.org
>>>>>>>> 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-encount
>>>>>>>>> er
>>>>>>>>> - 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-encounte
>>>>>>>> r- 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: cibsen@fusesource.com
>>>>>>> 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: cibsen@fusesource.com
>>>>>> 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: cibsen@fusesource.com
>>>>> 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: cibsen@fusesource.com
>>> 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
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
Thanks, Willem, I'll give that a try.
Again apologies for my newbie questions, but I couldn't find any docs on this question: If I'm to install this component, what do I need to uninstall first to avoid conflicts? I have read things about not having multiple versions of Camel-* going at the same time...
Also I assume I just download this jar and drop it in the deploy directory...correct?
Thanks much.
--Scott
-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com]
Sent: Wednesday, January 19, 2011 9:36 PM
To: users@servicemix.apache.org
Subject: Re: Large(ish) message issue (CXFBC and Camel)
On 1/19/11 10:15 PM, Claus Ibsen wrote:
> On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<sc...@search.org> wrote:
>> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From the
>> log messages I included in my message yesterday, it looks like my
>> install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log
>> message:>>>> 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.)
>>
>> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
>>
>> If not, is there something else that's causing the type converters not to get loaded?
>>
>
> Its this bug which was fixed dec-20-2010
> http://fusesource.com/issues/browse/MR-392
>
> And -03 hasn't been released yet.
Maybe you can consider to try out the camel-spring 2.4.0-fuse-SNAPSHOT[1] which has the fix?
[1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-20110118.002228-16.jar
>
>
>> Thanks for all your help...
>> --Scott
>>
>> -----Original Message-----
>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>> Sent: Wednesday, January 19, 2011 5:14 AM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<sc...@search.org> 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:willem.jiang@gmail.com]
>>> Sent: Wednesday, January 19, 2011 2:02 AM
>>> To: users@servicemix.apache.org
>>> 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:scott.came@search.org]
>>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>>> To: users@servicemix.apache.org
>>>> 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:claus.ibsen@gmail.com]
>>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>>> To: users@servicemix.apache.org
>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>
>>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>>> To: users@servicemix.apache.org
>>>>>> 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<sc...@search.org> 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.
>>>>>>> ja
>>>>>>> v
>>>>>>> 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:10
>>>>>>> 48
>>>>>>> )
>>>>>>> at
>>>>>>> org.apache.servicemix.soap.util.stax.FragmentStreamReader.next(F
>>>>>>> ra
>>>>>>> g
>>>>>>> m
>>>>>>> en
>>>>>>> tStreamReader.java:68)
>>>>>>> at
>>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(Sta
>>>>>>> xJ
>>>>>>> b
>>>>>>> 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(MessageSup
>>>>>>> po
>>>>>>> r
>>>>>>> t
>>>>>>> .j
>>>>>>> ava:103)
>>>>>>> at
>>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(ConvertB
>>>>>>> od
>>>>>>> y
>>>>>>> P
>>>>>>> ro
>>>>>>> cessor.java:57)
>>>>>>> at
>>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Proc
>>>>>>> es
>>>>>>> s
>>>>>>> o
>>>>>>> rT
>>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>> rH
>>>>>>> e
>>>>>>> l
>>>>>>> pe
>>>>>>> r.java:70)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De
>>>>>>> le
>>>>>>> g
>>>>>>> a
>>>>>>> te
>>>>>>> AsyncProcessor.java:98)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega
>>>>>>> te
>>>>>>> A
>>>>>>> s
>>>>>>> yn
>>>>>>> cProcessor.java:89)
>>>>>>> at
>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Ins
>>>>>>> tr
>>>>>>> u
>>>>>>> m
>>>>>>> en
>>>>>>> tationProcessor.java:68)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>> rH
>>>>>>> e
>>>>>>> l
>>>>>>> pe
>>>>>>> r.java:70)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De
>>>>>>> le
>>>>>>> g
>>>>>>> a
>>>>>>> te
>>>>>>> AsyncProcessor.java:98)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega
>>>>>>> te
>>>>>>> A
>>>>>>> s
>>>>>>> yn
>>>>>>> cProcessor.java:89)
>>>>>>> at
>>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.process(
>>>>>>> Tr
>>>>>>> a
>>>>>>> c
>>>>>>> eI
>>>>>>> nterceptor.java:99)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>> rH
>>>>>>> e
>>>>>>> l
>>>>>>> pe
>>>>>>> r.java:70)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De
>>>>>>> le
>>>>>>> g
>>>>>>> a
>>>>>>> te
>>>>>>> AsyncProcessor.java:98)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega
>>>>>>> te
>>>>>>> A
>>>>>>> s
>>>>>>> yn
>>>>>>> cProcessor.java:89)
>>>>>>> at
>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Ins
>>>>>>> tr
>>>>>>> u
>>>>>>> m
>>>>>>> en
>>>>>>> tationProcessor.java:68)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>> rH
>>>>>>> e
>>>>>>> l
>>>>>>> pe
>>>>>>> r.java:70)
>>>>>>> at
>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHa
>>>>>>> nd
>>>>>>> l
>>>>>>> e
>>>>>>> r(
>>>>>>> RedeliveryErrorHandler.java:290)
>>>>>>> at
>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Redeli
>>>>>>> ve
>>>>>>> r
>>>>>>> y
>>>>>>> Er
>>>>>>> rorHandler.java:202)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>>> 256)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>> rH
>>>>>>> e
>>>>>>> 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(UnitOfWor
>>>>>>> kP
>>>>>>> r
>>>>>>> o
>>>>>>> ce
>>>>>>> ssor.java:99)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcesso
>>>>>>> rH
>>>>>>> e
>>>>>>> l
>>>>>>> pe
>>>>>>> r.java:70)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(De
>>>>>>> le
>>>>>>> g
>>>>>>> a
>>>>>>> te
>>>>>>> AsyncProcessor.java:98)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delega
>>>>>>> te
>>>>>>> A
>>>>>>> s
>>>>>>> yn
>>>>>>> cProcessor.java:89)
>>>>>>> at
>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Ins
>>>>>>> tr
>>>>>>> u
>>>>>>> m
>>>>>>> en
>>>>>>> tationProcessor.java:68)
>>>>>>> at
>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelPr
>>>>>>> ov
>>>>>>> i
>>>>>>> d
>>>>>>> er
>>>>>>> Endpoint.java:109)
>>>>>>> at
>>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassL
>>>>>>> oa
>>>>>>> d
>>>>>>> e
>>>>>>> r(
>>>>>>> JbiBinding.java:116)
>>>>>>> at
>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActivePr
>>>>>>> ov
>>>>>>> i
>>>>>>> d
>>>>>>> er
>>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>>> at
>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelP
>>>>>>> ro
>>>>>>> v
>>>>>>> i
>>>>>>> de
>>>>>>> rEndpoint.java:85)
>>>>>>> at
>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncB
>>>>>>> as
>>>>>>> e
>>>>>>> L
>>>>>>> if
>>>>>>> eCycle.java:651)
>>>>>>> at
>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(
>>>>>>> As
>>>>>>> y
>>>>>>> n
>>>>>>> cB
>>>>>>> aseLifeCycle.java:606)
>>>>>>> at
>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeI
>>>>>>> nT
>>>>>>> x
>>>>>>> (
>>>>>>> As
>>>>>>> yncBaseLifeCycle.java:501)
>>>>>>> at
>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseL
>>>>>>> if
>>>>>>> e
>>>>>>> C
>>>>>>> yc
>>>>>>> le.java:370)
>>>>>>> at
>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoo
>>>>>>> lE
>>>>>>> x
>>>>>>> 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:freeman.fang@gmail.com]
>>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>>> To: users@servicemix.apache.org
>>>>>>> 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-encount
>>>>>>>> er
>>>>>>>> - 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-encounte
>>>>>>> r- 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: cibsen@fusesource.com
>>>>>> 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: cibsen@fusesource.com
>>>>> 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: cibsen@fusesource.com
>>>> 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: cibsen@fusesource.com
>> 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
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Willem Jiang <wi...@gmail.com>.
On 1/19/11 10:15 PM, Claus Ibsen wrote:
> On Wed, Jan 19, 2011 at 2:26 PM, Scott Came<sc...@search.org> wrote:
>> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From the log messages I included in my message yesterday, it looks like my install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log message:>>>> 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.)
>>
>> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
>>
>> If not, is there something else that's causing the type converters not to get loaded?
>>
>
> Its this bug which was fixed dec-20-2010
> http://fusesource.com/issues/browse/MR-392
>
> And -03 hasn't been released yet.
Maybe you can consider to try out the camel-spring
2.4.0-fuse-SNAPSHOT[1] which has the fix?
[1]http://repo.fusesource.com/nexus/content/groups/public-snapshots/org/apache/camel/camel-spring/2.4.0-fuse-SNAPSHOT/camel-spring-2.4.0-fuse-20110118.002228-16.jar
>
>
>> Thanks for all your help...
>> --Scott
>>
>> -----Original Message-----
>> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
>> Sent: Wednesday, January 19, 2011 5:14 AM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came<sc...@search.org> 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:willem.jiang@gmail.com]
>>> Sent: Wednesday, January 19, 2011 2:02 AM
>>> To: users@servicemix.apache.org
>>> 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:scott.came@search.org]
>>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>>> To: users@servicemix.apache.org
>>>> 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:claus.ibsen@gmail.com]
>>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>>> To: users@servicemix.apache.org
>>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>>
>>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>>> To: users@servicemix.apache.org
>>>>>> 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<sc...@search.org> 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.ja
>>>>>>> v
>>>>>>> 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(Fra
>>>>>>> g
>>>>>>> m
>>>>>>> en
>>>>>>> tStreamReader.java:68)
>>>>>>> at
>>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(StaxJ
>>>>>>> b
>>>>>>> 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(MessageSuppo
>>>>>>> r
>>>>>>> t
>>>>>>> .j
>>>>>>> ava:103)
>>>>>>> at
>>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(ConvertBod
>>>>>>> y
>>>>>>> P
>>>>>>> ro
>>>>>>> cessor.java:57)
>>>>>>> at
>>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Proces
>>>>>>> s
>>>>>>> o
>>>>>>> rT
>>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>>> e
>>>>>>> l
>>>>>>> pe
>>>>>>> r.java:70)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>>>> g
>>>>>>> a
>>>>>>> te
>>>>>>> AsyncProcessor.java:98)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>>>> A
>>>>>>> s
>>>>>>> yn
>>>>>>> cProcessor.java:89)
>>>>>>> at
>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Instr
>>>>>>> u
>>>>>>> m
>>>>>>> en
>>>>>>> tationProcessor.java:68)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>>> e
>>>>>>> l
>>>>>>> pe
>>>>>>> r.java:70)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>>>> g
>>>>>>> a
>>>>>>> te
>>>>>>> AsyncProcessor.java:98)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>>>> A
>>>>>>> s
>>>>>>> yn
>>>>>>> cProcessor.java:89)
>>>>>>> at
>>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.process(Tr
>>>>>>> a
>>>>>>> c
>>>>>>> eI
>>>>>>> nterceptor.java:99)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>>> e
>>>>>>> l
>>>>>>> pe
>>>>>>> r.java:70)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>>>> g
>>>>>>> a
>>>>>>> te
>>>>>>> AsyncProcessor.java:98)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>>>> A
>>>>>>> s
>>>>>>> yn
>>>>>>> cProcessor.java:89)
>>>>>>> at
>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Instr
>>>>>>> u
>>>>>>> m
>>>>>>> en
>>>>>>> tationProcessor.java:68)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>>> e
>>>>>>> l
>>>>>>> pe
>>>>>>> r.java:70)
>>>>>>> at
>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHand
>>>>>>> l
>>>>>>> e
>>>>>>> r(
>>>>>>> RedeliveryErrorHandler.java:290)
>>>>>>> at
>>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Redelive
>>>>>>> r
>>>>>>> y
>>>>>>> Er
>>>>>>> rorHandler.java:202)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>>> 256)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>>> e
>>>>>>> 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(UnitOfWorkP
>>>>>>> r
>>>>>>> o
>>>>>>> ce
>>>>>>> ssor.java:99)
>>>>>>> at
>>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>>> e
>>>>>>> l
>>>>>>> pe
>>>>>>> r.java:70)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>>>> g
>>>>>>> a
>>>>>>> te
>>>>>>> AsyncProcessor.java:98)
>>>>>>> at
>>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>>>> A
>>>>>>> s
>>>>>>> yn
>>>>>>> cProcessor.java:89)
>>>>>>> at
>>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Instr
>>>>>>> u
>>>>>>> m
>>>>>>> en
>>>>>>> tationProcessor.java:68)
>>>>>>> at
>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelProv
>>>>>>> i
>>>>>>> d
>>>>>>> er
>>>>>>> Endpoint.java:109)
>>>>>>> at
>>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassLoa
>>>>>>> d
>>>>>>> e
>>>>>>> r(
>>>>>>> JbiBinding.java:116)
>>>>>>> at
>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveProv
>>>>>>> i
>>>>>>> d
>>>>>>> er
>>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>>> at
>>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelPro
>>>>>>> v
>>>>>>> i
>>>>>>> de
>>>>>>> rEndpoint.java:85)
>>>>>>> at
>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBas
>>>>>>> e
>>>>>>> L
>>>>>>> if
>>>>>>> eCycle.java:651)
>>>>>>> at
>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(As
>>>>>>> y
>>>>>>> n
>>>>>>> cB
>>>>>>> aseLifeCycle.java:606)
>>>>>>> at
>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInT
>>>>>>> x
>>>>>>> (
>>>>>>> As
>>>>>>> yncBaseLifeCycle.java:501)
>>>>>>> at
>>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLif
>>>>>>> e
>>>>>>> C
>>>>>>> yc
>>>>>>> le.java:370)
>>>>>>> at
>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolE
>>>>>>> x
>>>>>>> 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:freeman.fang@gmail.com]
>>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>>> To: users@servicemix.apache.org
>>>>>>> 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: cibsen@fusesource.com
>>>>>> 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: cibsen@fusesource.com
>>>>> 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: cibsen@fusesource.com
>>>> 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: cibsen@fusesource.com
>> 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
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jan 19, 2011 at 2:26 PM, Scott Came <sc...@search.org> wrote:
> OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From the log messages I included in my message yesterday, it looks like my install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log message: >>>> 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.)
>
> Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
>
> If not, is there something else that's causing the type converters not to get loaded?
>
Its this bug which was fixed dec-20-2010
http://fusesource.com/issues/browse/MR-392
And -03 hasn't been released yet.
> Thanks for all your help...
> --Scott
>
> -----Original Message-----
> From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Sent: Wednesday, January 19, 2011 5:14 AM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> On Wed, Jan 19, 2011 at 1:59 PM, Scott Came <sc...@search.org> 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:willem.jiang@gmail.com]
>> Sent: Wednesday, January 19, 2011 2:02 AM
>> To: users@servicemix.apache.org
>> 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:scott.came@search.org]
>>> Sent: Tuesday, January 18, 2011 12:33 PM
>>> To: users@servicemix.apache.org
>>> 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:claus.ibsen@gmail.com]
>>> Sent: Tuesday, January 18, 2011 7:56 AM
>>> To: users@servicemix.apache.org
>>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>>
>>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>>> To: users@servicemix.apache.org
>>>>> 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<sc...@search.org> 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.ja
>>>>>> v
>>>>>> 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(Fra
>>>>>> g
>>>>>> m
>>>>>> en
>>>>>> tStreamReader.java:68)
>>>>>> at
>>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(StaxJ
>>>>>> b
>>>>>> 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(MessageSuppo
>>>>>> r
>>>>>> t
>>>>>> .j
>>>>>> ava:103)
>>>>>> at
>>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(ConvertBod
>>>>>> y
>>>>>> P
>>>>>> ro
>>>>>> cessor.java:57)
>>>>>> at
>>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Proces
>>>>>> s
>>>>>> o
>>>>>> rT
>>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>>> at
>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>> e
>>>>>> l
>>>>>> pe
>>>>>> r.java:70)
>>>>>> at
>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>>> g
>>>>>> a
>>>>>> te
>>>>>> AsyncProcessor.java:98)
>>>>>> at
>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>>> A
>>>>>> s
>>>>>> yn
>>>>>> cProcessor.java:89)
>>>>>> at
>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Instr
>>>>>> u
>>>>>> m
>>>>>> en
>>>>>> tationProcessor.java:68)
>>>>>> at
>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>> e
>>>>>> l
>>>>>> pe
>>>>>> r.java:70)
>>>>>> at
>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>>> g
>>>>>> a
>>>>>> te
>>>>>> AsyncProcessor.java:98)
>>>>>> at
>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>>> A
>>>>>> s
>>>>>> yn
>>>>>> cProcessor.java:89)
>>>>>> at
>>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.process(Tr
>>>>>> a
>>>>>> c
>>>>>> eI
>>>>>> nterceptor.java:99)
>>>>>> at
>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>> e
>>>>>> l
>>>>>> pe
>>>>>> r.java:70)
>>>>>> at
>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>>> g
>>>>>> a
>>>>>> te
>>>>>> AsyncProcessor.java:98)
>>>>>> at
>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>>> A
>>>>>> s
>>>>>> yn
>>>>>> cProcessor.java:89)
>>>>>> at
>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Instr
>>>>>> u
>>>>>> m
>>>>>> en
>>>>>> tationProcessor.java:68)
>>>>>> at
>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>> e
>>>>>> l
>>>>>> pe
>>>>>> r.java:70)
>>>>>> at
>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHand
>>>>>> l
>>>>>> e
>>>>>> r(
>>>>>> RedeliveryErrorHandler.java:290)
>>>>>> at
>>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Redelive
>>>>>> r
>>>>>> y
>>>>>> Er
>>>>>> rorHandler.java:202)
>>>>>> at
>>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>>> 256)
>>>>>> at
>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>> e
>>>>>> 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(UnitOfWorkP
>>>>>> r
>>>>>> o
>>>>>> ce
>>>>>> ssor.java:99)
>>>>>> at
>>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>>> e
>>>>>> l
>>>>>> pe
>>>>>> r.java:70)
>>>>>> at
>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>>> g
>>>>>> a
>>>>>> te
>>>>>> AsyncProcessor.java:98)
>>>>>> at
>>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>>> A
>>>>>> s
>>>>>> yn
>>>>>> cProcessor.java:89)
>>>>>> at
>>>>>> org.apache.camel.management.InstrumentationProcessor.process(Instr
>>>>>> u
>>>>>> m
>>>>>> en
>>>>>> tationProcessor.java:68)
>>>>>> at
>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelProv
>>>>>> i
>>>>>> d
>>>>>> er
>>>>>> Endpoint.java:109)
>>>>>> at
>>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassLoa
>>>>>> d
>>>>>> e
>>>>>> r(
>>>>>> JbiBinding.java:116)
>>>>>> at
>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveProv
>>>>>> i
>>>>>> d
>>>>>> er
>>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>>> at
>>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelPro
>>>>>> v
>>>>>> i
>>>>>> de
>>>>>> rEndpoint.java:85)
>>>>>> at
>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBas
>>>>>> e
>>>>>> L
>>>>>> if
>>>>>> eCycle.java:651)
>>>>>> at
>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(As
>>>>>> y
>>>>>> n
>>>>>> cB
>>>>>> aseLifeCycle.java:606)
>>>>>> at
>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInT
>>>>>> x
>>>>>> (
>>>>>> As
>>>>>> yncBaseLifeCycle.java:501)
>>>>>> at
>>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLif
>>>>>> e
>>>>>> C
>>>>>> yc
>>>>>> le.java:370)
>>>>>> at
>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolE
>>>>>> x
>>>>>> 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:freeman.fang@gmail.com]
>>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>>> To: users@servicemix.apache.org
>>>>>> 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: cibsen@fusesource.com
>>>>> 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: cibsen@fusesource.com
>>>> 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: cibsen@fusesource.com
>>> 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: cibsen@fusesource.com
> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
OK I'm confused... I have Fuse ESB 4.3.0-03-00 installed. From the log messages I included in my message yesterday, it looks like my install includes Camel Fuse 2.4.0.fuse-02-00. (Reference log message: >>>> 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.)
Do I need Camel Fuse 2.4.0.fuse-03-00 to get the fix, and if so is that now available in the Fuse ESB 4.3.0-03-00 download (I just installed ESB 4.3.0-03-00 late last week)?
If not, is there something else that's causing the type converters not to get loaded?
Thanks for all your help...
--Scott
-----Original Message-----
From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
Sent: Wednesday, January 19, 2011 5:14 AM
To: users@servicemix.apache.org
Subject: Re: Large(ish) message issue (CXFBC and Camel)
On Wed, Jan 19, 2011 at 1:59 PM, Scott Came <sc...@search.org> 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:willem.jiang@gmail.com]
> Sent: Wednesday, January 19, 2011 2:02 AM
> To: users@servicemix.apache.org
> 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:scott.came@search.org]
>> Sent: Tuesday, January 18, 2011 12:33 PM
>> To: users@servicemix.apache.org
>> 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:claus.ibsen@gmail.com]
>> Sent: Tuesday, January 18, 2011 7:56 AM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>> To: users@servicemix.apache.org
>>>> 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<sc...@search.org> 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.ja
>>>>> v
>>>>> 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(Fra
>>>>> g
>>>>> m
>>>>> en
>>>>> tStreamReader.java:68)
>>>>> at
>>>>> org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(StaxJ
>>>>> b
>>>>> 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(MessageSuppo
>>>>> r
>>>>> t
>>>>> .j
>>>>> ava:103)
>>>>> at
>>>>> org.apache.camel.processor.ConvertBodyProcessor.process(ConvertBod
>>>>> y
>>>>> P
>>>>> ro
>>>>> cessor.java:57)
>>>>> at
>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Proces
>>>>> s
>>>>> o
>>>>> rT
>>>>> oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
>>>>> at
>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>> e
>>>>> l
>>>>> pe
>>>>> r.java:70)
>>>>> at
>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>> g
>>>>> a
>>>>> te
>>>>> AsyncProcessor.java:98)
>>>>> at
>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>> A
>>>>> s
>>>>> yn
>>>>> cProcessor.java:89)
>>>>> at
>>>>> org.apache.camel.management.InstrumentationProcessor.process(Instr
>>>>> u
>>>>> m
>>>>> en
>>>>> tationProcessor.java:68)
>>>>> at
>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>> e
>>>>> l
>>>>> pe
>>>>> r.java:70)
>>>>> at
>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>> g
>>>>> a
>>>>> te
>>>>> AsyncProcessor.java:98)
>>>>> at
>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>> A
>>>>> s
>>>>> yn
>>>>> cProcessor.java:89)
>>>>> at
>>>>> org.apache.camel.processor.interceptor.TraceInterceptor.process(Tr
>>>>> a
>>>>> c
>>>>> eI
>>>>> nterceptor.java:99)
>>>>> at
>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>> e
>>>>> l
>>>>> pe
>>>>> r.java:70)
>>>>> at
>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>> g
>>>>> a
>>>>> te
>>>>> AsyncProcessor.java:98)
>>>>> at
>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>> A
>>>>> s
>>>>> yn
>>>>> cProcessor.java:89)
>>>>> at
>>>>> org.apache.camel.management.InstrumentationProcessor.process(Instr
>>>>> u
>>>>> m
>>>>> en
>>>>> tationProcessor.java:68)
>>>>> at
>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>> e
>>>>> l
>>>>> pe
>>>>> r.java:70)
>>>>> at
>>>>> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHand
>>>>> l
>>>>> e
>>>>> r(
>>>>> RedeliveryErrorHandler.java:290)
>>>>> at
>>>>> org.apache.camel.processor.RedeliveryErrorHandler.process(Redelive
>>>>> r
>>>>> y
>>>>> Er
>>>>> rorHandler.java:202)
>>>>> at
>>>>> org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
>>>>> 256)
>>>>> at
>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>> e
>>>>> 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(UnitOfWorkP
>>>>> r
>>>>> o
>>>>> ce
>>>>> ssor.java:99)
>>>>> at
>>>>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorH
>>>>> e
>>>>> l
>>>>> pe
>>>>> r.java:70)
>>>>> at
>>>>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(Dele
>>>>> g
>>>>> a
>>>>> te
>>>>> AsyncProcessor.java:98)
>>>>> at
>>>>> org.apache.camel.processor.DelegateAsyncProcessor.process(Delegate
>>>>> A
>>>>> s
>>>>> yn
>>>>> cProcessor.java:89)
>>>>> at
>>>>> org.apache.camel.management.InstrumentationProcessor.process(Instr
>>>>> u
>>>>> m
>>>>> en
>>>>> tationProcessor.java:68)
>>>>> at
>>>>> org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelProv
>>>>> i
>>>>> d
>>>>> er
>>>>> Endpoint.java:109)
>>>>> at
>>>>> org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassLoa
>>>>> d
>>>>> e
>>>>> r(
>>>>> JbiBinding.java:116)
>>>>> at
>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveProv
>>>>> i
>>>>> d
>>>>> er
>>>>> Exchange(CamelProviderEndpoint.java:107)
>>>>> at
>>>>> org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelPro
>>>>> v
>>>>> i
>>>>> de
>>>>> rEndpoint.java:85)
>>>>> at
>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBas
>>>>> e
>>>>> L
>>>>> if
>>>>> eCycle.java:651)
>>>>> at
>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(As
>>>>> y
>>>>> n
>>>>> cB
>>>>> aseLifeCycle.java:606)
>>>>> at
>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInT
>>>>> x
>>>>> (
>>>>> As
>>>>> yncBaseLifeCycle.java:501)
>>>>> at
>>>>> org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLif
>>>>> e
>>>>> C
>>>>> yc
>>>>> le.java:370)
>>>>> at
>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolE
>>>>> x
>>>>> 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:freeman.fang@gmail.com]
>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>> To: users@servicemix.apache.org
>>>>> 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: cibsen@fusesource.com
>>>> 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: cibsen@fusesource.com
>>> 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: cibsen@fusesource.com
>> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jan 19, 2011 at 1:59 PM, Scott Came <sc...@search.org> 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:willem.jiang@gmail.com]
> Sent: Wednesday, January 19, 2011 2:02 AM
> To: users@servicemix.apache.org
> 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:scott.came@search.org]
>> Sent: Tuesday, January 18, 2011 12:33 PM
>> To: users@servicemix.apache.org
>> 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:claus.ibsen@gmail.com]
>> Sent: Tuesday, January 18, 2011 7:56 AM
>> To: users@servicemix.apache.org
>> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>>
>> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>>> Sent: Monday, January 17, 2011 10:05 PM
>>>> To: users@servicemix.apache.org
>>>> 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<sc...@search.org> 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:freeman.fang@gmail.com]
>>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>>> To: users@servicemix.apache.org
>>>>> 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: cibsen@fusesource.com
>>>> 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: cibsen@fusesource.com
>>> 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: cibsen@fusesource.com
>> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
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:willem.jiang@gmail.com]
Sent: Wednesday, January 19, 2011 2:02 AM
To: users@servicemix.apache.org
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:scott.came@search.org]
> Sent: Tuesday, January 18, 2011 12:33 PM
> To: users@servicemix.apache.org
> 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:claus.ibsen@gmail.com]
> Sent: Tuesday, January 18, 2011 7:56 AM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>> Sent: Monday, January 17, 2011 10:05 PM
>>> To: users@servicemix.apache.org
>>> 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<sc...@search.org> 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:freeman.fang@gmail.com]
>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>> To: users@servicemix.apache.org
>>>> 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: cibsen@fusesource.com
>>> 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: cibsen@fusesource.com
>> 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: cibsen@fusesource.com
> 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
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Willem Jiang <wi...@gmail.com>.
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:scott.came@search.org]
> Sent: Tuesday, January 18, 2011 12:33 PM
> To: users@servicemix.apache.org
> 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:claus.ibsen@gmail.com]
> Sent: Tuesday, January 18, 2011 7:56 AM
> To: users@servicemix.apache.org
> Subject: Re: Large(ish) message issue (CXFBC and Camel)
>
> On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<cl...@gmail.com> wrote:
>> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<sc...@search.org> 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:claus.ibsen@gmail.com]
>>> Sent: Monday, January 17, 2011 10:05 PM
>>> To: users@servicemix.apache.org
>>> 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<sc...@search.org> 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:freeman.fang@gmail.com]
>>>> Sent: Monday, January 17, 2011 7:08 PM
>>>> To: users@servicemix.apache.org
>>>> 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: cibsen@fusesource.com
>>> 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: cibsen@fusesource.com
>> 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: cibsen@fusesource.com
> 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
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
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:scott.came@search.org]
Sent: Tuesday, January 18, 2011 12:33 PM
To: users@servicemix.apache.org
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:claus.ibsen@gmail.com]
Sent: Tuesday, January 18, 2011 7:56 AM
To: users@servicemix.apache.org
Subject: Re: Large(ish) message issue (CXFBC and Camel)
On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came <sc...@search.org> 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:claus.ibsen@gmail.com]
>> Sent: Monday, January 17, 2011 10:05 PM
>> To: users@servicemix.apache.org
>> 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 <sc...@search.org> 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:freeman.fang@gmail.com]
>>> Sent: Monday, January 17, 2011 7:08 PM
>>> To: users@servicemix.apache.org
>>> 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: cibsen@fusesource.com
>> 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: cibsen@fusesource.com
> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
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:claus.ibsen@gmail.com]
Sent: Tuesday, January 18, 2011 7:56 AM
To: users@servicemix.apache.org
Subject: Re: Large(ish) message issue (CXFBC and Camel)
On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came <sc...@search.org> 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:claus.ibsen@gmail.com]
>> Sent: Monday, January 17, 2011 10:05 PM
>> To: users@servicemix.apache.org
>> 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 <sc...@search.org> 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:freeman.fang@gmail.com]
>>> Sent: Monday, January 17, 2011 7:08 PM
>>> To: users@servicemix.apache.org
>>> 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: cibsen@fusesource.com
>> 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: cibsen@fusesource.com
> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Tue, Jan 18, 2011 at 4:18 PM, Scott Came <sc...@search.org> 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:claus.ibsen@gmail.com]
>> Sent: Monday, January 17, 2011 10:05 PM
>> To: users@servicemix.apache.org
>> 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 <sc...@search.org> 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:freeman.fang@gmail.com]
>>> Sent: Monday, January 17, 2011 7:08 PM
>>> To: users@servicemix.apache.org
>>> 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: cibsen@fusesource.com
>> 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: cibsen@fusesource.com
> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jan 18, 2011 at 4:18 PM, Scott Came <sc...@search.org> 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:claus.ibsen@gmail.com]
> Sent: Monday, January 17, 2011 10:05 PM
> To: users@servicemix.apache.org
> 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 <sc...@search.org> 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:freeman.fang@gmail.com]
>> Sent: Monday, January 17, 2011 7:08 PM
>> To: users@servicemix.apache.org
>> 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: cibsen@fusesource.com
> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
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.
Thanks for your help.
--Scott
-----Original Message-----
From: Claus Ibsen [mailto:claus.ibsen@gmail.com]
Sent: Monday, January 17, 2011 10:05 PM
To: users@servicemix.apache.org
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 <sc...@search.org> 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:freeman.fang@gmail.com]
> Sent: Monday, January 17, 2011 7:08 PM
> To: users@servicemix.apache.org
> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Claus Ibsen <cl...@gmail.com>.
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 <sc...@search.org> 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:freeman.fang@gmail.com]
> Sent: Monday, January 17, 2011 7:08 PM
> To: users@servicemix.apache.org
> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
RE: Large(ish) message issue (CXFBC and Camel)
Posted by Scott Came <sc...@search.org>.
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:freeman.fang@gmail.com]
Sent: Monday, January 17, 2011 7:08 PM
To: users@servicemix.apache.org
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
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Johan Edstrom <je...@savoirtech.com>.
> <from uri="jbi:endpoint:http://it.ojp.gov/global/services/tsc-encounter-router/RouterService/RouterServiceEndpoint"/>
Would consume the inputstream.
On Jan 17, 2011, at 8:08 PM, Freeman Fang wrote:
>> <from uri="jbi:endpoint:http://it.ojp.gov/global/services/tsc-encounter-router/RouterService/RouterServiceEndpoint"/>
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Freeman Fang <fr...@gmail.com>.
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-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>
>
> 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
Re: Large(ish) message issue (CXFBC and Camel)
Posted by Willem Jiang <wi...@gmail.com>.
On 1/18/11 10:41 AM, 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-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>
Can you try to move the <convertBodyTo type="java.lang.String"/>
before the
<to uri="log:gov.ojp.it.TSCEncounterRouterLog?showBody=false"/>
Just 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-router/RouterService/RouterServiceEndpoint"/>
<convertBodyTo type="java.lang.String"/>
<to uri="log:gov.ojp.it.TSCEncounterRouterLog?showBody=false"/>
<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.
>
> 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
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang