I suspect your http client to close the connection.
servicemix-http directly pass the http input stream for performance reasons,
so
if the client closes the connection because you debug for too long, the
stream will be closed.
I can' t think of any workaround for that, but we could add a flag on the
consumer endpoint
and component config to force parsing the input stream as a DOM node. This
can be
done easily, as the code is already there (it's needed for ws-security).
Please raise
a JIRA and attach your patch ;)
On 8/11/06, Peter Klotz <[EMAIL PROTECTED]> wrote:
Hi,
I have a very strange effect with sendSync() inside a servicemix component
that
inherites from ComponentSupport:
---
...
InOut getexch = createInOutExchange(target, null, null);
NormalizedMessage getreq = getexch.createMessage();
getexch.setInMessage(getreq);
getreq.setContent(new SourceTransformer().toStreamSourceFromSAX(new
JDOMSource(doc)));
// send request syncchronous
boolean rc = sendSync(getexch);
if (rc)
{
NormalizedMessage getresp = getexch.getOutMessage(); // getresp
is null
here!
if (getresp != null)
{
...
---
When stepping through the code in the debugger, everything works fine!
When setting a breakpoint before and after and have the debugger/or the
normal
execution run through it the sendSync() seems to return immediately and
does not
have a out message in it.
in the logfile one gets this message in that case:
----
...
ERROR - 2006-08-11 16:41:12,754 | BaseLifeCycle.onMessageExchange(45) |
Error
processing exchange null
com.ctc.wstx.exc.WstxIOException: Stream closed
at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(
WstxInputFactory.java:539)
at com.ctc.wstx.stax.WstxInputFactory.createSR(
WstxInputFactory.java:592)
at com.ctc.wstx.stax.WstxInputFactory.createSR(
WstxInputFactory.java:648)
at
com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(
WstxInputFactory.java:322)
at
org.apache.servicemix.jbi.jaxp.StAXSourceTransformer.toXMLStreamReader(
StAXSourceTransformer.java:79)
at
org.apache.servicemix.soap.marshalers.SoapWriter.writeContents(
SoapWriter.java:197)
at
org.apache.servicemix.soap.marshalers.SoapWriter.writeSimpleMessage(
SoapWriter.java:113)
at
org.apache.servicemix.soap.marshalers.SoapWriter.write(SoapWriter.java:82)
at
org.apache.servicemix.http.processors.ProviderProcessor.writeMessage(
ProviderProcessor.java:248)
at
org.apache.servicemix.http.processors.ProviderProcessor.process(
ProviderProcessor.java:115)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(
AsyncBaseLifeCycle.java:398)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(
BaseLifeCycle.java:43)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(
DeliveryChannelImpl.java:623)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(
AbstractFlow.java:169)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java
:177)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java
:227)
at
org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java
:291)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run
(Unknown
Source)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException: Stream closed
at java.io.StringReader.ensureOpen(StringReader.java:39)
at java.io.StringReader.read(StringReader.java:73)
at
com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java
:240)
at
com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java
:127)
at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(
WstxInputFactory.java:534)
... 18 more
...
---
We went to SM snapshot from the 10th of August but still the same
behaviour!
It looks like when stepping over the sendSync in the debugger it has more
time
or waits until the response is received and in the normal case does not
wait on
the response and thus the stream is closed?
The target is definitively correct and working with a InOut ME.
Any idea for such a strange behaviour? Anything we do wrong here?
Thanks, Peter
--
Cheers,
Guillaume Nodet
