https://bz.apache.org/bugzilla/show_bug.cgi?id=64080
--- Comment #12 from carbatt...@hotmail.com --- > If the expectation is that a request (from the client's perspective) will > not be dropped, then I think you can solve this at the load-balancer with > retry-based fail-over: the lb takes care of the fail-over and the client > detects no problems at all. The problem here is that the loadbalancer is in-house developed using Java, and the HttpURLConnection class does not distinguish between SocketTimeOutException for request payload sent and not sent, due to its built-in retry functionality. Therefore neither the exception nor the message is any indication of whether the loadbalancer can retry or not. I can provide links explaining this in detail, if this is of interest. To solve this we will have to either handle sockets ourselves, or switch to another http client instead of HttpUrlConnection > If you refuse to allow a request to an individual node to be dropped, that > is a much taller order. > > In my environment, we tell the lb that the nodes are coming down so we avoid > any of this. The lb allows all in-flight requests to complete and we only > shut-down the node after that point. No new requests are sent to the target > node after the lb is told to take it (softly) out of service. The only time > requests should ever be dropped in this situation is if a node unexpectedly > goes down. We do this using mod_jk with DISABLED and STOP states. > mod_proxy_* has these same states and can be used with either AJP or HTTP as > the communication protocol. That is plan B, depending on the conclusion for this bug: Do a custom integration between our build server and the load balancer. Even a 503 could be use able, provided that we can retry knowing, the request was rejected by tomcat. Who can provide a conclusion on this defect, in terms of next step? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
