Hi,
I'm using the domain property in the same situation as the one
discussed in this thread. Any reason why I shouldn't use the domain
property and rely on the worker names instead?
Thanks in advance,
-- Edgar Alves
Rainer Jung wrote:
That should not work!
The correct way to configure
Edgar Alves wrote:
Hi,
I'm using the domain property in the same situation as the one
discussed in this thread. Any reason why I shouldn't use the domain
property and rely on the worker names instead?
Domain is supposed to be used with multiple workers sharing the
same jvmRoute having
Hi Mladen,
I've used the domain property because it seemed the more general
approach (i.e., supports clusters but can be used with a single worker).
What this thread got me curious about is if using the domain property in
this fashion is officially supported, or on the other hand if it can
only
OK, thanks Mladen: I have to correct myself.
1) Traditional use
Until mod_jk 1.2.6 there was no concept of domains. You had to specify the
worker name to be exactly the same as the jvmRoute to make sticky sessions
work. This way of configuring stickyness is wel known to mod_jk users.
2) I
Hi -
I'm unable to get mod_jk load balancing working. The usual mod_jk setup
works just fine, but using a load balancing worker however, is not.
[Oddly, my webserver crashed during testing of this, but that could very
well be unrelated]
The problem is with user sessions. The instances
Try adding these two lines to worker.properties:
worker.bl_worker_dev.domain=dev_alexis
worker.bl_worker_noah.domain=noah_alexis
-- Edgar Alves
Mott Leroy wrote:
Hi -
I'm unable to get mod_jk load balancing working. The usual mod_jk
setup works just fine, but using a load balancing worker
Beautiful - worked like a charm. That might take the cake as far as
longest question to quickest, shortest answer goes. ha. Thanks a bunch.
I might have to gripe about doucmentation in a second (nother thread)..
Noah
Edgar Alves wrote:
Try adding these two lines to worker.properties:
That should not work!
The correct way to configure session stickyness is to use jvmRoute (which
you already did) and then giving the workers the same names as the
jvmRoute. That is instead of bl_worker_dev use dev_alexis and instead
of bl_worker_noah use noah_alexis as the worker names.
You
Ok - noted. I changed it. It works without the domain as you noted. Thanks.
Rainer Jung wrote:
That should not work!
The correct way to configure session stickyness is to use jvmRoute (which
you already did) and then giving the workers the same names as the
jvmRoute. That is instead of
Hey Michael,
I look inside the tomcat source and find that we don't set the cookie
hostname attribute.
That means that the calling client/browser must made the hostname
handling. I also
thing the redirect way is currently right direction.
Peter
Paul Singleton schrieb:
Michael Teter wrote:
I guess I was hoping there was some server-level redirect.
I'm not sure how I would put the meta redirect in all my pages. My
app is a complicated mess (my fault - my lack of skill).
The issue is that my users are clicking a PayPal Subscribe button,
which sends them off to PayPal. Part of the
PROTECTED]
Sent: 16 August 2005 13:17
To: Tomcat Users List
Subject: Re: session problems: www.blahblah.com versus blahblah.com
I guess I was hoping there was some server-level redirect.
I'm not sure how I would put the meta redirect in all my pages. My
app is a complicated mess (my fault - my
I would imagine the other way to do this is to implement a filter
looking for people trying to reach blahblah.com and returning a 302
redirect to www.blahblah.com. That would give them all the proper
cookie from the start and could be implemented accross all your webapp
resources at once.
Ignore my last mail, this way is better.
Ta
Matt
-Original Message-
From: David Smith [mailto:[EMAIL PROTECTED]
Sent: 16 August 2005 13:42
To: Tomcat Users List
Subject: Re: session problems: www.blahblah.com versus blahblah.com
I would imagine the other way to do this is to implement
Howdy.
I'm having some problems with sessions.
If my users come to blahblah.com, then go away, then return, they
get a new session id (for www.blahblah.com).
But if they come to www.blahblah.com, leave, and return (via link from
external site), they keep the same session.
I finally discovered
Hmm,
I thing a host alias at for your tomcat configuration was helpfull :-)
Host name=blahblah.com
Aliaswww.blahblah.com/Alias
/Host
Peter
Michael Teter schrieb:
Howdy.
I'm having some problems with sessions.
If my users come to blahblah.com, then go away, then return, they
get a
I tried that, but it's not working.
I tried:
Host name=blahblah.com
Aliaswww.blahblah.com/Alias
/Host
and I also tried:
Host name=www.blahblah.com
Aliasblahblah.com/Alias
/Host
Both ways, I still got a session cookie associated with the name the
user entered as the address. If the user
to www.blahblah.com so that whenever they are interacting with the webapp.
Ta
Matt
-Original Message-
From: Michael Teter [mailto:[EMAIL PROTECTED]
Sent: 15 August 2005 21:05
To: Tomcat Users List
Cc: [EMAIL PROTECTED]
Subject: Re: session problems: www.blahblah.com versus blahblah.com
I
they are interacting with
the webapp.
Ta
Matt
-Original Message-
From: Michael Teter [mailto:[EMAIL PROTECTED]
Sent: 15 August 2005 21:05
To: Tomcat Users List
Cc: [EMAIL PROTECTED]
Subject: Re: session problems: www.blahblah.com versus blahblah.com
I tried that, but it's
Michael Teter wrote:
If my users come to blahblah.com, then go away, then return, they
get a new session id (for www.blahblah.com).
But if they come to www.blahblah.com, leave, and return (via link from
external site), they keep the same session.
I finally discovered that the browser (Firefox
To: Tomcat Users List
Subject: Re: Session problems with cluster
Matt,
No other nodes are up, so there's nothing to serialize. I could imagine that the
session of the old context could be serialized to the new context in order to preserve
state, although I
hope this isn't done.
Thanks,
Matthew
Dale
Users List
Subject: Re: Session problems with cluster
Filip,
I discovered this when I had one node in the cluster. With no other
nodes
to receive a session from, I expected the session to be
empty. Is the session intended to survive reloads in this case? I
would
guess not, just because
feel free to send it directly to me, fhanik at apache dot org
Filip
- Original Message -
From: Brantley Hobbs [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 7:23 AM
Subject: RE: Session problems with cluster
Matt,
We've seen a similar
[mailto:[EMAIL PROTECTED]
Sent: Monday, October 18, 2004 6:23 PM
To: Tomcat Users List
Subject: Re: Session problems with cluster
Filip,
I discovered this when I had one node in the cluster. With no other
nodes
to receive a session from, I expected the session to be
empty
bug report with all
info, OS JDK version, etc
Filip
-Original Message-
From: Matthew Stone [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 11:15 AM
To: Tomcat Users List
Subject: Re: Session problems with cluster
Hmm, that's a bit concerning.
Brantley Hobbs wrote:
Matt
sure you populate your bug report with all
info, OS JDK version, etc
Filip
-Original Message-
From: Matthew Stone [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 11:15 AM
To: Tomcat Users List
Subject: Re: Session problems with cluster
Hmm, that's a bit concerning
-Original Message-
From: Matthew Stone [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 3:39 PM
To: Tomcat Users List
Subject: Re: Session problems with cluster
Filip Hanik (lists) wrote:
What's concerning?
the session actually randomly loses data sometimes
To set
---
end index.jsp
Thank you
Ivan
-Original Message-
From: Filip Hanik (lists) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 5:39 PM
To: Tomcat Users List
Subject: RE: Session problems with cluster
Hmm, that's a bit concerning.
I found your lack of faith
calls setAttribute or removeAttribute
Filip
-Original Message-
From: Ivan Vasquez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 5:13 PM
To: Tomcat Users List
Subject: RE: Session problems with cluster
Filip, here is a concrete case that you may find interesting. It's a
very
PM
To: Tomcat Users List
Cc: [EMAIL PROTECTED]
Subject: RE: Session problems with cluster
hi Ivan,
it took me a while to figure out what was going on.
its a coding/configuration problem on your part. Your code would have worked
if you had configured SimpleTcpReplicationManager with
useDirtyFlag
in a fix for this into Tomcat 5.5 right away, and 5.0.x when time
frees up.
Filip
-Original Message-
From: Matthew Stone [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 3:39 PM
To: Tomcat Users List
Subject: Re: Session problems with cluster
Filip Hanik (lists) wrote
When I restart the context of a clustered node the session doesnt seem
to be cleared. After I restart the context, I'm expecting a null from
the following line but I'm getting a ClassCastException because of the
different class loaders that loaded MyObject.
MyObject obj = (MyObject)
, 2004 2:09 PM
Subject: Session problems with cluster
When I restart the context of a clustered node the session doesnt seem
to be cleared. After I restart the context, I'm expecting a null from
the following line but I'm getting a ClassCastException because of the
different class loaders that loaded
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 18, 2004 2:09 PM
Subject: Session problems with cluster
When I restart the context of a clustered node the session doesnt seem
to be cleared. After I restart the context, I'm expecting a null from
the following line but I'm getting
To: [EMAIL PROTECTED]
Subject: Session problems with cluster
When I restart the context of a clustered node the session doesnt seem
to be cleared. After I restart the context, I'm expecting a null from
the following line but I'm getting a ClassCastException because of the
different class loaders
the sessions will get serialised then
reloaded so I would expect this behaviour. You would have to set the cluster to dump
sessions on a reload.
-Original Message-
From: Matthew Stone [mailto:[EMAIL PROTECTED]
Sent: 18 October 2004 20:09
To: [EMAIL PROTECTED]
Subject: Session problems
Iam using the Tomcat 4.1.24 clustering with apache 2.0.43. everything seems to work
fine, many many thanks to Filip for the fine work. But I have a problem when I try to
save a session notifier called 'SessionTimeoutNotifier' which extends
'HttpSessionBindingListener' in the session. First it
is this class in all your webapps?
can you send me a test case webapp and I will try it out
-Original Message-
From: Mandeep Jossan [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 11:01 AM
To: [EMAIL PROTECTED]
Subject: Session Problems in Tomcat Clustering
Iam using
://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q300895
Regards
Alessio
[EMAIL PROTECTED]
-Messaggio originale-
Da: Jeff Larsen [mailto:[EMAIL PROTECTED]]
Inviato: mercoledì 12 giugno 2002 18.33
A: tomcat-user
Oggetto: Client session problems when MSIE is run within Outlook
I
I don't have MS Outlook myself, so I can't do any testing on this. But
I have a customer who has been running a browser session from within
Outlook.
Some of my pages have javascript links that open a new browser window
to view a page. When she accesses one of these popups from within
Outlook,
-
From: Jeff Larsen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 12:33 PM
To: tomcat-user
Subject: Client session problems when MSIE is run within Outlook
I don't have MS Outlook myself, so I can't do any testing on this. But
I have a customer who has been running a browser session
Hi,
Byju P.Nair wrote:
Tomcat is creating 2 different sessions when another browser
window is opened from a main window.
Try to send the Request via the target-Attribute (A or FORM) to the new
Window, you can open a customized window with onclick.
Example:
a onClick=getArticleWindow();
- Original Message -
From: Byju P.Nair [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, October 04, 2001 2:33 PM
Subject: Session Problems
Hi,
Tomcat is creating 2 different sessions when another browser
window is opened from a main window. For instance, i have
Yes Simon, you are right. Since the browser has cookie enabled,
the above statement doesn't encode the sessionID into URL :-(
Hi,
Tomcat is creating 2 different sessions when another browser
window is opened from a main window. For instance, i have an
application, in which the
Hi,
Byju P.Nair wrote:
Yes Simon, you are right. Since the browser has cookie enabled,
the above statement doesn't encode the sessionID into URL :-(
See server.xml:
!-- Session interceptor will extract the session id from cookies and
deal with URL rewriting ( by fixing the URL ). If
I did exactly as mentioned below, but it is helping the issue. Having
suppressed the cookie usage, do i have to explicitly use URL
rewriting by using response.encodeURL(...) to encode the
sessionID?
See server.xml:
!-- Session interceptor will extract the session id from cookies and
Byju P.Nair wrote:
Having
suppressed the cookie usage, do i have to explicitly use URL
rewriting by using response.encodeURL(...) to encode the
sessionID?
Yes, shure.
Marc
See server.xml:
!-- Session interceptor will extract the session id from cookies and
deal with URL rewriting
request.getSession().putValue(name1,value1);
btw, the putValue()-method is deprecated since servlet2.2
you should use setAttribute(String key, Object value) instead.
have a look at the javadoc.
marco
Hi,
Tomcat is creating 2 different sessions when another browser
window is opened from a main window. For instance, i have an
application, in which the first jsp page sends a request to a servlet
which inturn places a session object using
request.getSession().putValue(name1,value1);
The
Hi Byju,
i had played with this in Tomcat and got similar results.
i opened multiple browser windows without acknowledging the session.
after 4 windows , the browser started to send the cookie info to the
server( i cant explain this behavior. )
what i suggest is get the client to acknowledge
I am having problems with the following code (this is just a simplified example):
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class TestSession extends HttpServlet {
public void doGet( HttpServletRequest req, HttpServletResponse res)
I've tried using request scope instaed, but the
request.getAttribute("test") produces a null bean object - why?
bean objects are not in the HttpServletRequest. They are simply
shorthand for instantiation of a Object... i.e. instead of:
SessionDoohicky doohicky = new SessionDoohicky(param1);
52 matches
Mail list logo
