Alright, now I'm really baffled. Below, I've copied my original post about the discrepancy that's been puzzling me. Please consult that for a description of the web app and the TEST environment.
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!] 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. The thing was working just yesterday and for days prior to that! One thing I did this morning involving Firefox is that I ran firefox.exe -silent -nosplash -setDefaultBrowser on the Windows run command line, to have Firefox set itself back as default browser (because when I downloaded IE7 over the weekend, it made itself the default browser, grrrr...). But I'm not suggesting there's any reason to think that action was relevant... I just don't know... 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... Jon, I don't think you meant to suggest that the install of LiveHTTPHeaders would fix my problem in and of itself! :) But more seriously, since I have no idea what caused the brief recurrence of my problem (DESPITE including session ID as param to URL) I don't have a lot of confidence this strange HttpSession behavior won't recur... Does anyone have any further ideas? I'd really appreciate any help. Mark <copy of description from first post> I have a servlet-based web app that behaves differently with its handling of HttpSession objects in two different environments. Here are the two environments: DEVELOPMENT ----------- Firefox client on a linux box pointing at an instance of tomcat 5.5.17 (JVM from 1.5.0_07-b03) running on the same box (run from within my IDE, IntelliJ IDEA, for debugging). TEST ---- Firefox client on Windows XP pointing at an instance of tomcat (same version; JVM from 1.5.0_06-b05, mixed mode) running on a Sun machine (Solaris 9). There's a discrepancy in the webapp behavior in these two environments that I'd like to understand better, but first before describing the discrepancy let me describe the web app a bit... There is a main servlet that generates refreshes till a search is completed. The search is invoked on a separate thread with the very first request. When the search is complete, the response page displays all the search results. Until the search is complete, the page presented in the browser with each refresh just shows whatever data has been acquired so far by the search. Also with each refresh page, the user is presented with a form that allows one to cancel the search or to switch the search to batch-mode. When either cancel or switch-to-batch are clicked on this form, the same servlet as the initial request is used. Until recently, I had simply put the URL of the servlet in quotes as value of the action element of the form. And all went well on both DEVELOPMENT and TEST environments. But at some point recently (a month, two months... unfortunately I can't pin it down at all), a discrepency appeared between the two environments: It started to happen in the TEST environment--not in the DEVELOPMENT environment--that when I select either cancel or switch-to-batch, the original HttpSession object would be lost (and several attributes of that session object are necessary for proper cancelling or switching to batch-mode). If the request comes from a refresh, however, and the user hasn't selected cancel or switch-to-batch, the original HttpSession object is retained and its attributes persist (I know because otherwise the app wouldn't complete its search successfully, which it does). I've gotten around this issue by running code in both environments that attaches a jsessionid param value to the URL for the cancel or switch form on the refresh pages, using the sessionId obtained from the initial HttpSession object. With that addition, the cancel and switch form works because the original HttpSession object is retained. This is fine, but what I don't understand is why specifying a jsessionid param value is necessary in the TEST environment and not necessary in the DEVELOPMENT environment. I also don't understand why the change occurred on the TEST environment at some point in time, when the old code (without use of jsessionid param value) worked there before. The config files for Tomcat are identical between the two environments; the Firefox settings (e.g. cookie options) are identical in both environments. I'd like to understand this difference in behavior. Can anyone help? </copy of description from first post> > -----Original Message----- > From: Jon Wingfield [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 19, 2006 9:35 AM > To: Tomcat Users List > Subject: Re: a discrepancy in webapp behavior in two environments > > Mark, > > Take a look at the LiveHttpHeaders plug-in for Firefox. It > may help you debug this on the client side. > Temporarily enabling the RequestDumperValve on the server > side will enable you to see if cookies are reaching the server. > > HTH, > > Jon > > Aronszajn, Mark wrote: > > Thanks for the information. I had checked Firefox in each > environment (I think I mentioned this) to be sure that > cookies were allowed, but I didn't realize that a firewall > might block cookies. > > > > I really appreciate the help. > > > > Mark > > > > > > -----Original Message----- > > From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] > > Sent: Wed 10/18/2006 5:15 PM > > To: Tomcat Users List > > Subject: RE: a discrepancy in webapp behavior in two environments > > > > > > > > > > -----Original Message----- > > From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] > > Sent: Wed 10/18/2006 5:15 PM > > To: Tomcat Users List > > Subject: RE: a discrepancy in webapp behavior in two environments > > > >> From: Aronszajn, Mark [mailto:[EMAIL PROTECTED] > >> Subject: RE: a discrepancy in webapp behavior in two environments > >> > >> Could you explain how the configuration of a firewall > would have such > >> effect on whether the original HttpSession object gets retained? > > > > If you're not appending jsessionid ro the URL, you must be using > > cookies to allow the server to identify the client. Some smart (?) > > firewalls (or proxy servers) can be configured to drop > cookies. For > > an example, see this thread: > > http://marc.theaimsgroup.com/?l=tomcat-user&m=107017907404496&w=2 > > > > Note that it could be a firewall installed on your Windows box, not > > just an external one. > > > > - Chuck > > > > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > > PROPRIETARY MATERIAL and is thus for use only by the intended > > recipient. If you received this in error, please contact the sender > > and delete the e-mail and its attachments from all computers. > > > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org To > unsubscribe, > > e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org To > unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
