Hi Mladen, I read our code as follows:
in any case where a function in the while loop does produce an error, we close the connection afterwards: - if jk_is_socket_connected() fails, we do it explicitely via jk_close_socket() - if ajp_handle_cping_cpong() fails, we don't go into ajp_connection_tcp_send_message() and call ajp_next_connection(), which as a side effect closes the old connection via jk_close_socket() - if ajp_connection_tcp_send_message() fails, and we don't get a JK_FATAL_ERROR, again the conn is closed in ajp_next_connection() - if it returns with JK_FATAL_ERROR, we close explicitely with jk_close_socket() So a hanging tomcat, cut off connections by a firewall, or closed conns by the remote side all behave the same (I assume the extreme case, that all conns are concerned): we end the loop, and all conns have beend closed and replaced by JK_INVALID_SOCKET. No the question is: how to proceed? If we had known before, that no connections are established we would have passed the wile loop and directly tried to establish a new connection. The difference in our situation is, that we know we had to close conns, but we don't know the reason. If we return directly, then the first try has been burned by invalidating all established connections, and the second (re)try will start from a clean, no connection state, by trying to connect. Both tries will be handled inside the ajp code, no load balancer will know about that. After the failure of the second try we go up the stack, and if there's a load balancer it will try another worker. The load balancer counts it's own retries totally independant of the ones from the ajp workers. In my opinion the only change is: - old code: retries=2 means first try to close all conns and second try with new connection - new code: retries=2 means first try to close all conns and immediate new conn, second try a "real" retry. My concern is: if a user thinks he does not want a retry in the ajp worker (especially if he uses a load balancer), then I find it a little too fast to not connect once, if all established conns are broken. Concerning load balancing: the patch does not really change the interaction with an lb. It's only a question, after how man retries we break out of the service method of the ajp worker. That's internal to the ajp worker. It's code decides how early it fails and then the lb decides how to proceed. The lb retries are counted totally independently of the ajp retries. Session free node: I expect maintenance will close the conns, if the min size is 0. Concerning the code here: if the new connection also fails, then it would have also failed during in the old code during the second try. So I don't see a big difference. But maybe I overlooked something. I find this discussion helpful! Regards, Rainer Mladen Turk schrieb: > Rainer Jung wrote: >> For those who want to test: I committed far the most part of what I >> planned to improve. > > Thanks Rainer, the patches you made are really great! > I think we'll have a best ever mod_jk. > > However I still have doubts about you patch: > >> @@ -1219,8 +1219,8 @@ >> jk_log(l, JK_LOG_INFO, >> "(%s) all endpoints are disconnected or dead", >> ae->worker->name); >> - JK_TRACE_EXIT(l); >> - return JK_FALSE; >> + jk_log(l, JK_LOG_INFO, >> + "Increase the backend idle connection timeout or > the connection_pool_minsize"); > > The patch you made is IMHO dubious. > I agree it works for standard sittuations when backend > Tomcat closes the connection, but it fails when the backend > is dead or (the major problem) when the firewall closes the > connection between them. > With your patch we loose the option to have a session-free > nodes. There is simply no chance to have a lb that will > go to another node if the existing one fails. > > Regards, > Mladen. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
