tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aronszajn, Mark" <maron...@fhcrc.org>
Subject a discrepancy in webapp behavior in two environments
Date Wed, 18 Oct 2006 23:06:29 GMT
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?

Thanks in advance,

Mark

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message