Hi Suprun, yes, we have a solution for this.
Our analysis showed that the timeouts were due to a misbehaviour of our .net service client. The client is sending a "100-continue" HTTP header and waits infinitely for a "100 Continue" response before sending the request body, resulting in timeouts. This behaviour is not according to HTTP 1.1 spec, though. Synapse by now is not responding to 100-continue headers and waits for the client to send the request body (according to HTTP 1.1). For future versions of Synapse it would be desirable that synapse gets the ability to respond with "100 Continue" responses. This would prevent interoperability issues with older .net clients like this. Asankha provided us with a quick fix; perhaps it would be possible that his fix flows into the Synapse trunk? Thank you and cheers! i. A. Ralph Henze Dipl.-Informatiker (Univ.) Sparda-Datenverarbeitung eG AE-ABS/Softwarearchitektur Supun Kamburugamuva <[email protected]> schrieb am 26.10.2009 05:04:58: > [Bild entfernt] > > Re: Antwort: Re: Antwort: Re: Connection timeout problem > > Supun Kamburugamuva > > an: > > user > > 26.10.2009 05:05 > > [Bild entfernt] > > Von: > > Supun Kamburugamuva <[email protected]> > > An: > > [email protected] > > Bitte Antwort an [email protected] > > Hi Ralph, > > Did you get a solution to this problem? > > Thanks, > Supun.. > > On Thu, Sep 3, 2009 at 1:13 AM, Asankha C. Perera <[email protected]>wrote: > > > Hi Ralph > > > The GET /soap/ requests are those issued by the monitoring system. The > > > monitoring assumes that the esb is available if the list of services is > > > retrieved or there is a problem/outage otherwise. > > > > > Typically it would be better to issue a real call through Synapse itself > > for monitoring purposes. I think Eric might be able to tell you more > > about the monitoring etc they do in their deployment environment. > > > In our infrastructure there is an Apache HTTP server that is placed in > > > front of synapse, so that the tcp connection client from synapse's > > > perspective is always the HTTP server. The HTTP server terminates SSL > > > connections and connects to synapse via mod_proxy. Do you presume that a > > > possible solution lies in HTTP server configuration? > > > > > > > > >> It seems like you issue a GET /soap/ request? I also saw many of those.. > > >> what is the purpose of issuing that? Anyway.. this seems like a harmless > > >> possible bug - where the connection gets timedout - but Synapse thinks > > >> its response was not fully read by the client. This could happen if the > > >> client just looks at the header of the response, and does not read the > > >> entity body - which will prevent the HTTP connection from being re-used > > >> again (i.e. as a keepalive) - however, I also suspect a slight bug in > > >> the code where this message could be dumped in a harmless case. Do you > > >> see an actual error at the client side? > > >> > > > > > > Yes, there is an effect at the service client side. About 10 percent of > > > client requests are responded with HTTP error code 502. > > Synapse does not return 502.. so this is returned by Apache.. but the > > reason behind would need some investigation.. If you could re-create > > this with a single request and get me a tcpdump it would be great > > > I'm not sure of > > > how that behaviour relates to the timeout message, because there are a > > lot > > > more timeout messages in the log than actual client errors. But we didn't > > > have that when we were on synapse 1.2. But as stated earlier, synapse 1.2 > > > freezed up to 3 times a day and had to be restarted, which we assume is a > > > consequence of bug SYNAPSE-404. > > > > > > Are you planning to prepare a fix? > > > > > Yes, I could fix the issue I suspect - but that would not solve the 502 > > issue.. what I noticed is that Synapse may report the "Connection > > Timeout - before message body was fully read " message when the remote > > party (i.e. client to synapse) terminated its socket - since that was > > what was happening in your logs > > > > cheers > > asankha > > > > -- > > Asankha C. Perera > > AdroitLogic, http://adroitlogic.org > > > > http://esbmagic.blogspot.com > > > > > > > > > > > > > -- > Software Engineer, WSO2 Inc > http://wso2.org > supunk.blogspot.com >
