Thanks for the replies. This is the process involved in my webapp:
At the bottom of my form I have: <input type="hidden"
name="serialNumber" value="123456789">
The action of this form calls the following control jsp:
<%@ page import="com.beans.clients.Validator" %>
<jsp:useBean id="formValidator" class="com.beans.clients.Validator"
scope="session"/>
<% formValidator.reset(); %>
<jsp:setProperty name="formValidator" property="*"/>
<% if (formValidator.isValid()) { %>
<jsp:forward page="Verify.jsp"/>
<% } else { %>
<jsp:forward page="Retry.jsp"/>
<% } %>
If the form data is not valid it calls Retry.jsp which I have tried two
ways:
1) <input type="hidden" name="serialNumber"
value="<%=formValidator.getSerialNumber()%>">
2) <input type="hidden" name="serialNumber" value="123456789">
If the form data is completely valid then Verify.jsp is called.
Verify.jsp just retrieves the form data (not the serialNumber) and
displays it to the user. Nothing can be changed on this screen and when
the user clicks submit the data is taken from the instance of
Validator.java and sent of for processing. The user does have the
option to go back and make changes which brings them to the previous
page.
One thing to note. On Retry.jsp up until yesterday I had the first way
in the jsp page. I changed this yesterday to make sure it was hard
coded from all possible change points and so far since then no
transactions have crossed over - but it is still a little too early to
tell since these "crossings" were random and not happening everyday.
Thank you for taking a look.
Denise Mangano
Complus Data Innovations, Inc.
914-747-1200
-----Original Message-----
From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 2:34 AM
To: Tomcat Users List
Subject: RE: Possible thread "crossing"
That the problem is just happening for users that have the highest
volume, might indicate that you have a threading problem. (Like a
variable that should only be visible in the current request, is visible
to concurrent requests)
If there is a threading problem it's most likely in your application or
a third party software. (I wouldn't bet that tomcat isn't having such
issues, but it is much less likely)
Can you show how you set the id in the jsp ?
Can you show a example how you process the jsp ?
If you can't make it public, you may post it to me directly (No
guarantee how much time I will have to look at it).
The memory that is used by your java is very unlikely to cause such
symptoms. (In certain instances it may indirectly affect the problem by
increasing the runtime for each request and this way rising the
probability that requests are processed concurrently)
> -----Original Message-----
> From: Denise Mangano [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 24, 2004 6:02 AM
> To: Tomcat Users List
> Subject: RE: Possible thread "crossing"
>
>
> I just wanted to point out again that this data appears to be getting
> "crossed" only with the clients that have the highest volume.... This
> is why I am thinking it's a java/Tomcat issue. Perhaps my java isn't
> using enough memory? (old-newbie guess?) How would I check something
> like that, and if it is too low how do I increase it?
>
> Thanks again.
>
>
> Denise Mangano
> Complus Data Innovations, Inc.
> 914-747-1200
>
> -----Original Message-----
> From: Denise Mangano
> Sent: Tuesday, March 23, 2004 11:53 PM
> To: Tomcat Users List
> Subject: RE: Possible thread "crossing"
>
> Can I please verify something? This webapp has been live since last
> year and I have never had this problem. I recently reformatted my
> server changing versions of Tomcat, Apache and RH. The programs and
> web pages I am using are the same - pulled from backups so nothing has
> changed.
>
> This is my java program structure: /com/beans/transaction/*.java.
>
> The pages accessing these programs are located in:
> /webapps/ROOT/clients/client1
> /webapps/ROOT/clients/client2
> etc...
>
> When someone goes to client one and accesses the java program an
> individual instance of the program is created, correct? So if user 1
> starts a transaction from /client1 and user 2 starts a transaction
> from
> /client2 each user has it's own instance of the java program running -
> so technically data from one instance should not be finding it's way
> to another. I made some changes to my webapp but this still appears
> to be happening.
>
> Nix:
> 1. Network sniffer? If I add some debugging code to my java program
> is this what you mean? Or is there a tool I can actually use?
> 2. The two key variables are a transaction number and this serial
> number. Both are hard coded into the JSP pages and are not changed by
> anything in either my JSP or my java program. Only variables that
> change are personal info (i.e. address).
>
> Thanks.
>
>
> Denise Mangano
> Complus Data Innovations, Inc.
> 914-747-1200
>
> -----Original Message-----
> From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 22, 2004 1:13 AM
> To: Tomcat Users List
> Subject: Re: Possible thread "crossing"
>
> Denise Mangano wrote:
>
> > The only thing I can narrow it down to is Tomcat/Java. Like I said
> > the serial numbers are hard coded on the jsp pages. Everytime this
> > jsp page is submitted it forms its own instance of my java
> bean which
> > can be called one or more times. So I guess my question is - is it
> > possible that somehow information from one thread is leaking to
> another thread?
>
> So, not only "data is leaking", but always the same data. That is
> possible, but sooo unlikely. I'd do two things.
>
> 1: setup network sniffer, see the actual data being sent
> 2: look for some static/instance variables being updated in those JSPs
>
> Nix.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
