You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Lataxes, Karl" <Ka...@nielsen.com> on 2011/07/13 15:37:19 UTC

Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

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?


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Rainer Jung <ra...@kippdata.de>.
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.jung@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.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by André Warnier <aw...@ice-sa.com>.
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 transform it into some 
form that your client appliance can understand.
(But them again comes the same question : if the client code can be modified to recognise 
a custom HTTP header with the session-id, then why can it not be modified to decode a 
standard Set-Cookie header ?)

So maybe finally, the solution to your problem could consist in implementing some level of 
Cookie support in your appliances.  Cookies are just quite simple HTTP headers, with a 
string value easy to encode/decode.  You do not necessarily have to implement the full 
arcana of the Cookie specifications for your purposes, just what is strictly necessary for 
mod_jk and Tomcat to handle sessions and load-balancing with it.

The result of such a modification of the appliances, would be to make them more similar to 
browsers in terms of handling cookies.  This in turn would help at the server side, in 
handling their requests in a more HTTP-compliant way, which would probably bring 
advantages in the long term in terms of application development.

And if for some reason you cannot do that, then there are standard mechanisms in Apache 
httpd which can do things like this (like mod_headers and mod_rewrite).  But their fields 
of action also tend to be on HTTP headers and cookies, rather than request/response 
bodies.  And the moment in the request/response cycle where they can intervene, may not 
necessarily fit very well with the needs of mod_jk for load-balancing or sticky sessions.

There are also non-standard mechanisms which can achieve what you want, for example using 
mod_perl on the front-end Apache.  But there we are entering the realm of bespoke programming.

Hope this helps.






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.
> 
> 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:chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Pid <pi...@pidster.com>.
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.jung@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.jung@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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.jung@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.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Rainer Jung <ra...@kippdata.de>.
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.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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:aw@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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:aw@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.jung@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.jung@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 the call should be routed)


Now just by curiosity : are we talking about audience metrics here ?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by André Warnier <aw...@ice-sa.com>.
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.jung@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.jung@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 
the call should be routed)


Now just by curiosity : are we talking about audience metrics here ?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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.jung@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.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Rainer Jung <ra...@kippdata.de>.
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.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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:markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Pid <pi...@pidster.com>.
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


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Pid <pi...@pidster.com>.
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



Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Pid <pi...@pidster.com>.
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


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by "Lataxes, Karl" <Ka...@nielsen.com>.
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:pid@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:
NNNNNN.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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8

Posted by Pid <pi...@pidster.com>.
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:
NNNNNN.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