 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
6 messages in org.apache.tomcat.usersavailability expectations with apache...| From | Sent On | Attachments |
|---|---|---|
| Nikita | Aug 19, 2004 12:24 pm | |
| Shapira, Yoav | Aug 19, 2004 12:26 pm | |
| Nikita | Aug 19, 2004 12:34 pm | |
| Shapira, Yoav | Aug 19, 2004 12:44 pm | |
| Filip Hanik (lists) | Aug 19, 2004 1:33 pm | |
| Nikita | Aug 19, 2004 7:30 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | availability expectations with apache/mod_jk/tomcat? [Was Re: adding <distributable/> garbles sesion id string] | Actions |
|---|---|---|
| From: | Nikita (nik...@workoutiq.com) | |
| Date: | Aug 19, 2004 7:30:36 pm | |
| List: | org.apache.tomcat.users | |
Yoav,
yes, you were correct. I looked over the servlet spec and it indeed says nothing about the format of session id's. I did initially have this question because clustering - or specifically session replication - weren't working properly for me. I think I resolved part of that problem, when i realized that the clocks of the two nodes in my cluster were 3 hours apart. I'm new to clustering, but I'm guessing session replication logic involves timestamp comparisons. But I'm not out of the woods yet...
I think I need to set my expectations of apache/mod_jk/tomcat realistically, so I'm hoping someone will be kind enough to clarify the following: Setup: 2 clustered nodes running jboss4/tomcat5, one node running apache/mod_jk with sticky round-robin. a distributable web app is farmed out to the cluster. Consider the following scenario: -User accesses webapp for the first time and is directed to node A -session is established in A, and immediately replicated to B -successive requests (let's say refresh) for that session keep going to A -A goes down, next request goes to B -A is brought back up, a bit later B goes down -next incoming request goes back to A -repeat the above steps and so on...
I've done the above quite slowly, terminating jboss server instances, waiting for them to shut down, and then playing "user" role and hitting refresh. In that scenario, clustering worked perfectly! However, if user keeps hitting refresh about once a second, while the target node is being brought down, the user eventually sees a 404. A few clicks later, the user does get a valid response, served by node B (ie load balancing worked), but with a *new* session (i guess session replication didn't work).
Am I expecting too much from this setup? In practice, is there now way to ensure that a user will never see a 404 or lose a session as long as load balancer and at least one cluster node are alive? Is there a minimum time between user requests assumed? Or should one be able to blast a cluster using JMeter with low (say 300 millis) delay between successive requests, alternatively bring down nodes and still have the sessions preserved?
In my current jboss/tomcat config, session replication is set to "instant". Are there any setting in mod_jk.conf that can be used to make sure that a cluster node is alive and well *immediately* before sending a request to it?
thanks a lot -nikita
Shapira, Yoav wrote:
Hi What you think is one matter, and servlet specification compliance is another ;) Is there something in the Servlet Spec that's being violated, or is the clustering behavior not working for you? In other words, are you seeing a bug or just unhappy that the session ID is not human-readable?
When you set distributable, it's a big deal. The clustering code kicks in and among other things it can modify session IDs to prepare for replication and state synchronization among cluster nodes. So if you change between distributable and not on the fly, you can expect this session management behavior change.
Yoav Shapira Millennium Research Informatics
-----Original Message----- From: Nikita [mailto:nik...@workoutiq.com] Sent: Thursday, August 19, 2004 3:35 PM To: Tomcat Users List Subject: Re: adding <distributable/> garbles sesion id string
i don't think this behavior is correct. for example, i deploy an app without <dist.> and get a session id. then, on the fly, i add this tag to web.xml (i originally deployed an exploded war), and if the web page is then refreshed, i get this new, garbled string. but, if i use stand-alone tomcat, i *never* get a session stings with alternating
case
and '*'. seems to me like there's something wrong with character encoding...
-nikita
Shapira, Yoav wrote:
Hi, As long as the session ID is a valid string, it's not a bug. There's
no
requirement that the session ID be human-readable right? ;)
Yoav Shapira Millennium Research Informatics
that
prints out session id string. The problem is that if i add "distributable" to web.xml, this string becomes garbled (both in the browser and in console output):
without <distributable/>: "session id: 5129D795478E6529E233E1909EF85CB7.node1"
with <distributable/>: "session id: gDMzbOR3bJ8SNSmC3dDMWQ**.node1"
I deployed the same war as in stand-alone tomcat 5.0.27 under both xp and linux and saw no problems. So seems like this is a jboss issue. however, jboss 4.0rc1 uses tomcat 5.0.27-dev, and i'm wondering if upgrading to 5.0.27 would help at all.
Could this be related to the fact that i'm using mod_jk 1.2.6? If so, should i post this in clustering forum? I'd really appreciate any
insight
my setup: jboss 4.0 rc1, clustered with mod_jk 1.2.6, tomcat 5.0.27-dev
integrated
os: jds 1 linux (based on suse enterprise desktop 1.0), also tried
win
xp
kernel: 2.4.21-189-default java version "1.4.2_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)
thanks,
-nikita
----------test.jsp---------------- <%@ page contentType="text/html; charset=iso-8859-1" language="java" import="java.sql.*" errorPage="" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html> <head> <meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<title>Untitled Document</title> </head> <body> session id: <%=session.getId()%> <P> last accessed: <%=new java.util.Date()%> </body> </html> -------------------end test.jsp----------------------
-----------------web.xml-------------------------------
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <display-name>Test Application</display-name> <description> Sample session jsp </description> </web-app> -------------------end web.xml-------------------------------
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended
recipient, please immediately delete this e-mail from your computer
system
and notify the sender. Thank you.
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged. This e-mail is intended only for the individual(s) to whom it
is addressed, and may not be saved, copied, printed, disclosed or used by anyone
else. If you are not the(an) intended recipient, please immediately delete this
e-mail from your computer system and notify the sender. Thank you.