You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2006/11/24 03:47:32 UTC
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: State of affairs for mod_jk 1.2.20
Posted by Jim Jagielski <ji...@jaguNET.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: State of affairs for mod_jk 1.2.20
Posted by Rainer Jung <ra...@kippdata.de>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
AJP Connector & enableLookups
Posted by "Fisher, Mitchell L" <Mi...@unisys.com>.
I have a question about the behavior of the Tomcat AJP Connector. When
my mod_jk equivalent sends the remote host name in AJP, the servlet's
call to getRemoteHost() returns the IP address if enableLookups is set
false in the connector, and returns the remote host supplied by the
front-end server if enableLookups is true. I am using snoop.jsp to test
this.
Does this make sense? If the front-end server is sending the hostname,
shouldn't the connector use the hostname whether enableLookups is set or
not?
By "mod_jk equivalent" I mean that we have our own web server extension
that performs the AJP 1.3 protocol to Tomcat 5.5.20 running on Windows.
My tracing shows that the hostname is being sent in each case.
Mitchell Fisher | Unisys Corp.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: State of affairs for mod_jk 1.2.20
Posted by Mladen Turk <mt...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: State of affairs for mod_jk 1.2.20
Posted by Rainer Jung <ra...@kippdata.de>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: State of affairs for mod_jk 1.2.20
Posted by Rainer Jung <ra...@kippdata.de>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: State of affairs for mod_jk 1.2.20
Posted by Mladen Turk <mt...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org