Why don't you just download the Fuse ESB 4.3.0-fuse-03-00?
You don't need to build the component yourself.
On 1/19/11 10:34 AM, Scott Came wrote:
I've actually succeeded in building the 2011.01-SNAPSHOT version of
servicemix-camel that's in SVN. I have the component .jar and installer .zip
in my local maven repository now.
Any reason why I shouldn't be able to install that in
servicemix-4.3.0-fuse-03-00? Do I just drop the zip file in the deploy
directory? Do I need to be worried about conflicts with the currently
installed version of Camel (i.e., should I uninstall)?
Excuse the newbie questions...is there a way to deploy this snapshot via the
features mechanism?
Anyway, if I can get this going I'd be happy to testdrive the 2011.01-SNAPSHOT
build of servicemix-camel...
Thanks.
--Scott
-----Original Message-----
From: Scott Came [mailto:[email protected]]
Sent: Tuesday, January 18, 2011 12:33 PM
To: [email protected]
Subject: RE: Large(ish) message issue (CXFBC and Camel)
Thanks, Claus. Is there anything I can do in the meantime? Is the fix in a
current Camel build? If so, are there docs on how to update the Camel
components in SM?
--Scott
-----Original Message-----
From: Claus Ibsen [mailto:[email protected]]
Sent: Tuesday, January 18, 2011 7:56 AM
To: [email protected]
Subject: Re: Large(ish) message issue (CXFBC and Camel)
On Tue, Jan 18, 2011 at 4:54 PM, Claus Ibsen<[email protected]> wrote:
On Tue, Jan 18, 2011 at 4:18 PM, Scott Came<[email protected]> wrote:
Thanks, Claus.
I grepped my logs for AnnotationTypeConverterLoader and see a line like this:
16:52:10,678 | INFO | @qtp-727842206-0 |
AnnotationTypeConverterLoader | er.AnnotationTypeConverterLoader
66 | 72 - org.apache.camel.camel-core - 2.4.0.fuse-02-00 | Found 3
packages with 0 @Converter classes to load
Grepped for DefaultTypeConverter and see this:
16:52:10,680 | INFO | @qtp-727842206-0 | DefaultTypeConverter
| l.converter.DefaultTypeConverter 397 | 72 -
org.apache.camel.camel-core - 2.4.0.fuse-02-00 | Loaded 0 type
converters in 0.003 seconds
I'm guessing that's not good. I am running the current release version of FUSE
ESB (apache-servicemix-4.3.0-fuse-03-00). I'm not sure what version of Camel
is included, but I haven't done anything to update Camel outside of the stock
FUSE ESB distro. It looks from the above log message like it's Camel
2.4.0.fuse-02-00.
Yeah it should be fixed in FUSE ESB 4.3.1 which includes Camel
2.4.0-fuse-03-00 which has the fix.
Correction, that would be the next FUSE ESB 4.3.0 release.
I think there is a ESB 4.3.1 planned later this month/next month which will
ship with Camel 2.6 (currently in progress).
From Camel 2.6 onwards we actually now will throw an exception on
starting Camel if this situation happens again.
Then it should be much easier for end user to spot something is wrong.
Thanks for your help.
--Scott
-----Original Message-----
From: Claus Ibsen [mailto:[email protected]]
Sent: Monday, January 17, 2011 10:05 PM
To: [email protected]
Subject: Re: Large(ish) message issue (CXFBC and Camel)
What versions of the products are you using? SMX / Camel?
And how do you startup the SMX container?
I think there was a bug when using JBI with SMX 4.x that could lead to Camel
not being able to load type converters on startup (race condition when using
OSGi). This should be fixed in upcoming Apache SMX 4.3 release and already in
the latest FUSE ESB release.
You should see something like this at INFO level logged by Camel on
startup (requires Camel 2.3 or better)
2011-01-18 07:05:00,519 [main ] INFO
AnnotationTypeConverterLoader - Found 3 packages with 19 @Converter
classes to load
2011-01-18 07:05:00,567 [main ] INFO DefaultTypeConverter
- Loaded 150 type converters in 1.038 seconds
On Tue, Jan 18, 2011 at 5:42 AM, Scott Came<[email protected]> wrote:
Hi Freeman, thanks for the suggestion.
I tried that and am seeing the same results. After consulting the Camel documentation about stream caching
at http://camel.apache.org/stream-caching.html I tried various flavors of specifying it (e.g., specifying
streamCache="true" on camelContext and streamCaching="true" and
streamCache="true" on route)...none of those helped.
I also tried removing the<to> element for the log message, and that didn't
help either.
It's like in the case of both<to uri="log..."> and<to uri="file..."> the
stream from the jbi: endpoint is getting cut off after 1000-2000 bytes. Very strange.
I set the log level to DEBUG, and I get a big nested stack trace at the
expected place, with this as the last exception listed:
Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected end of
input block in start tag
at [row,col {unknown-source}]: [51,20]
at
com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOB(StreamScanner.java:
69
6)
at
com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java
:1
062)
at
com.ctc.wstx.sr.StreamScanner.getNextCharFromCurrent(StreamScanner.j
av
a:807)
at
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.
ja
va:2892)
at
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:
2783)
at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1048)
at
org.apache.servicemix.soap.util.stax.FragmentStreamReader.next(Fragm
en
tStreamReader.java:68)
at
org.apache.servicemix.cxfbc.interceptors.StaxJbiWrapper.next(StaxJbi
Wr
apper.java:166)
at
org.apache.servicemix.soap.util.stax.StaxSource.parse(StaxSource.java:
116)
... 54 more
Incidentally, the first exception (top of the stack) is this:
org.apache.camel.InvalidPayloadException: No body available of type:
java.lang.String but has value:
org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207 of type:
org.apache.servicemix.soap.util.stax.StaxSource on: Message:
org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207. Caused by:
No type converter available to convert from type:
org.apache.servicemix.soap.util.stax.StaxSource to the required type:
java.lang.String with value
org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207.
Exchange[Message:
org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207]. Caused by:
[org.apache.camel.NoTypeConversionAvailableException - No type
converter available to convert from type:
org.apache.servicemix.soap.util.stax.StaxSource to the required type:
java.lang.String with value
org.apache.servicemix.soap.util.stax.StaxSource@4f6a4207]
at
org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSupport
.j
ava:103)
at
org.apache.camel.processor.ConvertBodyProcessor.process(ConvertBodyP
ro
cessor.java:57)
at
org.apache.camel.impl.converter.AsyncProcessorTypeConverter$Processo
rT
oAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:50)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel
pe
r.java:70)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delega
te
AsyncProcessor.java:98)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAs
yn
cProcessor.java:89)
at
org.apache.camel.management.InstrumentationProcessor.process(Instrum
en
tationProcessor.java:68)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel
pe
r.java:70)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delega
te
AsyncProcessor.java:98)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAs
yn
cProcessor.java:89)
at
org.apache.camel.processor.interceptor.TraceInterceptor.process(Trac
eI
nterceptor.java:99)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel
pe
r.java:70)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delega
te
AsyncProcessor.java:98)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAs
yn
cProcessor.java:89)
at
org.apache.camel.management.InstrumentationProcessor.process(Instrum
en
tationProcessor.java:68)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel
pe
r.java:70)
at
org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandle
r(
RedeliveryErrorHandler.java:290)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(Redelivery
Er
rorHandler.java:202)
at
org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:
256)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel
pe
r.java:70)
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:143)
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:78)
at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkPro
ce
ssor.java:99)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHel
pe
r.java:70)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(Delega
te
AsyncProcessor.java:98)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAs
yn
cProcessor.java:89)
at
org.apache.camel.management.InstrumentationProcessor.process(Instrum
en
tationProcessor.java:68)
at
org.apache.servicemix.camel.CamelProviderEndpoint$1.call(CamelProvid
er
Endpoint.java:109)
at
org.apache.servicemix.camel.JbiBinding.runWithCamelContextClassLoade
r(
JbiBinding.java:116)
at
org.apache.servicemix.camel.CamelProviderEndpoint.handleActiveProvid
er
Exchange(CamelProviderEndpoint.java:107)
at
org.apache.servicemix.camel.CamelProviderEndpoint.process(CamelProvi
de
rEndpoint.java:85)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseL
if
eCycle.java:651)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(Asyn
cB
aseLifeCycle.java:606)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchangeInTx(
As
yncBaseLifeCycle.java:501)
at
org.apache.servicemix.common.AsyncBaseLifeCycle$2.run(AsyncBaseLifeC
yc
le.java:370)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExe
cu
tor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
java:908)
at java.lang.Thread.run(Thread.java:680)
Any other ideas?
Thanks.
--Scott
-----Original Message-----
From: Freeman Fang [mailto:[email protected]]
Sent: Monday, January 17, 2011 7:08 PM
To: [email protected]
Subject: Re: Large(ish) message issue (CXFBC and Camel)
On 2011-1-18, at 上午10:41, Scott Came wrote:
I am seeing some strange behavior when using Camel to route from a
JBI endpoint (cxfbc) to a file using the Camel file component.
Here is the scenario.
I have created a JBI CXFBC service unit with WSDL. I have also
created a Camel service unit, with a very simple route: it routes
from the CXFBC endpoint to a file with a route that looks like this:
<camelContext id="camel" xmlns="http://camel.apache.org/schema/
spring">
<route>
<from
uri="jbi:endpoint:http://it.ojp.gov/global/services/tsc-encounter-r
ou t er/RouterService/RouterServiceEndpoint
"/>
<to
uri="log:gov.ojp.it.TSCEncounterRouterLog?showBody=false"/>
<convertBodyTo type="java.lang.String"/>
<to uri="file:/Users/scott/Desktop/router-output"/>
</route>
</camelContext>
I bundle these to SUs into an SA and deploy. Everything deploys fine.
I then use SOAPUI to send test messages.
If I send a very small message...say, no bigger than a couple
hundred bytes, to the RouterServiceEndpoint, everything works fine.
I see the log message in the log, and the file gets written to my
router-output directory.
However, when I increase the message size beyond a certain point
(not sure exactly where it is...somewhere around 2000-3000 bytes) I
start getting messages like:
Unexpected end of input block in start tag at [row,col {unknown-
source}]: [51,20]
The underlying exception seems to be a
com.ctc.wstx.exc.WstcEOFException.
If I try subsequent invocations of the service, I get a similar
error, though the referenced place in the stream is often a little
different (e.g., [51, 25] or [55, 10]). So it seems like the
parser is getting to a different place in the stream each time before it fails.
I have put TCPMon in the middle and verified that the entire
message is getting to the server, although the server side is not
closing the connection when the exception occurs.
I am 100% sure the content being sent is valid XML.
Interestingly, if I take out the<to> part of the route to the file
component, everything works fine...I get the simple log message
(note that I am not logging the body content), and the connection
closes in TCPMon. However, if I switch to logging the body content
(i.e., take off the ?showBody=false option), I get similar errors
as when I try to write out the file.
This looks like a stream already get consumed issue for me, how
about you just
How about you just change your router like<camelContext id="camel"
xmlns="http://camel.apache.org/schema/spring";>
<route streamCache="true">
<from
uri="jbi:endpoint:http://it.ojp.gov/global/services/tsc-encounter-ro
ut er/RouterService/RouterServiceEndpoint
"/>
<to uri="log:gov.ojp.it.TSCEncounterRouterLog?showBody=false"/>
<convertBodyTo type="java.lang.String"/>
<to uri="file:/Users/scott/Desktop/router-output"/>
</route>
</camelContext>
Freeman
I have tried taking out the<convertBodyTo...> element, but that
results in a different exception...something about no appropriate
converter being found.
It would be somewhat difficult for me to attach a full example, as
the content of the large message is somewhat sensitive/proprietary,
but I could do that if I absolutely needed to. I'm hoping there is
some simple configuration setting I need to tweak to handle bigger
messages (though a 2K or 3K message is by no means large...)
Thanks for any help you can offer.
--Scott
--
Freeman Fang
------------------------
FuseSource: http://fusesource.com
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang Apache
Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org Apache Felix:
http://felix.apache.org
--
Claus Ibsen
-----------------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
--
Claus Ibsen
-----------------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
--
Claus Ibsen
-----------------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
