On 8/11/06, Peter Klotz <[EMAIL PROTECTED]> wrote:
Hi Guillaume, but wait, the thing is the other way round, in the debugger it works, without debugger it does not and throw the exception. Well it is true that there is a timeout when I'm too long in the debugger but this is not this exception that I'm talking about, this exception occurs without debugger. Furthermore, the sendSync() is done from another ME but the target service where the ME is send to with sendSync has nothing to do with servicemix-http, it is in one case a service in the same process.
You need to take great care when using streams. Some components may not really support that correctly. Does something change if you put debug logging on / off ? Because the NMR will display the content of the exchanges and needs to convert them to re-readable xml sources to do that. BTW, is there a way to influence the timeout that the server has? When there
is a longer lasting ME it seems that the server cuts the connection, which is not desired in a req/resp interaction?
I experienced this behavior, but this was the client which close the connection. commons-httpclient does that and retry 2 times. I guess this is configurable somewhere... Guillaume Nodet wrote:
> 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 ;) >
-- Cheers, Guillaume Nodet
