Hi chris, I think your suggestion about multiple windows was a good guess. It would account for all the behavior, except that I'm quite sure I wasn't using a different window. I mean, the web app responds with a page that refreshes itself after a set, short amount of time, presenting a progress bar each time, but also presenting a form with cancel/switch-to-batch-mode buttons. I really don't think I could have started the app & refreshing in one window and then selected some other window (from some previous session) to choose cancel. I run the app, and as soon as I can I click cancel.
Regarding your other suggestions: No, no HTTPS-to-HTTP stuff; all requests are going to a port dedicated to Tomcat (8088). And the Firefox cookies options form is set so that cookies are kept "until they expire" which I believe is the default (the other options being "until I close Firefox" and "ask me every time"). Any further thoughts always appreciated, -M > -----Original Message----- > From: Christopher Schultz [mailto:[EMAIL PROTECTED] > Sent: Monday, October 23, 2006 3:10 PM > To: Tomcat Users List > Subject: Re: a discrepancy in webapp behavior in two environments > > Mark, > > > My web app had been working just fine in the TEST environment, > > PROVIDED I included the initial session ID as a param to > the URL used > > on the cancel/switch-to-batch form. But starting just this > morning, it > > was failing again, DESPITE my using the session ID as a > param to the > > URL on the cancel form. It appeared that a DIFFERENT session with > > different session ID was getting created when I hit cancel. > > > > [After a request is received from the cancel form, my servlet uses > > getSession(false) to get the session, so if there were no valid > > session I should get null, but I don't get null..., so > there must be a > > valid session retrieved, yet with a different session ID!] > > Is it possible that you have multiple windows (or tabs) open > in your browser with competing sessions lurking in the URLs > (rather than using a cookie)? > > Are you using cookies or URL-rewriting? > > It might help to purge Tomcat's stored sessions while you > have Tomcat stopped, in case there are broken sessions in > your test environment that won't go away for whatever reason > (maybe a really long session timeout?). > > Also, you could write an HttpSessionListener that does > something like this in the sessionCreated method: > > System.err.println("Creating a new session. id=" > + se.getSession().getId()); (new > Throwable()).printStackTrace(); > > This will dump the newly created session id and stack trace > into stderr, and so you can see exactly where sessions are > being created. It's possible that you have a getSession(true) > somewhere in your code, or that you have a couple of URLs > that are missing URL re-writing code around them. > > > I don't understand how this could have been happening. > > > > MOREOVER, cancelling my web-app in the TEST environment works fine > > when > > IE7 is used as browser on the client side; it's only w. > Firefox that > > I'm getting this puzzling HttpSession object behavior. Yet both > > firefox and > > IE7 have their cookies option set to allow-all. > > Okay, so cookies shouldn't be the problem. Hmm... > > > The thing was working just yesterday and for days prior to that! > > Are you doing funny things with port numbers? HTTPS-to-HTTP? > Or vice versa? Or is everything happening on port 80? > > > And now to add one extra piece of bizarreness to this whole > thing: I > > followed Jon Wingfield's suggestion of installing > LiveHTTPHeaders to > > Firefox, to watch what was being sent from the browser, and when I > > restarted Firefox and attempted to reproduce the problem, it was > > working again! I was able to cancel and switch-to-batch > just as before... > > Weird. Are your cookies set to expire at the end of the > browser session or anything like that? > > -chris > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
