Oleg, thanks a lot for your reply! Please see my comments inline!
> > The problem is I don't understand the cause of this exception. It occurs > during the read on a Socket-Channel. So I think the server might close the > connection while the ESB is reading. But maybe internally some kind of > pool is used and a connection can change to some abnormal state? > > Unlikely. This kind of I/O exception occurs when the connection is > closed by the _remote_ side. Yes, this has also been my understanding. So our Bea Application Server seems to close the connection which is still in use by Synapse. > > <syn:property name="FORCE_HTTP_1.0" value="true" scope="axis2" /> > > > > Connection reset by peer I/O exceptions are perfectly normal with > persistent HTTP connections. Bye the way just another question. If those exceptions are "perfectly normal" why do we see a stacktrace in the log a not a short warning? I mean the complete stack doesn't help much and just bloats the server logs. Is there a particular reason for this. How shall this exception normally be handled from any application using the http core nio module? Just a retry of the request? > The most likely cause of it is that the > connection was closed on the server side due to the timeout (maximum > period of inactivity) about the same moment the client started sending > data to the server. Situations like that can happen. Ok, I understand this now for http 1.1 (with persistent connnections). > I do not know Hessian well enough protocol to comment on it. I also can't see any logical relation to the application protocol used on top of the transport protocol. If we send HTTP 1.0 requests with Synapse can it still happen that the server uses persistent connections? I think this should not be the case. But if the server does not use persistent connections and for each request a new connection will be created I don't understand how this error might occur. One idea which came into my mind was a timeout. But our response times are pretty low (about 10 ms on average). The longest ever running request took 6500 ms according to our statistic data. The default nhttp timeout should be 60000 ms. I'll try to see if there might be some connection timeout on the server side. Any other idea? Regards, Eric
