Re: State of affairs for mod_jk 1.2.20
On Nov 24, 2006, at 3:06 PM, Mladen Turk wrote: Rainer Jung wrote: 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. Right, and that is the problem. With retries=1 the old code would in case of connect failure go to the next worker in the lb, while in the new code it would first try to reconnect. Now, this is OK for sticky session, but if you have session replication there is simply no need to try to reconnect, because it will connect on the next election. What I'm saying is that right now we would always reconnect, and the user has no influence in that, while with default retries=2 he can set retries=1 and have that option. Of course there will be extra [info] lines in the log in that case. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: State of affairs for mod_jk 1.2.20
Hi Mladen, 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. Thanks for the credits, I hope they work. 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. OK, I'll think about that in the next hour and then comment. Four eyes are much better than 2 ... Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: State of affairs for mod_jk 1.2.20
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]
Re: State of affairs for mod_jk 1.2.20
Rainer Jung wrote: 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. Right, and that is the problem. With retries=1 the old code would in case of connect failure go to the next worker in the lb, while in the new code it would first try to reconnect. Now, this is OK for sticky session, but if you have session replication there is simply no need to try to reconnect, because it will connect on the next election. What I'm saying is that right now we would always reconnect, and the user has no influence in that, while with default retries=2 he can set retries=1 and have that option. Of course there will be extra [info] lines in the log in that case. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: State of affairs for mod_jk 1.2.20
OK, convinced. I'll change that tomorrow and add a respective note to the docs fpr ajp retries in relation to lb. Mladen Turk schrieb: Rainer Jung wrote: 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. Right, and that is the problem. With retries=1 the old code would in case of connect failure go to the next worker in the lb, while in the new code it would first try to reconnect. Now, this is OK for sticky session, but if you have session replication there is simply no need to try to reconnect, because it will connect on the next election. What I'm saying is that right now we would always reconnect, and the user has no influence in that, while with default retries=2 he can set retries=1 and have that option. Of course there will be extra [info] lines in the log in that case. 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]
State of affairs for mod_jk 1.2.20
For those who want to test: I committed far the most part of what I planned to improve. The rest of the things, I want to work on (depending on time) concerns only much smaller code areas: - checking consistency for logging/%R/NOTES concerning worker name versus jvmRoute - XML and txt mime type enhancements in jk status - 2 more notes for logging (busy+max_busy of the lb itself) - improve envvar handling in apache wrt. duplicate configuration - document max_packet_size - write a doc page concerning mapping rules, uriworkermap etc. - write a doc page about jk status Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
