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
