cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
hgomez 2004/02/17 09:54:52 Modified:jk/xdocs/jk workershowto.xml Log: Add explanation on recovery_options for worker Revision ChangesPath 1.16 +15 -0 jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml Index: workershowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- workershowto.xml 25 Sep 2003 15:21:02 - 1.15 +++ workershowto.xml 17 Feb 2004 17:54:51 - 1.16 @@ -287,6 +287,21 @@ Disabled by default. /p +p +brecovery_options/b property told webserver how to handle recovery when +it detect that tomcat failed. +By default, webserver will forward the request to another tomcat in LB mode +(or to another ajp thread in ajp13 mode). +values are : 0 (full recovery), 1 (don't recover if tomcat failed after getting the request), +2 (don't recover if tomcat failed after sending the headers to client), 3 (don't recover if tomcat failed +getting the request or after sending the headers to client). +/p +p +This features has been added in bjk 1.2.6/b to avoid problem with hung tomcat's and works on all +servlet engines supporting ajp13. +Full recovery by default. +/p + screen noteworker worker2 will talk to Tomcat listening on machine www2.x.com at port 8009 using 3.5 lb factor/note readworker.worker2.host=www2.x.com/read - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
hgomez 2004/02/17 09:57:31 Modified:jk/xdocs/jk workershowto.xml Log: Revision ChangesPath 1.17 +2 -2 jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml Index: workershowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- workershowto.xml 17 Feb 2004 17:54:51 - 1.16 +++ workershowto.xml 17 Feb 2004 17:57:31 - 1.17 @@ -297,8 +297,8 @@ getting the request or after sending the headers to client). /p p -This features has been added in bjk 1.2.6/b to avoid problem with hung tomcat's and works on all -servlet engines supporting ajp13. +This features has been added in bjk 1.2.6/b to avoid problem with hung/broken tomcat's +and works on all servlet engines supporting ajp13. Full recovery by default. /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
hgomez 2003/09/25 08:21:02 Modified:jk/xdocs/jk workershowto.xml Log: Update workers documentation with new hang detection parameters Revision ChangesPath 1.15 +33 -0 jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml Index: workershowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- workershowto.xml 25 Sep 2003 13:06:30 - 1.14 +++ workershowto.xml 25 Sep 2003 15:21:02 - 1.15 @@ -254,6 +254,39 @@ This property is very similar to bcache_timeout/b but works also in non-cache mode. /p +p +bconnect_timeout/b property told webserver to send a PING request on ajp13 connection after +connection is established. The parameter is the delay in milliseconds to wait for the PONG reply. +/p +p +This features has been added in bjk 1.2.6/b to avoid problem with hung tomcat's and require ajp13 +ping/pong support which has been implemented on Tomcat b3.3.2+, 4.1.28+ and 5.0.13+/b. +Disabled by default. +/p + +p +bprepost_timeout/b property told webserver to send a PING request on ajp13 connection before +forwarding to it a request. The parameter is the delay in milliseconds to wait for the PONG reply. +/p +p +This features has been added in bjk 1.2.6/b to avoid problem with hung tomcat's and require ajp13 +ping/pong support which has been implemented on bTomcat 3.3.2+, 4.1.28+ and 5.0.13+/b. +Disabled by default. +/p + +p +breply_timeout/b property told webserver to wait some time for reply to a forwarded request +before considering the remote tomcat is dead and eventually switch to another tomcat in a cluster +group. By default webserver will wait forever which could be an issue for you. +The parameter is the number of milliseconds to wait for reply, so adjust it carrefully if you +have long running servlets. +/p +p +This features has been added in bjk 1.2.6/b to avoid problem with hung tomcat's and works on all +servlet engines supporting ajp13. +Disabled by default. +/p + screen noteworker worker2 will talk to Tomcat listening on machine www2.x.com at port 8009 using 3.5 lb factor/note readworker.worker2.host=www2.x.com/read - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
hgomez 2003/07/18 04:06:43 Modified:jk/xdocs/jk workershowto.xml Log: Indicate that cache is disable by default. If Glenn set a default valuen I'll update the doc Revision ChangesPath 1.13 +1 -0 jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml Index: workershowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- workershowto.xml 27 May 2003 13:04:46 - 1.12 +++ workershowto.xml 18 Jul 2003 11:06:43 - 1.13 @@ -207,6 +207,7 @@ bcachesize/b property is usefull when you're using JK in multithreaded web servers such as Apache 2.0, IIS and Netscape. They will benefit the most by setting this value to a higher level (such as the estimated average concurrent users for Tomcat). +If cachesize is not set, the connection cache support is disabled. /p p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
wname is the worker name. This name is the name of the worker as defined
in the JK property config file. Eg:
worker.tomcat1.host=localhost
^^^
For example above: tomcat1 is the worker name.
If someone were to attempt a buffer overflow, they would need write
access to the Jk config file. (Then have enough permission/patience
until apache is restarted).
I do not think this is a problem (except for the admin of the box).
-Tim
Jerome Lacoste (Frisurf) wrote:
const char *wname) {
+int rc = JK_TRUE;
+char buf[1024];
+if (m wname) {
+int value;
+sprintf(buf, %s.%s.%s, PREFIX_OF_WORKER, wname, STICKY_SESSION);
Seeing that checkin I got curious and I had a look at the code.
I saw that this sprintf is used a lot in that way. Was wondering if
there was a way to pass some parameters to overflow the buffer.
Especially if the name comes from a property read from a file. I didn't
see any special protection checking the length of the parameters, wname
in that case.
Am I wrong?
J.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
glenn 2003/01/02 09:12:55
Modified:jk/native CHANGES.txt
jk/native/common jk_lb_worker.c jk_util.c jk_util.h
jk/xdocs/jk workershowto.xml
Log:
Add new lb property sticky_session. If set to 0, requests with session
id's do not have to be routed back to the same Tomcat worker. This is
to support the new Tomcat Session Manager code which supports persistance
of session data across multiple Tomcat instances, such as JavaGroup's.
Revision ChangesPath
1.9 +4 -1 jakarta-tomcat-connectors/jk/native/CHANGES.txt
Index: CHANGES.txt
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CHANGES.txt 2 Jan 2003 13:00:59 - 1.8
+++ CHANGES.txt 2 Jan 2003 17:12:55 - 1.9
@@ -6,6 +6,9 @@
[glenn]
* Apache 2/1.3, if Tomcat returns an error but not content,
let Apache handle processing the error returned by Tomcat.
+* Added the load balancer sticky_session property. If set to 0
+ requests with servlet SESSION ID's can be routed to any Tomcat
+ worker. Default is 1, sessions are sticky.
Changes with JK 1.2.2:
* tomcat_trend.pl updated script to support changed logging of
1.12 +9 -3 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jk_lb_worker.c30 Oct 2002 21:17:34 - 1.11
+++ jk_lb_worker.c2 Jan 2003 17:12:55 - 1.12
@@ -103,6 +103,7 @@
jk_worker_t worker;
int in_local_worker_mode;
int local_worker_only;
+int sticky_session;
};
typedef struct lb_worker lb_worker_t;
@@ -254,8 +255,12 @@
worker_record_t *rc = NULL;
double lb_min = 0.0;
unsigned i;
-char *session_route = get_session_route(s);
-
+char *session_route = NULL;
+
+if (p-sticky_session) {
+session_route = get_session_route(s);
+}
+
if(session_route) {
for(i = 0 ; i p-num_of_workers ; i++) {
if(0 == strcmp(session_route, p-lb_workers[i].name)) {
@@ -421,6 +426,7 @@
unsigned num_of_workers;
p-in_local_worker_mode = JK_FALSE;
p-local_worker_only = jk_get_local_worker_only_flag(props, p-name);
+p-sticky_session = jk_get_is_sticky_session(props, p-name);
if(jk_get_lb_worker_list(props,
p-name,
1.19 +15 -1 jakarta-tomcat-connectors/jk/native/common/jk_util.c
Index: jk_util.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- jk_util.c 16 Sep 2002 08:26:46 - 1.18
+++ jk_util.c 2 Jan 2003 17:12:55 - 1.19
@@ -89,6 +89,7 @@
#define SOCKET_KEEPALIVE_OF_WORKER (socket_keepalive)
#define LOAD_FACTOR_OF_WORKER (lbfactor)
#define BALANCED_WORKERS(balanced_workers)
+#define STICKY_SESSION (sticky_session)
#define LOCAL_WORKER_ONLY_FLAG (local_worker_only)
#define LOCAL_WORKER_FLAG (local_worker)
#define WORKER_AJP12(ajp12)
@@ -499,6 +500,19 @@
sprintf(buf, %s.%s.%s, PREFIX_OF_WORKER, wname, LOAD_FACTOR_OF_WORKER);
return map_get_double(m, buf, DEFAULT_LB_FACTOR);
+}
+
+int jk_get_is_sticky_session(jk_map_t *m,
+const char *wname) {
+int rc = JK_TRUE;
+char buf[1024];
+if (m wname) {
+int value;
+sprintf(buf, %s.%s.%s, PREFIX_OF_WORKER, wname, STICKY_SESSION);
+value = map_get_int(m, buf, 0);
+if (!value) rc = JK_FALSE;
+}
+return rc;
}
int jk_get_is_local_worker(jk_map_t *m,
1.9 +4 -1 jakarta-tomcat-connectors/jk/native/common/jk_util.h
Index: jk_util.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.h,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- jk_util.h 16 Sep 2002 08:26:46 - 1.8
+++ jk_util.h 2 Jan 2003 17:12:55 - 1.9
@@ -134,6 +134,9 @@
double jk_get_lb_factor(jk_map_t *m,
const char *wname);
+int jk_get_is_sticky_session(jk_map_t *m,
+ const char *wname);
+
int
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
Are you going to port this to jk2 :-) ?
One issue: I'm not sure JavaGroup is doing the synchronous(?) replication of
session data - there is a delay between a change is made on one worker and
the moment this is known on all other workers.
If you don't route back to the same worker - you'll loose data. If the
original worker doesn't respond - you can send to a different worker in
the group.
Costin
[EMAIL PROTECTED] wrote:
glenn 2003/01/02 09:12:55
Modified:jk/native CHANGES.txt
jk/native/common jk_lb_worker.c jk_util.c jk_util.h
jk/xdocs/jk workershowto.xml
Log:
Add new lb property sticky_session. If set to 0, requests with session
id's do not have to be routed back to the same Tomcat worker. This is
to support the new Tomcat Session Manager code which supports
persistance of session data across multiple Tomcat instances, such as
JavaGroup's.
Revision ChangesPath
1.9 +4 -1 jakarta-tomcat-connectors/jk/native/CHANGES.txt
Index: CHANGES.txt
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CHANGES.txt 2 Jan 2003 13:00:59 - 1.8
+++ CHANGES.txt 2 Jan 2003 17:12:55 - 1.9
@@ -6,6 +6,9 @@
[glenn]
* Apache 2/1.3, if Tomcat returns an error but not content,
let Apache handle processing the error returned by Tomcat.
+* Added the load balancer sticky_session property. If set to 0
+ requests with servlet SESSION ID's can be routed to any Tomcat
+ worker. Default is 1, sessions are sticky.
Changes with JK 1.2.2:
* tomcat_trend.pl updated script to support changed logging of
1.12 +9 -3
jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.11 retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jk_lb_worker.c 30 Oct 2002 21:17:34 - 1.11
+++ jk_lb_worker.c 2 Jan 2003 17:12:55 - 1.12
@@ -103,6 +103,7 @@
jk_worker_t worker;
int in_local_worker_mode;
int local_worker_only;
+int sticky_session;
};
typedef struct lb_worker lb_worker_t;
@@ -254,8 +255,12 @@
worker_record_t *rc = NULL;
double lb_min = 0.0;
unsigned i;
-char *session_route = get_session_route(s);
-
+char *session_route = NULL;
+
+if (p-sticky_session) {
+session_route = get_session_route(s);
+}
+
if(session_route) {
for(i = 0 ; i p-num_of_workers ; i++) {
if(0 == strcmp(session_route, p-lb_workers[i].name)) {
@@ -421,6 +426,7 @@
unsigned num_of_workers;
p-in_local_worker_mode = JK_FALSE;
p-local_worker_only = jk_get_local_worker_only_flag(props,
p-name);
+p-sticky_session = jk_get_is_sticky_session(props, p-name);
if(jk_get_lb_worker_list(props,
p-name,
1.19 +15 -1
jakarta-tomcat-connectors/jk/native/common/jk_util.c
Index: jk_util.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
retrieving revision 1.18 retrieving revision 1.19
diff -u -r1.18 -r1.19
--- jk_util.c 16 Sep 2002 08:26:46 - 1.18
+++ jk_util.c 2 Jan 2003 17:12:55 - 1.19
@@ -89,6 +89,7 @@
#define SOCKET_KEEPALIVE_OF_WORKER (socket_keepalive)
#define LOAD_FACTOR_OF_WORKER (lbfactor)
#define BALANCED_WORKERS(balanced_workers)
+#define STICKY_SESSION (sticky_session)
#define LOCAL_WORKER_ONLY_FLAG (local_worker_only)
#define LOCAL_WORKER_FLAG (local_worker)
#define WORKER_AJP12(ajp12)
@@ -499,6 +500,19 @@
sprintf(buf, %s.%s.%s, PREFIX_OF_WORKER, wname,
LOAD_FACTOR_OF_WORKER);
return map_get_double(m, buf, DEFAULT_LB_FACTOR);
+}
+
+int jk_get_is_sticky_session(jk_map_t *m,
+const char *wname) {
+int rc = JK_TRUE;
+char buf[1024];
+if (m wname) {
+int value;
+sprintf(buf, %s.%s.%s, PREFIX_OF_WORKER, wname,
STICKY_SESSION);
+value = map_get_int(m, buf, 0);
+if (!value) rc = JK_FALSE;
+}
+return rc;
}
int jk_get_is_local_worker(jk_map_t *m,
1.9 +4 -1
jakarta-tomcat-connectors/jk/native/common/jk_util.h
Index:
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
On Thu, 2 Jan 2003, Costin Manolache wrote:
Date: Thu, 02 Jan 2003 09:23:49 -0800
From: Costin Manolache [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk
workershowto.xml
Are you going to port this to jk2 :-) ?
One issue: I'm not sure JavaGroup is doing the synchronous(?) replication of
session data - there is a delay between a change is made on one worker and
the moment this is known on all other workers.
If you don't route back to the same worker - you'll loose data. If the
original worker doesn't respond - you can send to a different worker in
the group.
A further subtlety to keep in mind is a restriction from Section 7.7.2:
Within an application marked as distributable, all requests
that are part of a session must be handled by one virtual
machine at a time.
In other words, it's legal to migrate sessions from one JVM to another in
between requests. But it's not legal to send two simultaneous requests
for the same session to two different JVMs. I don't know all the
implications of this patch, but it sounds like you might be going down a
path that will have problems with this requirement.
(And it's also not technicallly legal to distribute an app that is not
marked distributable/ in web.xml, but that's a separate issue )
Costin
Craig
[EMAIL PROTECTED] wrote:
glenn 2003/01/02 09:12:55
Modified:jk/native CHANGES.txt
jk/native/common jk_lb_worker.c jk_util.c jk_util.h
jk/xdocs/jk workershowto.xml
Log:
Add new lb property sticky_session. If set to 0, requests with session
id's do not have to be routed back to the same Tomcat worker. This is
to support the new Tomcat Session Manager code which supports
persistance of session data across multiple Tomcat instances, such as
JavaGroup's.
Revision ChangesPath
1.9 +4 -1 jakarta-tomcat-connectors/jk/native/CHANGES.txt
Index: CHANGES.txt
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CHANGES.txt 2 Jan 2003 13:00:59 - 1.8
+++ CHANGES.txt 2 Jan 2003 17:12:55 - 1.9
@@ -6,6 +6,9 @@
[glenn]
* Apache 2/1.3, if Tomcat returns an error but not content,
let Apache handle processing the error returned by Tomcat.
+* Added the load balancer sticky_session property. If set to 0
+ requests with servlet SESSION ID's can be routed to any Tomcat
+ worker. Default is 1, sessions are sticky.
Changes with JK 1.2.2:
* tomcat_trend.pl updated script to support changed logging of
1.12 +9 -3
jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.11 retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jk_lb_worker.c 30 Oct 2002 21:17:34 - 1.11
+++ jk_lb_worker.c 2 Jan 2003 17:12:55 - 1.12
@@ -103,6 +103,7 @@
jk_worker_t worker;
int in_local_worker_mode;
int local_worker_only;
+int sticky_session;
};
typedef struct lb_worker lb_worker_t;
@@ -254,8 +255,12 @@
worker_record_t *rc = NULL;
double lb_min = 0.0;
unsigned i;
-char *session_route = get_session_route(s);
-
+char *session_route = NULL;
+
+if (p-sticky_session) {
+session_route = get_session_route(s);
+}
+
if(session_route) {
for(i = 0 ; i p-num_of_workers ; i++) {
if(0 == strcmp(session_route, p-lb_workers[i].name)) {
@@ -421,6 +426,7 @@
unsigned num_of_workers;
p-in_local_worker_mode = JK_FALSE;
p-local_worker_only = jk_get_local_worker_only_flag(props,
p-name);
+p-sticky_session = jk_get_is_sticky_session(props, p-name);
if(jk_get_lb_worker_list(props,
p-name,
1.19 +15 -1
jakarta-tomcat-connectors/jk/native/common/jk_util.c
Index: jk_util.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
retrieving revision 1.18 retrieving revision 1.19
diff -u -r1.18 -r1.19
--- jk_util.c 16 Sep 2002 08:26:46 - 1.18
+++ jk_util.c 2 Jan 2003 17:12:55 - 1.19
@@ -89,6 +89,7 @@
#define SOCKET_KEEPALIVE_OF_WORKER (socket_keepalive)
#define
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
Craig R. McClanahan wrote:
On Thu, 2 Jan 2003, Costin Manolache wrote:
Date: Thu, 02 Jan 2003 09:23:49 -0800
From: Costin Manolache [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk
workershowto.xml
Are you going to port this to jk2 :-) ?
It could be I ported to jk2, only a few lines of code. :-)
One issue: I'm not sure JavaGroup is doing the synchronous(?) replication of
session data - there is a delay between a change is made on one worker and
the moment this is known on all other workers.
If you don't route back to the same worker - you'll loose data. If the
original worker doesn't respond - you can send to a different worker in
the group.
Yes, there very well could be problems with persistance of session data
across multiple tomcat workers. Being able to seamlessly failover from
one tomcat worker to another without loosing session data is an important
feature when you start clustering. At least with this property we can start
testing different session persistance solutions.
A further subtlety to keep in mind is a restriction from Section 7.7.2:
Within an application marked as distributable, all requests
that are part of a session must be handled by one virtual
machine at a time.
In other words, it's legal to migrate sessions from one JVM to another in
between requests. But it's not legal to send two simultaneous requests
for the same session to two different JVMs. I don't know all the
implications of this patch, but it sounds like you might be going down a
path that will have problems with this requirement.
(And it's also not technicallly legal to distribute an app that is not
marked distributable/ in web.xml, but that's a separate issue )
Thanks for the heads up Craig.
Costin
Craig
[EMAIL PROTECTED] wrote:
glenn 2003/01/02 09:12:55
Modified:jk/native CHANGES.txt
jk/native/common jk_lb_worker.c jk_util.c jk_util.h
jk/xdocs/jk workershowto.xml
Log:
Add new lb property sticky_session. If set to 0, requests with session
id's do not have to be routed back to the same Tomcat worker. This is
to support the new Tomcat Session Manager code which supports
persistance of session data across multiple Tomcat instances, such as
JavaGroup's.
Revision ChangesPath
1.9 +4 -1 jakarta-tomcat-connectors/jk/native/CHANGES.txt
Index: CHANGES.txt
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CHANGES.txt 2 Jan 2003 13:00:59 - 1.8
+++ CHANGES.txt 2 Jan 2003 17:12:55 - 1.9
@@ -6,6 +6,9 @@
[glenn]
* Apache 2/1.3, if Tomcat returns an error but not content,
let Apache handle processing the error returned by Tomcat.
+* Added the load balancer sticky_session property. If set to 0
+ requests with servlet SESSION ID's can be routed to any Tomcat
+ worker. Default is 1, sessions are sticky.
Changes with JK 1.2.2:
* tomcat_trend.pl updated script to support changed logging of
1.12 +9 -3
jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.11 retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jk_lb_worker.c 30 Oct 2002 21:17:34 - 1.11
+++ jk_lb_worker.c 2 Jan 2003 17:12:55 - 1.12
@@ -103,6 +103,7 @@
jk_worker_t worker;
int in_local_worker_mode;
int local_worker_only;
+int sticky_session;
};
typedef struct lb_worker lb_worker_t;
@@ -254,8 +255,12 @@
worker_record_t *rc = NULL;
double lb_min = 0.0;
unsigned i;
-char *session_route = get_session_route(s);
-
+char *session_route = NULL;
+
+if (p-sticky_session) {
+session_route = get_session_route(s);
+}
+
if(session_route) {
for(i = 0 ; i p-num_of_workers ; i++) {
if(0 == strcmp(session_route, p-lb_workers[i].name)) {
@@ -421,6 +426,7 @@
unsigned num_of_workers;
p-in_local_worker_mode = JK_FALSE;
p-local_worker_only = jk_get_local_worker_only_flag(props,
p-name);
+p-sticky_session = jk_get_is_sticky_session(props, p-name);
if(jk_get_lb_worker_list(props,
p-name,
1.19 +15 -1
jakarta-tomcat-connectors/jk/native/common/jk_util.c
Index: jk_util.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
retrieving revision 1.18 retrieving revision 1.19
diff -u -r1.18 -r1.19
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
hgomez 2002/09/10 01:36:30 Modified:jk/xdocs/jk workershowto.xml Log: Added the documentation on advanced lb ie, local_worker and local_worker_only Revision ChangesPath 1.4 +81 -0 jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml Index: workershowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- workershowto.xml 10 Sep 2002 08:02:49 - 1.3 +++ workershowto.xml 10 Sep 2002 08:36:30 - 1.4 @@ -313,6 +313,87 @@ /subsection +subsection name=Advanced lb Worker properties +p +With JK 1.2.x, new load-balancing and fault-tolerant support has been added via +2 new properties, blocal_worker_only/b and blocal_worker/b. +/p + +p +Let's take an example environment: +/p + +p +A cluster with two nodes (worker1+worker2), running a webserver + tomcat tandem on each node and +a loadbalancer in front of the nodes. +/p + +screen +noteThe advanced router LB worker/note +readworker.list=router/read +note# Define a 'local_worker' worker using ajp13/note +readworker.worker1.port=8009/read +readworker.worker1.host=node1.domain.org/read +readworker.worker1.type=ajp13/read +readworker.worker1.lbfactor=1/read +readworker.worker1.local_worker=1/read +note# Define another 'local_worker' worker using ajp13/note +readworker.worker2.port=8009/read +readworker.worker2.host=node2.domain.org/read +readworker.worker2.type=ajp13/read +readworker.worker2.lbfactor=1/read +readworker.worker2.local_worker=0/read +note# Define the LB worker/note +readworker.router.type=lb/read +readworker.router.balanced_workers=worker1,worker2/read +readworker.router.local_worker_only=1/read +/screen + +p +The blocal_worker/b flag on worker1 and worker2 tells the blb_worker/b which connections are going +to the local worker. +/p + +p +If local_worker is an int and is not 0 it is set to JK_TRUE and marked as local worker, JK_FALSE otherwise. +If in minimum one worker is marked as local worker, lb_worker is in local worker mode. +All local workers are moved to the beginning of the internal worker list in lb_worker during validation. +/p + +p +This means that if a request with a session id comes in it would be routed to the appropriate worker. +If this worker is down it will be send to the first local worker which is not in error state. +/p + +p +If a request without a session comes in, it would be routed to the first local worker. +If all local worker are in error state, then the 'local_worker_only' flag is important. +If it was set to an int and this wasn't 0 it is set to JK_TRUE, JK_FALSE otherwise. With set to JK_TRUE, this request gets an error response. If set to JK_FALSE lb_worker tries to route the request to another balanced worker. +/p + +p +If one of the worker was in error state and has recovered nothing changes. +The local worker will be check for requests without a session id (and with a session on himself) and +the other worker will only be checked if a request with a session id of this worker comes in. +/p + +p +Why do we need souch a complex behavior ? +/p + +p +We need a graceful shut down of a node for maintenance. The balancer in front asks a special port on each +node periodically. If we want to remove a node from the cluster, we switch off this port. +The loadbalancer can't connect to it and marks the node as down. +But we don't move the sessions to another node. In this environment it is an error if the balancer sends a request without a session to an apache+mod_jk+tomcat which port is switched off. And if the load balancer determines that a node is down no other node is allowed to send a request without a session to it. Only requests with old sessions on the switched off node would be routed to this node. After some time nobody uses the old sessions and the sessions will time out. Then nobody uses this node, because all session are gone and the node is unreachable without a session-id in the request. If someone uses a session which timed out, our servlet system sends a redirect response without a session id to the browser. This is necessary for me, because on a switched off node apache and tomcat can still be up and running, but they are in an old state and should only be asked for valid old sessions. After the last session timed out, I could update the node etc. without killing sessions or moving them to another node. Sometimes we have a lot of big objects in our sessions, so it would be really time consuming to move them. +/p + +p +The defaults are still local_worker: 0 and local_worker_only:0 +/p + +/subsection + subsection name=jni Worker properties p The jni
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
hgomez 2002/09/09 02:16:42 Added: jk/xdocs/jk workershowto.xml Log: Add WorkersHowTo (still need works and review). I'd like to see commiters check cache_timeout and socket_timeout. Also I'll need informations of load balancing settings for error mode only (failover) Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml Index: workershowto.xml === ?xml version=1.0 encoding=ISO-8859-1 ? document properties titleWorkers HowTo/title author email=[EMAIL PROTECTED]Henri Gomez/author author email=[EMAIL PROTECTED]Gal Shachor/author /properties section name=Introduction p A Tomcat worker is a Tomcat instance that is waiting to execute servlets on behalf of some web server. For example, we can have a web server such as Apache forwarding servlet requests to a Tomcat process (the worker) running behind it. /p p The scenario described above is a very simple one; in fact one can configure multiple Tomcat workers to serve servlets on behalf of a certain web server. The reasons for such configuration can be: /p ul li We want different contexts to be served by different Tomcat workers to provide a development environment where all the developers share the same web server but own a Tomcat worker of their own. /li li We want different virtual hosts served by different Tomcat processes to provide a clear separation between sites belonging to different companies. /li li We want to provide load balancing, meaning run multiple Tomcat workers each on a machine of its own and distribute the requests between them. /li /ul p There are probably more reasons for having multiple workers but I guess that this list is enough... Tomcat workers are defined in a properties file dubbed workers.properties and this tutorial explains how to work with it. /p p This document was originally part of bTomcat: A Minimalistic User's Guide/b written by Gal Shachor, but has been split off for organizational reasons. /p /section section name=Defining Workers p Defining workers to the Tomcat web server plugin can be done using a properties file (a sample file named workers.properties is available in the conf/ directory). /p p the file contains entries of the following form: /p p bworker.list/b=lt;a comma separated list of worker namesgt; /p screen notethe list of workers/note readworker.list= worker1, worker2/read /screen p When starting up, the web server plugin will instantiate the workers whose name appears in the bworker.list/b property, these are also the workers to whom you can map requests. /p subsection name=Workers Type p Each named worker should also have a few entries to provide additional information on his behalf. This information includes the worker's type and other related worker information. Currently the following worker types that exists are (jk 1.2.0): /p table trthType/ththDescription/th/tr trtdajp12/tdtdThis worker knows how to forward requests to out-of-process Tomcat workers using the ajpv12 protocol./td/tr trtdajp13/tdtdThis worker knows how to forward requests to out-of-process Tomcat workers using the ajpv13 protocol./td/tr trtdjni/tdtdThis worker knows how to forward requests to in-process Tomcat workers using JNI./td/tr trtdlb/tdtdThis is a load-balancing worker; it knows how to provide round-robin based sticky load balancing with a certain level of fault-tolerance./td/tr /table p Defining workers of a certain type should be done with the following property format: /p p bworker/b. bworker name/b.btype/b=lt;worker typegt; Where worker name is the name assigned to the worker and the worker type is one of the four types defined in the table (a worker name may not contain any space (a good naming convention for queue named should follow the Java variable naming rules). /p screen noteDefines a worker named local that uses the ajpv12 protocol to forward requests to a Tomcat process./note readworker.local.type=ajp12/read noteDefines a worker named remote that uses the ajpv13 protocol to forward requests to a Tomcat process./note readworker.remote.type=ajp13/read noteDefines a worker named fast that uses JNI to forward requests to a Tomcat process./note readworker.fast.type=jni/read noteDefines a worker named loadbalancer that loadbalances several Tomcat processes transparently./note readworker.loadbalancer.type=lb/read /screen /subsection /section section name=Setting Worker Properties p After defining the workers you can also specify properties for them. Properties can be specified in the following manner: /p p worker.lt;worker namegt;.lt;propertygt;=lt;property valuegt; /p
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml
hgomez 2002/09/09 02:56:35 Modified:jk/xdocs/jk workershowto.xml Log: Added JNI informations Revision ChangesPath 1.2 +87 -1 jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml Index: workershowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/workershowto.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- workershowto.xml 9 Sep 2002 09:16:42 - 1.1 +++ workershowto.xml 9 Sep 2002 09:56:35 - 1.2 @@ -306,7 +306,7 @@ screen note The worker balance1 while use real workers worker1 and worker2/note -readworker.balance1.balanced_workers= worker1, worker2/read +readworker.balance1.balanced_workers=worker1, worker2/read /screen /subsection @@ -432,6 +432,92 @@ /subsection +subsection name=Property file macros +p +You can define macros in the property files. +These macros let you define properties and later on use them while +constructing other properties and it's very usefull when you want to +change your Java Home, Tomcat Home or OS path separator +/p + +screen +noteproperty example, don't hardcode path separator/note +ps=\ +readworkers.tomcat_home=d:\tomcat/read +readworkers.java_home=d:\sdk\jdk1.2.2/read +noteUsing macros we'll have : worker.inprocess.class_path=d:\tomcat\classes/note +readworker.inprocess.class_path=$(workers.tomcat_home)$(ps)classes/read +noteUsing macros we'll have : worker.inprocess.class_path=d:\sdk\jdk1.2.2\lib\tools.jar/note +readworker.inprocess.class_path=$(workers.java_home)$(ps)lib$(ps)tools.jar/read +/screen + +/subsection + +/section + +section name=A sample worker.properties +p +Since coping with worker.properties on your own is not an easy thing to do, +a sample worker.properties file is bundled along jk. +/p + +p +You could also find here a sample workers.properties defining : +/p + +ul +li +An ajp12 worker that used the host localhost and the port 8007 +/li +li +An ajp13 worker that used the host localhost and the port 8008 +/li +li +A jni worker +/li +li +A lb worker that load balance the ajp12 and ajp13 workers +/li +/ul + +screen +note# Define some properties/note +readworkers.apache_log=/var/log/httpd//read +readworkers.tomcat_home=/var/tomcat3/read +readworkers.java_home=/opt/IBMJava2-131//read +readps=//read +note# Define 4 workers, 3 real workers using ajp12, ajp13, jni, the last one being a loadbalancing worker/note +readworker.list=worker1, worker2, worker3, worker4/read +note# Set properties for worker1 (ajp12)/note +readworker.worker1.type=ajp12/read +readworker.worker1.host=locahost/read +readworker.worker1.port=8007/read +readworker.worker1.lbfactor=5/read +note# Set properties for worker2 (ajp13)/note +readworker.worker2.type=ajp13/read +readworker.worker2.host=locahost/read +readworker.worker2.port=8009/read +readworker.worker2.lbfactor=50/read +readworker.worker2.cachesize=10/read +readworker.worker2.cache_timeout=600/read +readworker.worker2.socket_keepalive=1/read +readworker.worker2.socket_timeout=300/read +note# Set properties for worker3 (jni)/note +readworker.worker3.type=jni/read +note# Set worker3 classpath/note +readworker.worker3.class_path=$(workers.tomcat_home)$(ps)classes/read +readworker.worker3.class_path=$(workers.tomcat_home)$(ps)lib$(ps)tomcat.jar/read +note# Set worker3 tomcat command line/note +readworker.worker3.cmd_line=-home/read +readworker.worker3.cmd_line=$(workers.tomcat_home)/read +note# Set worker3 Tomcat/JVM settings/note +readworker.worker3.jvm_lib=$(workers.java_home)$(ps)jre$(ps)bin$(ps)classic$(ps)libjvm.so/read +readworker.worker3.stdout=$(workers.apache_log)$(ps)inprocess.stdout/read +readworker.worker3.stderr=$(workers.apache_log)$(ps)inprocess.stderr/read +readworker.worker3.sysprops=tomcat.home=$(workers.tomcat_home)/read +note# Set properties for worker4 (lb) which use worker1 and worker2/note +readworker.worker4.balanced_workers=worker1,worker2/read +/screen /section -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
