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
signature.asc
Description: OpenPGP digital signature
