Hi Asankha, thank you for your analysis.
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. 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. 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? Thanks again. Cheers, Ralph.
