RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
We have a winner. Creating a system property at startup and appending it to the session id worked. I was able to run multiple Tomcat instances, both on the same and multiple hosts, with 100% session stickiness. This approach will work perfectly, as we can use the jvmroute parameter as an input argument for the scripts we use to start Tomcat. Thanks to all who helped to get this working. Karl -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Monday, August 15, 2011 4:01 PM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.08.2011 21:20, Pid wrote: On 15/08/2011 19:09, Lataxes, Karl wrote: I wrote the code to generate the session id and add it as an HTTP header at the recommendation of someone on the users list. The problem now is appending the jvmroute to the generated session id in order to get session stickiness to work. If there were some way for the servlet to retrieve the jvmRoute from server.xml, I could append it to the session id and get it to work. I have been looking online for a solution, but have been unable to find one. Try using JMX. Look up the appropriate object (there are clues in the source of the Manager app) and then retrieve the value of the appropriate attribute. I would experiment with setting this value in the servlet.init() method. Or, since you don't really need a jvmRoute but just something to add to the session id which is known by mod_jk, you can set a system property -DjvmRoute=tomcat7A etc. Then retrieve the value as a system property and add it to the session id, separated with a dot. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
Chris, As mentioned in an earlier post, our clients are not web browsers and do not support cookies. Session management is handled via an internally generated session id, and I am attempting to adapt an existing infrastructure to load balancing with session stickiness. The recommendations I received yesterday may be just what I was looking for. I just have to adapt my servlet accordingly. Karl -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, August 15, 2011 4:14 PM To: Tomcat Users List Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl, On 8/15/2011 2:09 PM, Lataxes, Karl wrote: I wrote the code to generate the session id and add it as an HTTP header at the recommendation of someone on the users list. Not to open a whole can of worms, but why are you generating your own session ids? You don't like the format of the existing ids? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Jfh8ACgkQ9CaO5/Lv0PD5UACgt4xmRqavb5Hk3gpZ+ihNxXV2 drgAn39ZqloIyCzBILV7Kw2hL8MTv/QJ =lq+C -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl, On 8/16/2011 7:00 AM, Lataxes, Karl wrote: As mentioned in an earlier post, our clients are not web browsers and do not support cookies. Session management is handled via an internally generated session id, and I am attempting to adapt an existing infrastructure to load balancing with session stickiness. The recommendations I received yesterday may be just what I was looking for. I just have to adapt my servlet accordingly. Okay. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5K0PcACgkQ9CaO5/Lv0PDzTgCgmMJ37huFYFWVG2/iQPJOVJm+ WhcAn2u5xUeZbS+sE/XkfR2BGNFUtYte =j0e1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
Yes, the space before servlet is a copy/paste error.
I made the LogFormat additions to httpd.conf, set the mod_jk logging level to
debug and ran some additional tests.
The session id did appear in the access_log I generated:
2000-1-200-ap-1313413815567
In the mod_jk.log, I also noted several references to the session id, which are
included below. Please note that the original client request went to worker
tomcat7A, but subsequent requests were routed to tomcat7C
[Mon Aug 15 09:10:15.614 2011] [3275:1] [debug]
ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie] =
[JSESSIONID=2000-1-200-ap-1313413815567]
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c (1118):
service sticky_session=1 id='2000-1-200-ap-1313413815567'
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial
sessionid 2000-1-200-ap-1313413815567
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (1001): found best worker tomcat7C
(tomcat7C) using method 'Request'
You can see from the log snippets that .worker_name is not being appended
to the session as expected.
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Saturday, August 13, 2011 8:11 AM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 12.08.2011 15:30, Lataxes, Karl wrote:
The jvmRoute's for both server.xmls are properly set to the worker names and
are not commented out. This was the first thing I verified.
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7A
Engine name=Catalina defaultHost=localhost
jvmRoute=tomcat7C
Here are the settings in workers.properties (worker tomcat7A identical to
tomcat7C except for port, since both are running on the same server for
testing. In production, we will probably install them on separate boxes):
worker.list=loadbalancer,jkstatus
worker.tomcat7C.type=ajp13
worker.tomcat7C.host=host_name
worker.tomcat7C.port=4931
worker.tomcat7C.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
worker.loadbalancer.sticky_session=1
worker.jkstatus.type=status
OK
Here are the JkMount settings in mod_jk.conf:
JkMount /jkmanager/* jkstatus
JkMount / servlet/* loadbalancer
I hope the space before servlet is a copy and paste error and not in the
original config ...
Load balancing is working, but subsequent requests from a single client are
being routed to the other Tomcat instance despite sticky_session being set to
1.
OK, then maybe your cookie header is not OK. To debug:
- Add %{Cookie}i to the LogFormat you are using in Apache. It will log all
cookies. Check the values.
- Add %{JSESSIONID}C to the same LogFormat. It will log the value of the
JSESSIONID cookie found by the web server. Check the values.
- Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the setting
of the cookie (sending a cookie from the server to the client).
Probably of no use for you, since you seem to parse that info in some other way.
- Increase log level of mod_jk to debug or even trace (not in
production) and look at the log lines written when your client sends a request,
which isn't handled sticky.
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.08.2011 17:09, Lataxes, Karl wrote:
Yes, the space before servlet is a copy/paste error.
I made the LogFormat additions to httpd.conf, set the mod_jk logging level to
debug and ran some additional tests.
The session id did appear in the access_log I generated:
2000-1-200-ap-1313413815567
So the session ID is wrong, it does not contain the trailing .tomcat7A
to allow sticky routing.
Whatever generates the session id doesn't generate a correct one which
supports stickyness. The session id doesn't look like a normal Tomcat
session id, so it seems something else is setting the JSESSIONID cookie,
like a custom sesion manager. You need to find that piece of code and
fix it (to append the jvmRoute to the id).
Regards,
Rainer
In the mod_jk.log, I also noted several references to the session id, which
are included below. Please note that the original client request went to
worker tomcat7A, but subsequent requests were routed to tomcat7C
[Mon Aug 15 09:10:15.614 2011] [3275:1] [debug]
ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie] =
[JSESSIONID=2000-1-200-ap-1313413815567]
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c
(1118): service sticky_session=1 id='2000-1-200-ap-1313413815567'
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial
sessionid 2000-1-200-ap-1313413815567
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (1001): found best worker tomcat7C
(tomcat7C) using method 'Request'
You can see from the log snippets that .worker_name is not being appended
to the session as expected.
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Saturday, August 13, 2011 8:11 AM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 12.08.2011 15:30, Lataxes, Karl wrote:
The jvmRoute's for both server.xmls are properly set to the worker names and
are not commented out. This was the first thing I verified.
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7A
Engine name=Catalina defaultHost=localhost
jvmRoute=tomcat7C
Here are the settings in workers.properties (worker tomcat7A identical to
tomcat7C except for port, since both are running on the same server for
testing. In production, we will probably install them on separate boxes):
worker.list=loadbalancer,jkstatus
worker.tomcat7C.type=ajp13
worker.tomcat7C.host=host_name
worker.tomcat7C.port=4931
worker.tomcat7C.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
worker.loadbalancer.sticky_session=1
worker.jkstatus.type=status
OK
Here are the JkMount settings in mod_jk.conf:
JkMount /jkmanager/* jkstatus
JkMount / servlet/* loadbalancer
I hope the space before servlet is a copy and paste error and not in the
original config ...
Load balancing is working, but subsequent requests from a single client are
being routed to the other Tomcat instance despite sticky_session being set
to 1.
OK, then maybe your cookie header is not OK. To debug:
- Add %{Cookie}i to the LogFormat you are using in Apache. It will log all
cookies. Check the values.
- Add %{JSESSIONID}C to the same LogFormat. It will log the value of the
JSESSIONID cookie found by the web server. Check the values.
- Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the setting
of the cookie (sending a cookie from the server to the client).
Probably of no use for you, since you seem to parse that info in some other
way.
- Increase log level of mod_jk to debug or even trace (not in
production) and look at the log lines written when your client sends a
request, which isn't handled sticky.
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
I wrote the code to generate the session id and add it as an HTTP header at the
recommendation of someone on the users list. The problem now is appending the
jvmroute to the generated session id in order to get session stickiness to
work. If there were some way for the servlet to retrieve the jvmRoute from
server.xml, I could append it to the session id and get it to work. I have
been looking online for a solution, but have been unable to find one.
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Monday, August 15, 2011 12:52 PM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.08.2011 17:09, Lataxes, Karl wrote:
Yes, the space before servlet is a copy/paste error.
I made the LogFormat additions to httpd.conf, set the mod_jk logging level to
debug and ran some additional tests.
The session id did appear in the access_log I generated:
2000-1-200-ap-1313413815567
So the session ID is wrong, it does not contain the trailing .tomcat7A
to allow sticky routing.
Whatever generates the session id doesn't generate a correct one which supports
stickyness. The session id doesn't look like a normal Tomcat session id, so it
seems something else is setting the JSESSIONID cookie, like a custom sesion
manager. You need to find that piece of code and fix it (to append the jvmRoute
to the id).
Regards,
Rainer
In the mod_jk.log, I also noted several references to the session id,
which are included below. Please note that the original client
request went to worker tomcat7A, but subsequent requests were routed
to tomcat7C
[Mon Aug 15 09:10:15.614 2011] [3275:1] [debug]
ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie]
= [JSESSIONID=2000-1-200-ap-1313413815567]
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c
(1118): service sticky_session=1 id='2000-1-200-ap-1313413815567'
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial
sessionid 2000-1-200-ap-1313413815567 [Mon Aug 15 09:10:18.495 2011] [3275:1]
[debug] get_most_suitable_worker::jk_lb_worker.c (1001): found best worker
tomcat7C (tomcat7C) using method 'Request'
You can see from the log snippets that .worker_name is not being appended
to the session as expected.
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Saturday, August 13, 2011 8:11 AM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat
7.0.8
On 12.08.2011 15:30, Lataxes, Karl wrote:
The jvmRoute's for both server.xmls are properly set to the worker names and
are not commented out. This was the first thing I verified.
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7A
Engine name=Catalina defaultHost=localhost
jvmRoute=tomcat7C
Here are the settings in workers.properties (worker tomcat7A identical to
tomcat7C except for port, since both are running on the same server for
testing. In production, we will probably install them on separate boxes):
worker.list=loadbalancer,jkstatus
worker.tomcat7C.type=ajp13
worker.tomcat7C.host=host_name
worker.tomcat7C.port=4931
worker.tomcat7C.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
worker.loadbalancer.sticky_session=1
worker.jkstatus.type=status
OK
Here are the JkMount settings in mod_jk.conf:
JkMount /jkmanager/* jkstatus
JkMount / servlet/* loadbalancer
I hope the space before servlet is a copy and paste error and not in the
original config ...
Load balancing is working, but subsequent requests from a single client are
being routed to the other Tomcat instance despite sticky_session being set
to 1.
OK, then maybe your cookie header is not OK. To debug:
- Add %{Cookie}i to the LogFormat you are using in Apache. It will log all
cookies. Check the values.
- Add %{JSESSIONID}C to the same LogFormat. It will log the value of the
JSESSIONID cookie found by the web server. Check the values.
- Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the setting
of the cookie (sending a cookie from the server to the client).
Probably of no use for you, since you seem to parse that info in some other
way.
- Increase log level of mod_jk to debug or even trace (not in
production) and look at the log lines written when your client sends a
request, which isn't handled sticky.
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15/08/2011 19:09, Lataxes, Karl wrote:
I wrote the code to generate the session id and add it as an HTTP header at
the recommendation of someone on the users list. The problem now is
appending the jvmroute to the generated session id in order to get session
stickiness to work. If there were some way for the servlet to retrieve the
jvmRoute from server.xml, I could append it to the session id and get it to
work. I have been looking online for a solution, but have been unable to
find one.
Try using JMX.
Look up the appropriate object (there are clues in the source of the
Manager app) and then retrieve the value of the appropriate attribute.
I would experiment with setting this value in the servlet.init() method.
p
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Monday, August 15, 2011 12:52 PM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.08.2011 17:09, Lataxes, Karl wrote:
Yes, the space before servlet is a copy/paste error.
I made the LogFormat additions to httpd.conf, set the mod_jk logging level
to debug and ran some additional tests.
The session id did appear in the access_log I generated:
2000-1-200-ap-1313413815567
So the session ID is wrong, it does not contain the trailing .tomcat7A
to allow sticky routing.
Whatever generates the session id doesn't generate a correct one which
supports stickyness. The session id doesn't look like a normal Tomcat session
id, so it seems something else is setting the JSESSIONID cookie, like a
custom sesion manager. You need to find that piece of code and fix it (to
append the jvmRoute to the id).
Regards,
Rainer
In the mod_jk.log, I also noted several references to the session id,
which are included below. Please note that the original client
request went to worker tomcat7A, but subsequent requests were routed
to tomcat7C
[Mon Aug 15 09:10:15.614 2011] [3275:1] [debug]
ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie]
= [JSESSIONID=2000-1-200-ap-1313413815567]
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c
(1118): service sticky_session=1 id='2000-1-200-ap-1313413815567'
[Mon Aug 15 09:10:18.495 2011] [3275:1] [debug]
get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial
sessionid 2000-1-200-ap-1313413815567 [Mon Aug 15 09:10:18.495 2011]
[3275:1] [debug] get_most_suitable_worker::jk_lb_worker.c (1001): found best
worker tomcat7C (tomcat7C) using method 'Request'
You can see from the log snippets that .worker_name is not being
appended to the session as expected.
-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Saturday, August 13, 2011 8:11 AM
To: users@tomcat.apache.org
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat
7.0.8
On 12.08.2011 15:30, Lataxes, Karl wrote:
The jvmRoute's for both server.xmls are properly set to the worker names
and are not commented out. This was the first thing I verified.
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7A
Engine name=Catalina defaultHost=localhost
jvmRoute=tomcat7C
Here are the settings in workers.properties (worker tomcat7A identical to
tomcat7C except for port, since both are running on the same server for
testing. In production, we will probably install them on separate boxes):
worker.list=loadbalancer,jkstatus
worker.tomcat7C.type=ajp13
worker.tomcat7C.host=host_name
worker.tomcat7C.port=4931
worker.tomcat7C.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
worker.loadbalancer.sticky_session=1
worker.jkstatus.type=status
OK
Here are the JkMount settings in mod_jk.conf:
JkMount /jkmanager/* jkstatus
JkMount / servlet/* loadbalancer
I hope the space before servlet is a copy and paste error and not in the
original config ...
Load balancing is working, but subsequent requests from a single client are
being routed to the other Tomcat instance despite sticky_session being set
to 1.
OK, then maybe your cookie header is not OK. To debug:
- Add %{Cookie}i to the LogFormat you are using in Apache. It will log all
cookies. Check the values.
- Add %{JSESSIONID}C to the same LogFormat. It will log the value of the
JSESSIONID cookie found by the web server. Check the values.
- Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the
setting of the cookie (sending a cookie from the server to the client).
Probably of no use for you, since you seem to parse that info in some other
way.
- Increase log level of mod_jk to debug or even trace (not in
production) and look at the log lines written when your client sends a
request, which isn't handled sticky.
Regards,
Rainer
-
To unsubscribe, e-mail:
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.08.2011 21:20, Pid wrote: On 15/08/2011 19:09, Lataxes, Karl wrote: I wrote the code to generate the session id and add it as an HTTP header at the recommendation of someone on the users list. The problem now is appending the jvmroute to the generated session id in order to get session stickiness to work. If there were some way for the servlet to retrieve the jvmRoute from server.xml, I could append it to the session id and get it to work. I have been looking online for a solution, but have been unable to find one. Try using JMX. Look up the appropriate object (there are clues in the source of the Manager app) and then retrieve the value of the appropriate attribute. I would experiment with setting this value in the servlet.init() method. Or, since you don't really need a jvmRoute but just something to add to the session id which is known by mod_jk, you can set a system property -DjvmRoute=tomcat7A etc. Then retrieve the value as a system property and add it to the session id, separated with a dot. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl, On 8/15/2011 2:09 PM, Lataxes, Karl wrote: I wrote the code to generate the session id and add it as an HTTP header at the recommendation of someone on the users list. Not to open a whole can of worms, but why are you generating your own session ids? You don't like the format of the existing ids? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Jfh8ACgkQ9CaO5/Lv0PD5UACgt4xmRqavb5Hk3gpZ+ihNxXV2 drgAn39ZqloIyCzBILV7Kw2hL8MTv/QJ =lq+C -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 12.08.2011 15:30, Lataxes, Karl wrote:
The jvmRoute's for both server.xmls are properly set to the worker names and
are not commented out. This was the first thing I verified.
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7A
Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7C
Here are the settings in workers.properties (worker tomcat7A identical to
tomcat7C except for port, since both are running on the same server for
testing. In production, we will probably install them on separate boxes):
worker.list=loadbalancer,jkstatus
worker.tomcat7C.type=ajp13
worker.tomcat7C.host=host_name
worker.tomcat7C.port=4931
worker.tomcat7C.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat7A,tomcat7C
worker.loadbalancer.sticky_session=1
worker.jkstatus.type=status
OK
Here are the JkMount settings in mod_jk.conf:
JkMount /jkmanager/* jkstatus
JkMount / servlet/* loadbalancer
I hope the space before servlet is a copy and paste error and not in
the original config ...
Load balancing is working, but subsequent requests from a single client are
being routed to the other Tomcat instance despite sticky_session being set to
1.
OK, then maybe your cookie header is not OK. To debug:
- Add %{Cookie}i to the LogFormat you are using in Apache. It will log
all cookies. Check the values.
- Add %{JSESSIONID}C to the same LogFormat. It will log the value of the
JSESSIONID cookie found by the web server. Check the values.
- Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the
setting of the cookie (sending a cookie from the server to the client).
Probably of no use for you, since you seem to parse that info in some
other way.
- Increase log level of mod_jk to debug or even trace (not in
production) and look at the log lines written when your client sends a
request, which isn't handled sticky.
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 11.08.2011 15:32, Lataxes, Karl wrote: OK, I'm getting close. On the server side, I'm adding a Set-Cookie header containing the session id I want to use. The client emulator I am using has similarly been modified to add a Cookie header with the session id sent by the server, but sticky sessions are still not working. In the mod_jk log, there is a searching worker for partial sessionid reference that contains the correct session id, but .worker was not appended. In my workers.properties file, sticky_session is set to 1. The jvmRoute parameters in my respective Tomcat server.xml files are set to the workers identified in the workers.properties file as well. What do I have to do to append .worker to the outgoing session id? When Tomcat sets a session cookie, and you correctly set the jvmRoute in server.xml, it automatically adds the value of jvmRoute to the end of the session id, separated with a dot. Make sure you did not set the jvmRoute in some line in server.xml that is cmmented out. To make stickyness with mod_jk happen, the jvmRoute used for Tomcat should be equal to the name of the worker pointing to the Tomcat instance. Finally you add all those workers to a load balancer worker in mod_jk and JkMount the URLs to the load balancer worker. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
The jvmRoute's for both server.xmls are properly set to the worker names and are not commented out. This was the first thing I verified. Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7A Engine name=Catalina defaultHost=localhost jvmRoute=tomcat7C Here are the settings in workers.properties (worker tomcat7A identical to tomcat7C except for port, since both are running on the same server for testing. In production, we will probably install them on separate boxes): worker.list=loadbalancer,jkstatus worker.tomcat7C.type=ajp13 worker.tomcat7C.host=host_name worker.tomcat7C.port=4931 worker.tomcat7C.lbfactor=1 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=tomcat7A,tomcat7C worker.loadbalancer.sticky_session=1 worker.jkstatus.type=status Here are the JkMount settings in mod_jk.conf: JkMount /jkmanager/* jkstatus JkMount / servlet/* loadbalancer Load balancing is working, but subsequent requests from a single client are being routed to the other Tomcat instance despite sticky_session being set to 1. -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, August 12, 2011 4:17 AM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 11.08.2011 15:32, Lataxes, Karl wrote: OK, I'm getting close. On the server side, I'm adding a Set-Cookie header containing the session id I want to use. The client emulator I am using has similarly been modified to add a Cookie header with the session id sent by the server, but sticky sessions are still not working. In the mod_jk log, there is a searching worker for partial sessionid reference that contains the correct session id, but .worker was not appended. In my workers.properties file, sticky_session is set to 1. The jvmRoute parameters in my respective Tomcat server.xml files are set to the workers identified in the workers.properties file as well. What do I have to do to append .worker to the outgoing session id? When Tomcat sets a session cookie, and you correctly set the jvmRoute in server.xml, it automatically adds the value of jvmRoute to the end of the session id, separated with a dot. Make sure you did not set the jvmRoute in some line in server.xml that is cmmented out. To make stickyness with mod_jk happen, the jvmRoute used for Tomcat should be equal to the name of the worker pointing to the Tomcat instance. Finally you add all those workers to a load balancer worker in mod_jk and JkMount the URLs to the load balancer worker. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
OK, I'm getting close. On the server side, I'm adding a Set-Cookie header containing the session id I want to use. The client emulator I am using has similarly been modified to add a Cookie header with the session id sent by the server, but sticky sessions are still not working. In the mod_jk log, there is a searching worker for partial sessionid reference that contains the correct session id, but .worker was not appended. In my workers.properties file, sticky_session is set to 1. The jvmRoute parameters in my respective Tomcat server.xml files are set to the workers identified in the workers.properties file as well. What do I have to do to append .worker to the outgoing session id? -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Tuesday, August 09, 2011 5:09 PM To: Tomcat Users List Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 Rainer Jung wrote: On 09.08.2011 20:45, Lataxes, Karl wrote: Our clients cannot send or process JSESSIONIDs as they are not web browsers, but proprietary equipment running embedded software that sends HTTP POST messages to a servlet on our internal network. The servlet keeps track of sessions internally by assigning a session id which is contained within the HTTP request body. I believe my best solution would be to send an additional header containing the session id with the servlet response and using that for sticky sessions. I am working with our embedded software developers on sending this header back to the servlet during subsequent client requests to facilitate sticky sessions. I know I will probably have to go to Apache 2.2 to accommodate this, but that was something I expected. Are you aware of the fact, that a cookie *is* an additional HTTP header, namely the header named Cookie? So if you can set HTTP headers to values you can define, then you *can* send cookies. That was a much shorter way to get to the same conclusion as my earlier contribution.. :-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rainer, On 8/9/2011 4:49 PM, Rainer Jung wrote: On 09.08.2011 20:45, Lataxes, Karl wrote: Our clients cannot send or process JSESSIONIDs as they are not web browsers, but proprietary equipment running embedded software that sends HTTP POST messages to a servlet on our internal network. The servlet keeps track of sessions internally by assigning a session id which is contained within the HTTP request body. I believe my best solution would be to send an additional header containing the session id with the servlet response and using that for sticky sessions. I am working with our embedded software developers on sending this header back to the servlet during subsequent client requests to facilitate sticky sessions. I know I will probably have to go to Apache 2.2 to accommodate this, but that was something I expected. Are you aware of the fact, that a cookie *is* an additional HTTP header, namely the header named Cookie? So if you can set HTTP headers to values you can define, then you *can* send cookies. +1 To Karl: I don't think any of your questions are stupid. You're just trying to solve a problem that's complicated. We are trying to coax a solution out of the situation :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Cs9MACgkQ9CaO5/Lv0PB+/QCeJL4+sjYbPf2C25cyOo6UO6k2 lt8AoK74fgDDcXmv3KW76tvw8e/mjqg3 =Z99M -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
Our clients cannot send or process JSESSIONIDs as they are not web browsers,
but proprietary equipment running embedded software that sends HTTP POST
messages to a servlet on our internal network. The servlet keeps track of
sessions internally by assigning a session id which is contained within the
HTTP request body.
I believe my best solution would be to send an additional header containing the
session id with the servlet response and using that for sticky sessions. I am
working with our embedded software developers on sending this header back to
the servlet during subsequent client requests to facilitate sticky sessions. I
know I will probably have to go to Apache 2.2 to accommodate this, but that was
something I expected.
I am somewhat unfamiliar with these aspects of Tomcat/Apache and I'm learning a
lot of this stuff on the fly, so please forgive the stupid questions.
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Monday, August 08, 2011 12:14 PM
To: Tomcat Users List
Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Karl,
On 8/5/2011 7:49 AM, Lataxes, Karl wrote:
After some testing, I determined that appending the session ID to the
URL will not work.
Why not?
I can, however, add the session ID as a new HTTP header, but I have to
determine which modules to use (mod_headers, mod_proxy,
mod_proxy_http, mod_proxy_balancer?)
How about just having the client send JSESSIONID in the way that Tomcat expects
it?
and how to configure sticky sessions using the new HTTP header. I am
somewhat unfamiliar with this aspect of Apache, so is anyone able to
point me in the right direction?
You said that your client was sending this information:
session-id= unique_client_identifier-current_time_in_milliseconds
but you never said where that information was. If it's in the query-string of
the URL, then it should be easy to fetch and set into a request header.
To fetch the session id, you can do something like this:
SetEnvIf Request_URI /session-id=([A-Za-z0-1.]+)-/ SESSION_ID=$1
That will set an environment variable SESSION_ID to an id passed-in via the
query string (unless you have the misfortune of having
session-id=[A-Za-z0-1.]+ somewhere else in your URL, too). You might have to
tweak the regular expression if it won't match your unique_client_identifier
which I'm assuming is the Tomcat session id.
If you can use mod_headers /before/ mod_jk gets it's hands on things, you ought
to be able to do something like this:
RequestHeader append Cookie JSESSIONID=%{SESSION_ID}e
That will set the JSESSIONID cookie header to the value of the session id
retrieved from the query string above.
I hope that gets you on the right track.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5ACzMACgkQ9CaO5/Lv0PBQDgCeKtjV7nqZ/HoE/i3Wz2oLtwqy
HqcAn0rIRIvf5FZwVl1L1npDqKy/iL26
=5Fxb
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 09.08.2011 20:45, Lataxes, Karl wrote: Our clients cannot send or process JSESSIONIDs as they are not web browsers, but proprietary equipment running embedded software that sends HTTP POST messages to a servlet on our internal network. The servlet keeps track of sessions internally by assigning a session id which is contained within the HTTP request body. I believe my best solution would be to send an additional header containing the session id with the servlet response and using that for sticky sessions. I am working with our embedded software developers on sending this header back to the servlet during subsequent client requests to facilitate sticky sessions. I know I will probably have to go to Apache 2.2 to accommodate this, but that was something I expected. Are you aware of the fact, that a cookie *is* an additional HTTP header, namely the header named Cookie? So if you can set HTTP headers to values you can define, then you *can* send cookies. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
Be reassured : your questions are not stupid. It is just that your situation is a bit unusual, so it takes us time to figure out precisely what you want to achieve, and to try to fit this (if it has to be fitted) to how Tomcat handles sessions and session-id's. But maybe this is just a misconception on our part, and some parts of your explanations are still not very clear. So let's try to summarise. a) the clients in this case are not browsers, but proprietary equipment which runs some software (also under your direct/indirect control) which is capable of receiving/sending messages with a webserver (in this case Tomcat, fronted by Apache httpd), using the HTTP protocol. But they cannot handle HTTP cookies, and they cannot handle URL-rewriting. b) on this Tomcat webserver, runs an application (composed of one or more servlets), and this is what the appliances in question communicate with. The Tomcat webserver is fronted by an Apache httpd server which acts as a load-balancer and/or router to the back-end Tomcat(s). c) you have a need to handle some form of session between a given client and the webserver. This means that the individual requests/responses between an appliance and the webserver are not independent of one another (which is normally the case with the standard HTTP protocol), but your client and your webserver application need to maintain a form of state between them. d) what is not so clear, is if your notion of session matches Tomcat's notion of session. On the one hand, you seem to say that your application maintains this session internally, in other words that Tomcat basically knows nothing about these sessions. But you also seem to say that Tomcat should be aware of these internal sessions, for some reason which I do not remember. (Is it because you want Apache httpd to act as a load balancer, and keep sending the requests of one appliance to the same Tomcat as the one with which this appliance started the session ?). e) to handle Tomcat-type sessions, Tomcat's standard built-in mechanisms (and also the mod_jk connector's built-in mechanisms) require this session-id to be exchanged either via cookies, or via a modification of the request URLs. Both of which apparently your appliances are unable to handle. So there are apparently two kinds of solutions : a) to modify the internal mechanisms of Tomcat and mod_jk to handle the exchange of session-id differently (in a way which your appliances can handle) or b) to create some kind of adaptor which would take a session-id as generated by the standard Tomcat mechanisms and translate it to a form which your appliances understand; and vice-versa, to take the session-id as your appliances can send it, and transform it on-the-fly to a form which mod_jk and Tomcat can understand and handle (cookie or URL modification). (a) is possible, since after all both are open-source. But it is also likely to be hard to do, because the code which handles this is probably not trivial, and there are probably umpteen possibilities to do this wrong. (And you could hire a mod_jk specialist to do this for you; there are several on this list probably willing to take on a job like that) (b) seems (to me) an easier path, but there are some limitations. First, for some intermediate piece of software to go and get this session-id out of a POST body sent by the client, is complicated (need to parse the body) and inefficient (need to parse each body of each request). It may also a problem for the Tomcat application side, because when something at the Tomcat level reads the request body, that body is read, and it is no longer available for the application to read (at least not via the standard request API). So it would be better indeed if the session-id sent by the client was sent in a HTTP header. That is easier to parse, more efficient and does not interfere with the subsequent application's parsing of the request body. What this intermediate piece of software would need to do, is to parse the HTTP headers coming from the client, find this session-id header, and modify the request URL to add the session-id to it. Or, replace this HTTP header by another header (or add another one) (a JSESSIONID Cookie header), which mod_jk and Tomcat can understand. This would need to be done early, when the request first reaches Apache httpd, and before mod_jk uses this information to balance this request to one Tomcat or the other. (All of which make me think now however, that if you can modify the client code to add such a special header, then why can that header not be a Cookie header which the standard mod_jk/Tomcat could handle ? creating a Cookie header is not that hard.) In the other direction, Tomcat sends a Set-Cookie header (named JSESSION-ID) with every response, and this cookie contains the Tomcat session-id. So the intermediate piece of software would need to read that response Set-Cookie header, and
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
Rainer Jung wrote: On 09.08.2011 20:45, Lataxes, Karl wrote: Our clients cannot send or process JSESSIONIDs as they are not web browsers, but proprietary equipment running embedded software that sends HTTP POST messages to a servlet on our internal network. The servlet keeps track of sessions internally by assigning a session id which is contained within the HTTP request body. I believe my best solution would be to send an additional header containing the session id with the servlet response and using that for sticky sessions. I am working with our embedded software developers on sending this header back to the servlet during subsequent client requests to facilitate sticky sessions. I know I will probably have to go to Apache 2.2 to accommodate this, but that was something I expected. Are you aware of the fact, that a cookie *is* an additional HTTP header, namely the header named Cookie? So if you can set HTTP headers to values you can define, then you *can* send cookies. That was a much shorter way to get to the same conclusion as my earlier contribution.. :-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 09.08.2011 23:08, André Warnier wrote: Rainer Jung wrote: On 09.08.2011 20:45, Lataxes, Karl wrote: Are you aware of the fact, that a cookie *is* an additional HTTP header, namely the header named Cookie? So if you can set HTTP headers to values you can define, then you *can* send cookies. That was a much shorter way to get to the same conclusion as my earlier contribution.. :-) Der Weg ist das Ziel (The journey is the reward). Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Karl,
On 8/5/2011 7:49 AM, Lataxes, Karl wrote:
After some testing, I determined that appending the session ID to
the URL will not work.
Why not?
I can, however, add the session ID as a new HTTP header, but I have
to determine which modules to use (mod_headers, mod_proxy,
mod_proxy_http, mod_proxy_balancer?)
How about just having the client send JSESSIONID in the way that Tomcat
expects it?
and how to configure sticky sessions using the new HTTP header. I am
somewhat unfamiliar with this aspect of Apache, so is anyone able to
point me in the right direction?
You said that your client was sending this information:
session-id= unique_client_identifier-current_time_in_milliseconds
but you never said where that information was. If it's in the
query-string of the URL, then it should be easy to fetch and set into a
request header.
To fetch the session id, you can do something like this:
SetEnvIf Request_URI /session-id=([A-Za-z0-1.]+)-/ SESSION_ID=$1
That will set an environment variable SESSION_ID to an id passed-in via
the query string (unless you have the misfortune of having
session-id=[A-Za-z0-1.]+ somewhere else in your URL, too). You might
have to tweak the regular expression if it won't match your
unique_client_identifier which I'm assuming is the Tomcat session id.
If you can use mod_headers /before/ mod_jk gets it's hands on things,
you ought to be able to do something like this:
RequestHeader append Cookie JSESSIONID=%{SESSION_ID}e
That will set the JSESSIONID cookie header to the value of the session
id retrieved from the query string above.
I hope that gets you on the right track.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5ACzMACgkQ9CaO5/Lv0PBQDgCeKtjV7nqZ/HoE/i3Wz2oLtwqy
HqcAn0rIRIvf5FZwVl1L1npDqKy/iL26
=5Fxb
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
After some testing, I determined that appending the session ID to the URL will not work. I can, however, add the session ID as a new HTTP header, but I have to determine which modules to use (mod_headers, mod_proxy, mod_proxy_http, mod_proxy_balancer?) and how to configure sticky sessions using the new HTTP header. I am somewhat unfamiliar with this aspect of Apache, so is anyone able to point me in the right direction? Thanks -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Friday, July 29, 2011 11:36 AM To: Tomcat Users List Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 Lataxes, Karl wrote: I believe this may what you requested. The parameter information I extracted from the request was contained in the request body, as well as the session ID I mentioned previously. If we need to include additional coding in both our servlet and client software, then it's better we find out now. URL: http://host:port/servlet_path/servlet/servlet_name/ PATH: / HEADER INFORMATION HEADER: user-agent 'Java/1.6.0_16' HEADER: host 'host:port' HEADER: accept 'text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2' HEADER: connection 'keep-alive' HEADER: content-type 'application/x-www-form-urlencoded' HEADER: content-length '134' PARAMETER INFORMATION PARAM: parameter_name 'parameter_value' -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, July 15, 2011 3:22 PM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.07.2011 18:19, Lataxes, Karl wrote: We do not send cookies. Our clients are not web pages but applications embedded in proprietary hardware, which connect to our network via landline telephone or cell modem and access our servlet via HTTP connection. The servlet responds by sending a message containing several parameters in name-value pair format, including a session id that appears as: session-id= unique_client_identifier-current_time_in_milliseconds. The client will respond to the servlet with a message that contains the same session id name-value pair. After initial connection, all client-server communications will contain this unique session id name-value pair. Apache will forward the requests/responses as expected when a single Tomcat node is running. However, for multiple nodes, the requests are forwarded round robin to all nodes. Our system environment prevents us from using session replication between nodes, so we have to use sticky sessions. I do not believe the problem is with Tomcat, but rather how mod_jk routes the requests. Is there any way to configure mod_jk so that it will recognize the session id name-value pair? I did understand your question, but you still did not give the information hntains the session id. The protocol spoken is HTTP and Apache is an HTTP server. So you need to get used to the appropriate language in order to allow us to understand and give a correct answer. That's why I suggested words as query parameters, path info, request headers etc. If the session id is send by the client as part of the request body, then it will become complex and I currently see no solution without a bit of coding. If the id is in headers or somewhere in the URL, you could likely design a solution using mod_proxy_balancer. Regards, Rainer -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, July 15, 2011 9:44 AM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.07.2011 12:48, Lataxes, Karl wrote: Our servlet assigns a session id to a client when it initially contacts the server. The session id consists of session-id, a unique client identifier, and the current time in milliseconds, which is used as session identification for subsequent requests. There are numerous message exchanges between the servlet and client during a typical session, all of which contain the session id. Once the session has successfully ended, the session id is removed from the servlet. Is there any way we can configure mod_jk to recognize the session id in order to route subsequent messages to the original Tomcat node it initially contacted? How does the client present the session id as part of the requests? Query parameter, path info, request header, cookie, ...? Can you five a complete example? Regards, Rainer My 0.02 € : It looks like Karl has access to the source code of the client side, as well as the servlet's. One thing that might help already a lot, is if the client was adding the session-id to each request, either - by appending it to the request URL, as : http://host:port/servlet_path/servlet/servlet_name/;jsessionid=session-id AND/OR - by adding a specific HTTP header, like : X-SESSION-ID: session-id
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
I believe this may what you requested. The parameter information I extracted from the request was contained in the request body, as well as the session ID I mentioned previously. If we need to include additional coding in both our servlet and client software, then it's better we find out now. URL: http://host:port/servlet_path/servlet/servlet_name/ PATH: / HEADER INFORMATION HEADER: user-agent 'Java/1.6.0_16' HEADER: host 'host:port' HEADER: accept 'text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2' HEADER: connection 'keep-alive' HEADER: content-type 'application/x-www-form-urlencoded' HEADER: content-length '134' PARAMETER INFORMATION PARAM: parameter_name 'parameter_value' -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, July 15, 2011 3:22 PM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.07.2011 18:19, Lataxes, Karl wrote: We do not send cookies. Our clients are not web pages but applications embedded in proprietary hardware, which connect to our network via landline telephone or cell modem and access our servlet via HTTP connection. The servlet responds by sending a message containing several parameters in name-value pair format, including a session id that appears as: session-id= unique_client_identifier-current_time_in_milliseconds. The client will respond to the servlet with a message that contains the same session id name-value pair. After initial connection, all client-server communications will contain this unique session id name-value pair. Apache will forward the requests/responses as expected when a single Tomcat node is running. However, for multiple nodes, the requests are forwarded round robin to all nodes. Our system environment prevents us from using session replication between nodes, so we have to use sticky sessions. I do not believe the problem is with Tomcat, but rather how mod_jk routes the requests. Is there any way to configure mod_jk so that it will recognize the session id name-value pair? I did understand your question, but you still did not give the information hntains the session id. The protocol spoken is HTTP and Apache is an HTTP server. So you need to get used to the appropriate language in order to allow us to understand and give a correct answer. That's why I suggested words as query parameters, path info, request headers etc. If the session id is send by the client as part of the request body, then it will become complex and I currently see no solution without a bit of coding. If the id is in headers or somewhere in the URL, you could likely design a solution using mod_proxy_balancer. Regards, Rainer -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, July 15, 2011 9:44 AM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.07.2011 12:48, Lataxes, Karl wrote: Our servlet assigns a session id to a client when it initially contacts the server. The session id consists of session-id, a unique client identifier, and the current time in milliseconds, which is used as session identification for subsequent requests. There are numerous message exchanges between the servlet and client during a typical session, all of which contain the session id. Once the session has successfully ended, the session id is removed from the servlet. Is there any way we can configure mod_jk to recognize the session id in order to route subsequent messages to the original Tomcat node it initially contacted? How does the client present the session id as part of the requests? Query parameter, path info, request header, cookie, ...? Can you five a complete example? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
Lataxes, Karl wrote: I believe this may what you requested. The parameter information I extracted from the request was contained in the request body, as well as the session ID I mentioned previously. If we need to include additional coding in both our servlet and client software, then it's better we find out now. URL: http://host:port/servlet_path/servlet/servlet_name/ PATH: / HEADER INFORMATION HEADER: user-agent 'Java/1.6.0_16' HEADER: host 'host:port' HEADER: accept 'text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2' HEADER: connection 'keep-alive' HEADER: content-type 'application/x-www-form-urlencoded' HEADER: content-length '134' PARAMETER INFORMATION PARAM: parameter_name 'parameter_value' -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, July 15, 2011 3:22 PM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.07.2011 18:19, Lataxes, Karl wrote: We do not send cookies. Our clients are not web pages but applications embedded in proprietary hardware, which connect to our network via landline telephone or cell modem and access our servlet via HTTP connection. The servlet responds by sending a message containing several parameters in name-value pair format, including a session id that appears as: session-id= unique_client_identifier-current_time_in_milliseconds. The client will respond to the servlet with a message that contains the same session id name-value pair. After initial connection, all client-server communications will contain this unique session id name-value pair. Apache will forward the requests/responses as expected when a single Tomcat node is running. However, for multiple nodes, the requests are forwarded round robin to all nodes. Our system environment prevents us from using session replication between nodes, so we have to use sticky sessions. I do not believe the problem is with Tomcat, but rather how mod_jk routes the requests. Is there any way to configure mod_jk so that it will recognize the session id name-value pair? I did understand your question, but you still did not give the information hntains the session id. The protocol spoken is HTTP and Apache is an HTTP server. So you need to get used to the appropriate language in order to allow us to understand and give a correct answer. That's why I suggested words as query parameters, path info, request headers etc. If the session id is send by the client as part of the request body, then it will become complex and I currently see no solution without a bit of coding. If the id is in headers or somewhere in the URL, you could likely design a solution using mod_proxy_balancer. Regards, Rainer -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, July 15, 2011 9:44 AM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.07.2011 12:48, Lataxes, Karl wrote: Our servlet assigns a session id to a client when it initially contacts the server. The session id consists of session-id, a unique client identifier, and the current time in milliseconds, which is used as session identification for subsequent requests. There are numerous message exchanges between the servlet and client during a typical session, all of which contain the session id. Once the session has successfully ended, the session id is removed from the servlet. Is there any way we can configure mod_jk to recognize the session id in order to route subsequent messages to the original Tomcat node it initially contacted? How does the client present the session id as part of the requests? Query parameter, path info, request header, cookie, ...? Can you five a complete example? Regards, Rainer My 0.02 € : It looks like Karl has access to the source code of the client side, as well as the servlet's. One thing that might help already a lot, is if the client was adding the session-id to each request, either - by appending it to the request URL, as : http://host:port/servlet_path/servlet/servlet_name/;jsessionid=session-id AND/OR - by adding a specific HTTP header, like : X-SESSION-ID: session-id That is because it is a lot easier, on the server side, to retrieve information from the URL or from a HTTP header, than it is from a request body. And there already exists code in the server to do this. (Talking about the Apache http front-end, mod_rewrite and mod_headers for instance) The servlet could also add the session-id as a HTTP response header, which may be also easier for the client to retrieve (depending on what HTTP library is being used there). I am not really familiar with the way in which mod_jk handles sticky sessions, but I would imagine that a suffix to the request URL, as indicated above, should be usable, no ? (Maybe it also needs to contain an identifier for the specific Tomcat (worker) to which
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 29.07.2011 16:34, Lataxes, Karl wrote: I believe this may what you requested. The parameter information I extracted from the request was contained in the request body, as well as the session ID I mentioned previously. If we need to include additional coding in both our servlet and client software, then it's better we find out now. If you want an HTTP intermediate - like a reverse proxy - to implement stickyness, it needs to extract session id info. Extracting from request bodies is much more complex, than from headers or the request URI. So out of the box most solutions only support the latter (or some cases of it). This is especially true for Apache mod_proxy and mod_jk. Regards, Rainer URL: http://host:port/servlet_path/servlet/servlet_name/ PATH: / HEADER INFORMATION HEADER: user-agent 'Java/1.6.0_16' HEADER: host 'host:port' HEADER: accept 'text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2' HEADER: connection 'keep-alive' HEADER: content-type 'application/x-www-form-urlencoded' HEADER: content-length '134' PARAMETER INFORMATION PARAM: parameter_name 'parameter_value' -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, July 15, 2011 3:22 PM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.07.2011 18:19, Lataxes, Karl wrote: We do not send cookies. Our clients are not web pages but applications embedded in proprietary hardware, which connect to our network via landline telephone or cell modem and access our servlet via HTTP connection. The servlet responds by sending a message containing several parameters in name-value pair format, including a session id that appears as: session-id= unique_client_identifier-current_time_in_milliseconds. The client will respond to the servlet with a message that contains the same session id name-value pair. After initial connection, all client-server communications will contain this unique session id name-value pair. Apache will forward the requests/responses as expected when a single Tomcat node is running. However, for multiple nodes, the requests are forwarded round robin to all nodes. Our system environment prevents us from using session replication between nodes, so we have to use sticky sessions. I do not believe the problem is with Tomcat, but rather how mod_jk routes the requests. Is there any way to configure mod_jk so that it will recognize the session id name-value pair? I did understand your question, but you still did not give the information hntains the session id. The protocol spoken is HTTP and Apache is an HTTP server. So you need to get used to the appropriate language in order to allow us to understand and give a correct answer. That's why I suggested words as query parameters, path info, request headers etc. If the session id is send by the client as part of the request body, then it will become complex and I currently see no solution without a bit of coding. If the id is in headers or somewhere in the URL, you could likely design a solution using mod_proxy_balancer. Regards, Rainer -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, July 15, 2011 9:44 AM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.07.2011 12:48, Lataxes, Karl wrote: Our servlet assigns a session id to a client when it initially contacts the server. The session id consists of session-id, a unique client identifier, and the current time in milliseconds, which is used as session identification for subsequent requests. There are numerous message exchanges between the servlet and client during a typical session, all of which contain the session id. Once the session has successfully ended, the session id is removed from the servlet. Is there any way we can configure mod_jk to recognize the session id in order to route subsequent messages to the original Tomcat node it initially contacted? How does the client present the session id as part of the requests? Query parameter, path info, request header, cookie, ...? Can you five a complete example? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
Our servlet assigns a session id to a client when it initially contacts the server. The session id consists of session-id, a unique client identifier, and the current time in milliseconds, which is used as session identification for subsequent requests. There are numerous message exchanges between the servlet and client during a typical session, all of which contain the session id. Once the session has successfully ended, the session id is removed from the servlet. Is there any way we can configure mod_jk to recognize the session id in order to route subsequent messages to the original Tomcat node it initially contacted? -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, July 13, 2011 3:12 PM To: Tomcat Users List Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 13/07/2011 19:39, Lataxes, Karl wrote: We're not using cookies. Our application is not web based, but accepts HTTP PUTS via client requests that enter our network from external sources. We are not URL encoding, as our clients are not configured to accept it. If we have to include URL encoding, both our client and server applications will have to be modified accordingly, which may be an option. No cookies and no url encoding. OK. So how are requests associated with a session? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.07.2011 12:48, Lataxes, Karl wrote: Our servlet assigns a session id to a client when it initially contacts the server. The session id consists of session-id, a unique client identifier, and the current time in milliseconds, which is used as session identification for subsequent requests. There are numerous message exchanges between the servlet and client during a typical session, all of which contain the session id. Once the session has successfully ended, the session id is removed from the servlet. Is there any way we can configure mod_jk to recognize the session id in order to route subsequent messages to the original Tomcat node it initially contacted? How does the client present the session id as part of the requests? Query parameter, path info, request header, cookie, ...? Can you five a complete example? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
We do not send cookies. Our clients are not web pages but applications embedded in proprietary hardware, which connect to our network via landline telephone or cell modem and access our servlet via HTTP connection. The servlet responds by sending a message containing several parameters in name-value pair format, including a session id that appears as: session-id= unique_client_identifier-current_time_in_milliseconds. The client will respond to the servlet with a message that contains the same session id name-value pair. After initial connection, all client-server communications will contain this unique session id name-value pair. Apache will forward the requests/responses as expected when a single Tomcat node is running. However, for multiple nodes, the requests are forwarded round robin to all nodes. Our system environment prevents us from using session replication between nodes, so we have to use sticky sessions. I do not believe the problem is with Tomcat, but rather how mod_jk routes the requests. Is there any way to configure mod_jk so that it will recognize the session id name-value pair? -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, July 15, 2011 9:44 AM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.07.2011 12:48, Lataxes, Karl wrote: Our servlet assigns a session id to a client when it initially contacts the server. The session id consists of session-id, a unique client identifier, and the current time in milliseconds, which is used as session identification for subsequent requests. There are numerous message exchanges between the servlet and client during a typical session, all of which contain the session id. Once the session has successfully ended, the session id is removed from the servlet. Is there any way we can configure mod_jk to recognize the session id in order to route subsequent messages to the original Tomcat node it initially contacted? How does the client present the session id as part of the requests? Query parameter, path info, request header, cookie, ...? Can you five a complete example? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 15.07.2011 18:19, Lataxes, Karl wrote: We do not send cookies. Our clients are not web pages but applications embedded in proprietary hardware, which connect to our network via landline telephone or cell modem and access our servlet via HTTP connection. The servlet responds by sending a message containing several parameters in name-value pair format, including a session id that appears as: session-id= unique_client_identifier-current_time_in_milliseconds. The client will respond to the servlet with a message that contains the same session id name-value pair. After initial connection, all client-server communications will contain this unique session id name-value pair. Apache will forward the requests/responses as expected when a single Tomcat node is running. However, for multiple nodes, the requests are forwarded round robin to all nodes. Our system environment prevents us from using session replication between nodes, so we have to use sticky sessions. I do not believe the problem is with Tomcat, but rather how mod_jk routes the requests. Is there any way to configure mod_jk so that it will recognize the session id name-value pair? I did understand your question, but you still did not give the information hntains the session id. The protocol spoken is HTTP and Apache is an HTTP server. So you need to get used to the appropriate language in order to allow us to understand and give a correct answer. That's why I suggested words as query parameters, path info, request headers etc. If the session id is send by the client as part of the request body, then it will become complex and I currently see no solution without a bit of coding. If the id is in headers or somewhere in the URL, you could likely design a solution using mod_proxy_balancer. Regards, Rainer -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Friday, July 15, 2011 9:44 AM To: users@tomcat.apache.org Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 15.07.2011 12:48, Lataxes, Karl wrote: Our servlet assigns a session id to a client when it initially contacts the server. The session id consists of session-id, a unique client identifier, and the current time in milliseconds, which is used as session identification for subsequent requests. There are numerous message exchanges between the servlet and client during a typical session, all of which contain the session id. Once the session has successfully ended, the session id is removed from the servlet. Is there any way we can configure mod_jk to recognize the session id in order to route subsequent messages to the original Tomcat node it initially contacted? How does the client present the session id as part of the requests? Query parameter, path info, request header, cookie, ...? Can you five a complete example? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 13/07/2011 20:17, Christopher Schultz wrote: Mark, On 7/13/2011 3:12 PM, Mark Thomas wrote: On 13/07/2011 19:39, Lataxes, Karl wrote: We're not using cookies. Our application is not web based, but accepts HTTP PUTS via client requests that enter our network from external sources. We are not URL encoding, as our clients are not configured to accept it. If we have to include URL encoding, both our client and server applications will have to be modified accordingly, which may be an option. No cookies and no url encoding. OK. So how are requests associated with a session? +1 +1 Sounds like the OP is Doing It Wrong. You missed out the capitals (corrected above). ;) p signature.asc Description: OpenPGP digital signature
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 14/07/2011 10:25, Pid wrote: On 13/07/2011 20:17, Christopher Schultz wrote: Mark, On 7/13/2011 3:12 PM, Mark Thomas wrote: On 13/07/2011 19:39, Lataxes, Karl wrote: We're not using cookies. Our application is not web based, but accepts HTTP PUTS via client requests that enter our network from external sources. We are not URL encoding, as our clients are not configured to accept it. If we have to include URL encoding, both our client and server applications will have to be modified accordingly, which may be an option. No cookies and no url encoding. OK. So how are requests associated with a session? +1 +1 Sounds like the OP is Doing It Wrong. You missed out the capitals (corrected above). ;) http://www.cafepress.com/cp/customize/product2.aspx?number=556022568 p signature.asc Description: OpenPGP digital signature
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 7/14/2011 5:45 AM, Pid wrote: http://www.cafepress.com/cp/customize/product2.aspx?number=556022568 $21? boo... - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4e+P0ACgkQ9CaO5/Lv0PDZ7gCgpaSQIg653F1mc4voYmpDT8Rs cKcAoIB9PsUouVmvf4/t7TvYyoo+6aLf =RXR3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 14/07/2011 15:11, Christopher Schultz wrote: Pid, On 7/14/2011 5:45 AM, Pid wrote: http://www.cafepress.com/cp/customize/product2.aspx?number=556022568 $21? boo... I couldn't change the price... s signature.asc Description: OpenPGP digital signature
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 13/07/2011 14:37, Lataxes, Karl wrote: We are attempting to run identical servlets under several Tomcat 7.0.8 nodes behind a load balancer (Apache 2.0.54 using mod_jk), but we have been unable to get sticky sessions to work. Initial requests are forwarded to a node as expected, but subsequent requests from the same client are being forwarded to the second node ala round robin, which triggers session not found logic in our application and causes the connection to terminate. Due to environment limitations, we cannot employ session persistence to our Tomcat instances and must make use of sticky sessions. My Tomcat instances have been properly configured (HTTP connector commented out, AJP 1.3 connected uncommented, jvmRoute attribute in each instance set to the workers listed in workers.properties file). Here are the mod_jk entries in my httpd.conf file: LoadModule jk_module /path_to/apache/modules/mod_jk.so JkWorkersFile /path_to/apache/conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel debug JkMount /* loadbalancer Here are the entries in my workers.property file: worker.list=loadbalancer worker.tomcat7A.type=ajp13 worker.tomcat7A.host=host_name worker.tomcat7A.port=4911 worker.tomcat7A.lbfactor=1 worker.tomcat7C.type=ajp13 worker.tomcat7C.host=host_name worker.tomcat7C.port=4931 worker.tomcat7C.lbfactor=1 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=tomcat7A,tomcat7C worker.loadbalancer.sticky_session=1 worker.jkstatus.type=status What am I doing wrong? Are they always forwarded to the wrong node, or do some succeed? If you monitor the response headers (look for Set-Cookie: NN.tomcat7X) is a new session sent each time? Is the client sending the Cookie: header with the second request? Are you URL encoding each link in the page? p signature.asc Description: OpenPGP digital signature
RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
We're not using cookies. Our application is not web based, but accepts HTTP PUTS via client requests that enter our network from external sources. We are not URL encoding, as our clients are not configured to accept it. If we have to include URL encoding, both our client and server applications will have to be modified accordingly, which may be an option. -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Wednesday, July 13, 2011 11:23 AM To: Tomcat Users List Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 On 13/07/2011 14:37, Lataxes, Karl wrote: We are attempting to run identical servlets under several Tomcat 7.0.8 nodes behind a load balancer (Apache 2.0.54 using mod_jk), but we have been unable to get sticky sessions to work. Initial requests are forwarded to a node as expected, but subsequent requests from the same client are being forwarded to the second node ala round robin, which triggers session not found logic in our application and causes the connection to terminate. Due to environment limitations, we cannot employ session persistence to our Tomcat instances and must make use of sticky sessions. My Tomcat instances have been properly configured (HTTP connector commented out, AJP 1.3 connected uncommented, jvmRoute attribute in each instance set to the workers listed in workers.properties file). Here are the mod_jk entries in my httpd.conf file: LoadModule jk_module /path_to/apache/modules/mod_jk.so JkWorkersFile /path_to/apache/conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel debug JkMount /* loadbalancer Here are the entries in my workers.property file: worker.list=loadbalancer worker.tomcat7A.type=ajp13 worker.tomcat7A.host=host_name worker.tomcat7A.port=4911 worker.tomcat7A.lbfactor=1 worker.tomcat7C.type=ajp13 worker.tomcat7C.host=host_name worker.tomcat7C.port=4931 worker.tomcat7C.lbfactor=1 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=tomcat7A,tomcat7C worker.loadbalancer.sticky_session=1 worker.jkstatus.type=status What am I doing wrong? Are they always forwarded to the wrong node, or do some succeed? If you monitor the response headers (look for Set-Cookie: NN.tomcat7X) is a new session sent each time? Is the client sending the Cookie: header with the second request? Are you URL encoding each link in the page? p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
On 13/07/2011 19:39, Lataxes, Karl wrote: We're not using cookies. Our application is not web based, but accepts HTTP PUTS via client requests that enter our network from external sources. We are not URL encoding, as our clients are not configured to accept it. If we have to include URL encoding, both our client and server applications will have to be modified accordingly, which may be an option. No cookies and no url encoding. OK. So how are requests associated with a session? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 7/13/2011 3:12 PM, Mark Thomas wrote: On 13/07/2011 19:39, Lataxes, Karl wrote: We're not using cookies. Our application is not web based, but accepts HTTP PUTS via client requests that enter our network from external sources. We are not URL encoding, as our clients are not configured to accept it. If we have to include URL encoding, both our client and server applications will have to be modified accordingly, which may be an option. No cookies and no url encoding. OK. So how are requests associated with a session? +1 Sounds like the OP is doing it wrong. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4d70MACgkQ9CaO5/Lv0PCx0QCcClUefau5IpF9bX796LfVah9U oZoAnjW40iu8UL0BzxtWVf8D/G5di5N1 =mMRQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
