You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jorge Medina <jm...@e-dialog.com> on 2009/03/27 21:15:32 UTC
mod_jk : recovery_options
Hi,
I have an automated test of a web services application running on
Tomcat (6.0.18) behind Apache (2.2.11) We use mod_jk (1.2.27)
Our test suite runs a client against the Apache server on a system
where we have a single Tomcat instance behind Apache.
So far so good, all test passed.
Now, I tried using Apache as a load balancer; using two Tomcat
instances behind Apache.
All of my tests passed, except for one that failed on a strange way.
The test does the following:
deleteAllItems
createItem (A)
createItem (B)
createItem (C)
list = getAllItems()
at this point we verify that we get 3 items on the list, but instead
of 3, the list returned 4 items!!
This was the only test that failed from a test suite of about 400. I
ran the same test suite again and the error did not occur again.
So, could it be related to the configuration of the mod_jk module in
Apache?
Currently we don't specify the "recovery_options" for the Tomcat
worker (therefore it defaults to "0") in workers.properties.
We do not specify the "retries" either, so it defaults to "2".
I was wondering if in the test above, a "createItem" call was resent
to a Tomcat instance due to some communication error, and therefore 4
items were created in the database instead of the 3 we expected.
I would appreciate if someone could shed more light on the
"recovery_options" from what it is found in the documentation.
Below is what I found on the documentation
http://tomcat.apache.org/connectors-doc/reference/workers.html#Advanced%
20Worker%20Directives
Thanks a lot.
-Jorge
------------------
recovery_options
------------------
Worker Type: AJP,SUB
Default value: 0
Recovery options influence, how we should handle retries, in case we
detect a problem with Tomcat. How often we will retry is controlled by
the attribute retries.
This attribute is a bit mask. The following bits are allowed:
1: don't recover if Tomcat failed after getting the request
2: don't recover if Tomcat failed after sending the headers to client
4: close the connection to Tomcat, if we detect an error when writing
back the answer to the client (browser)
8: always recover requests for HTTP method HEAD (even if Bits 1 or 2 are
set)
16: always recover requests for HTTP method GET (even if Bits 1 or 2 are
set)
This features has been added in jk 1.2.6. Option 4 has been added in
version 1.2.16, options 8 and 16 in version 1.2.24.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: mod_jk : recovery_options
Posted by Jorge Medina <jm...@e-dialog.com>.
Danke schön Rainer!
Yes, all my transaction requests use POST. We only allow GET to get a couple of static files.
-Jorge
-----Original Message-----
From: Rainer Jung [mailto:rainer.jung@kippdata.de]
Sent: Tuesday, March 31, 2009 3:24 AM
To: Tomcat Users List
Subject: Re: mod_jk : recovery_options
On 30.03.2009 22:24, Jorge Medina wrote:
> I did not get any response to my questions, but from previous
> messages (posted by Rainer Jung) I believe that using the default
> values for "retry" and "recovery_options" may produce the unexpected
> result I was having. I changed the "recovery_options" on my AJP
> workers to value "27". So far I have not seen the tests failing again.
If mod_jk retried a request which might have resulted in duplicate transactions, then you should find info level log messages about that in your mod_jk log.
If your application doesn't prevent against duplicate transaction execution, setting the recovery_options to "3" is recommended. Your value of "27" is save, in case duplicate GETs and HEADs are fine for you. One example would be, if you always use POST for requesting changes you don't want to see duplicate.
The official semantics of GET and HEAD require them to be idempotent, so with this assumption "27" is fine. Many apps do not satisfy this condition though and for them "3" would be better.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk : recovery_options
Posted by Rainer Jung <ra...@kippdata.de>.
On 30.03.2009 22:24, Jorge Medina wrote:
> I did not get any response to my questions, but from previous messages
> (posted by Rainer Jung) I believe that using the default values for
> "retry" and "recovery_options" may produce the unexpected result I was
> having. I changed the "recovery_options" on my AJP workers to value
> "27". So far I have not seen the tests failing again.
If mod_jk retried a request which might have resulted in duplicate
transactions, then you should find info level log messages about that in
your mod_jk log.
If your application doesn't prevent against duplicate transaction
execution, setting the recovery_options to "3" is recommended. Your
value of "27" is save, in case duplicate GETs and HEADs are fine for
you. One example would be, if you always use POST for requesting changes
you don't want to see duplicate.
The official semantics of GET and HEAD require them to be idempotent, so
with this assumption "27" is fine. Many apps do not satisfy this
condition though and for them "3" would be better.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: mod_jk : recovery_options
Posted by Jorge Medina <jm...@e-dialog.com>.
I did not get any response to my questions, but from previous messages
(posted by Rainer Jung) I believe that using the default values for
"retry" and "recovery_options" may produce the unexpected result I was
having. I changed the "recovery_options" on my AJP workers to value
"27". So far I have not seen the tests failing again.
-Jorge
-----Original Message-----
From: Jorge Medina [mailto:jmedina@e-dialog.com]
Sent: Friday, March 27, 2009 4:16 PM
To: users@tomcat.apache.org
Subject: mod_jk : recovery_options
Hi,
I have an automated test of a web services application running on
Tomcat (6.0.18) behind Apache (2.2.11) We use mod_jk (1.2.27)
Our test suite runs a client against the Apache server on a system
where we have a single Tomcat instance behind Apache.
So far so good, all test passed.
Now, I tried using Apache as a load balancer; using two Tomcat
instances behind Apache.
All of my tests passed, except for one that failed on a strange way.
The test does the following:
deleteAllItems
createItem (A)
createItem (B)
createItem (C)
list = getAllItems()
at this point we verify that we get 3 items on the list, but instead
of 3, the list returned 4 items!!
This was the only test that failed from a test suite of about 400. I
ran the same test suite again and the error did not occur again.
So, could it be related to the configuration of the mod_jk module in
Apache?
Currently we don't specify the "recovery_options" for the Tomcat
worker (therefore it defaults to "0") in workers.properties.
We do not specify the "retries" either, so it defaults to "2".
I was wondering if in the test above, a "createItem" call was resent
to a Tomcat instance due to some communication error, and therefore 4
items were created in the database instead of the 3 we expected.
I would appreciate if someone could shed more light on the
"recovery_options" from what it is found in the documentation.
Below is what I found on the documentation
http://tomcat.apache.org/connectors-doc/reference/workers.html#Advanced%
20Worker%20Directives
Thanks a lot.
-Jorge
------------------
recovery_options
------------------
Worker Type: AJP,SUB
Default value: 0
Recovery options influence, how we should handle retries, in case we
detect a problem with Tomcat. How often we will retry is controlled by
the attribute retries.
This attribute is a bit mask. The following bits are allowed:
1: don't recover if Tomcat failed after getting the request
2: don't recover if Tomcat failed after sending the headers to client
4: close the connection to Tomcat, if we detect an error when writing
back the answer to the client (browser)
8: always recover requests for HTTP method HEAD (even if Bits 1 or 2 are
set)
16: always recover requests for HTTP method GET (even if Bits 1 or 2 are
set)
This features has been added in jk 1.2.6. Option 4 has been added in
version 1.2.16, options 8 and 16 in version 1.2.24.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org