Thanks for the hints,
you are right here are the cxf part/ to-part of route:
rtdmProcess.to(rtdmEndpoint).to(tpLoggerToRtdm).process(handleRtdmAnswer).to(tpLoggerFromRtdm)
rtdmEndpoint is cxf
it is created this way:
CxfEndpoint endpoint = new CxfEndpoint(rtdmUrl, new
CxfComponent(context));
endpoint.setServiceClass(EventPortType.class);
My guess is that the cause of stackoverflow could be, that on the one hand
we take zipped/jsoned file with 1000 object in each and send this to soap,
and on the other hand for some reason (problem on soap server side) we get
an Fault for every message. This combination - 1000 in a row and Fault
("handled" by custom error handler) fills up the stack.
-Xss256 could be a solution. But i want to be sure or at least need some
evidence that stack size correlates to our file size/ messages per file and
the faults (we never saw this problem even with much bigger files)
Are there any hints you can give on how to monitor (probably with some jmx
metrics camel/cxf/errorhandlers offers) stack size or work load?
--
View this message in context:
http://camel.465427.n5.nabble.com/StackOverflowException-for-route-using-cxf-component-sending-to-soap-endpoint-tp5764460p5764630.html
Sent from the Camel - Users mailing list archive at Nabble.com.
