Problem with request parameters getting mixed with requests from minutes before (PartII)

[ia...@info.seino.co.jp]

On Thu, Jun 03, 2004 at 07:41:30PM +0900, ian.wark wrote:
: We have a really difficult problem that surfaces only once every week or
so
: in which request parameters
: for requests from a particular mapping get mixed randomly with request
: parameters from the same mapping
: that occurred minutes before.
:
: Has anyone come across this before or know why it might be happening? How
: we might avoid it?

"duplicate info for different people" usually means
"instance variable where there should be a method-local variable"

----------There is a request instance variable in the bean, however the
action creates a bean for each request inside the control method, so
----------I can't see there being multiple threads accessing the same
instance variable.

How are these request params being set?

-QM

----------The short answer is: the application uses the struts framework
and on this jsp, submitting is done via JavaScript form submits.

Here are some more details.

We can tell that is is the same session from the log. So it is the same
user.

The user does a search and comes up with a list of items. Each item in the
list has a link that submits to a details screen that has the
details of that particular item. On that screen various information is
displayed and there are three buttons below. One called 'check',
one called 'back' (ie back to the search list) and another one that is
something like 'finished with'. After clicking the 'check' the 'finished
with'
button becomes pressable. All submitting is done via JavaScript form
submits.

The problem seems to occur after a sequence similar to the following:

1. User clicks the link to get to the detail screen
2. User clicks the 'check' button which submits the request to itself and
updates the check status.
3. The user clicks another button. Which button is not clear because the
parameter reads something equivalent to 'check eck' (Japanese equivalent)
which does not exist. The button name is taken via JavaScript.

The other strange parameter is alarmNo which picks up randomish information
after the = sign. Normally there is just one number. Here is an excerpt of
one mishappen request from our log.

[POST]/AlarmDetail.do?finishUserId=&changeConfirmFlg=0&addDatet=2004/05/29
09:13:58A13:58&confirmExecUpdFlg=0&errfilepath
=&alarmNo=39372=38932dFlg=039583
&alarmDetail=etc etc..
We thought at first that the reason might be because the button doesn't
have a multiple press lock via Javascript, so that you don't accicentally
submit twice. It does have a 'Do you really want to do this' style dialog
box. But even if the user managed to submit twice, you don't get two
requests getting bunged together.

Another very outside chance might be memory leaks. We have closed all the
statements in our SQL explicitely, but not the ResultSets.

Does that make things little a bit clearer?


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org