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
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
-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
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
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:
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
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
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
-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
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
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
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
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
-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
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
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
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
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
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.
-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
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
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.
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
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
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
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
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
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
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
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
-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 -
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
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
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
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
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
-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
37 matches
Mail list logo
