tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lataxes, Karl" <Karl.Lataxes...@nielsen.com>
Subject RE: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8
Date Fri, 05 Aug 2011 11:49:53 GMT
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

Mime
View raw message