RE: Possible thread crossing
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
Re: Possible thread crossing
Denise Mangano wrote, On 3/25/2004 8:04 AM: 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. I would guess that your formValidator class com.beans.clients.Validator may have some issues based on the behavior you've described. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible thread crossing
It would appear so, but the strange thing is that I have been using the same program since July of last year. I recently rebuilt my server and changed versions of RH, Apache and Tomcat - but my web pages and java programs were all restored from back up. This is what's boggling my mind - nothing has changed in my application itself and this just started happening a few weeks ago... Denise Mangano Complus Data Innovations, Inc. 914-747-1200 -Original Message- From: David Rees [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 11:15 AM To: Tomcat Users List Subject: Re: Possible thread crossing Denise Mangano wrote, On 3/25/2004 8:04 AM: 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. I would guess that your formValidator class com.beans.clients.Validator may have some issues based on the behavior you've described. -Dave - 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]
RE: Possible thread crossing
So far so good, but how is the serial number stored
in the validator bean ?
If the id is stored in an instance variable it may be
possible that 2 concurrent request in the same session
to any form that uses this bean might cause problems.
(It is possible to change the value between
jsp:setProperty and isValid())
What exactly is the purpose of the serial id ?
-Original Message-
From: Denise Mangano [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 5:05 PM
To: Tomcat Users List
Subject: RE: Possible thread crossing
%@ 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()) { %
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible thread crossing
Denise Mangano wrote, On 3/25/2004 8:45 AM: It would appear so, but the strange thing is that I have been using the same program since July of last year. I recently rebuilt my server and changed versions of RH, Apache and Tomcat - but my web pages and java programs were all restored from back up. This is what's boggling my mind - nothing has changed in my application itself and this just started happening a few weeks ago... This is a wild stab in the dark, but are you using SSL? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible thread crossing
You have basically this options: - The error was introduced by the update of the underlying software - The error was there before and somehow just didn't show That is shows up after the update may be coincidence. Or it just show because the new system is faster/slower than before. From your description the second one is (in my opinion) most likely. -Original Message- From: Denise Mangano [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 5:46 PM To: Tomcat Users List Subject: RE: Possible thread crossing It would appear so, but the strange thing is that I have been using the same program since July of last year. I recently rebuilt my server and changed versions of RH, Apache and Tomcat - but my web pages and java programs were all restored from back up. This is what's boggling my mind - nothing has changed in my application itself and this just started happening a few weeks ago... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible thread crossing
Ralph,
In the bean there is an instance variable:
private static String serialNumber=;
And it is set using the regular set method:
public void setserialNumber(String sn) { serialNumber = sn; }
The purpose of the serial number is to identify which client the
information being processed is for. Correct me if I am wrong but I have
the scope of the bean set to session. That means that that when user A
accesses my first JSP page it starts a session and the variables apply
to that session until the user ends it. If user B comes to the site
they get their own session started. Is that correct? If so then if
User A is in the middle of the session how could it be possible that
they are requested the form more than once in their session?
Dave, yes I am using mod_ssl 2.8.16.
Thanks.
Denise Mangano
Complus Data Innovations, Inc.
914-747-1200
-Original Message-
From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 11:43 AM
To: Tomcat Users List
Subject: RE: Possible thread crossing
So far so good, but how is the serial number stored in the validator
bean ?
If the id is stored in an instance variable it may be possible that 2
concurrent request in the same session to any form that uses this bean
might cause problems.
(It is possible to change the value between jsp:setProperty and
isValid())
What exactly is the purpose of the serial id ?
-Original Message-
From: Denise Mangano [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 5:05 PM
To: Tomcat Users List
Subject: RE: Possible thread crossing
%@ 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()) { %
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
-
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]
RE: Possible thread crossing
Ha ! Gotcha !
That's no instance variable
It's a class variable
It is shared by all instances of the bean !!!
change it to:
private String serialNumber=;
-Original Message-
From: Denise Mangano [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 6:14 PM
To: Tomcat Users List
Subject: RE: Possible thread crossing
In the bean there is an instance variable:
private static String serialNumber=;
And it is set using the regular set method:
public void setserialNumber(String sn) { serialNumber = sn; }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible thread crossing
Hi,
Why is the serialNumber field static?
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Denise Mangano [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 12:14 PM
To: Tomcat Users List
Subject: RE: Possible thread crossing
Ralph,
In the bean there is an instance variable:
private static String serialNumber=;
And it is set using the regular set method:
public void setserialNumber(String sn) { serialNumber = sn; }
The purpose of the serial number is to identify which client the
information being processed is for. Correct me if I am wrong but I
have
the scope of the bean set to session. That means that that when user A
accesses my first JSP page it starts a session and the variables apply
to that session until the user ends it. If user B comes to the site
they get their own session started. Is that correct? If so then if
User A is in the middle of the session how could it be possible that
they are requested the form more than once in their session?
Dave, yes I am using mod_ssl 2.8.16.
Thanks.
Denise Mangano
Complus Data Innovations, Inc.
914-747-1200
-Original Message-
From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 11:43 AM
To: Tomcat Users List
Subject: RE: Possible thread crossing
So far so good, but how is the serial number stored in the validator
bean ?
If the id is stored in an instance variable it may be possible that 2
concurrent request in the same session to any form that uses this bean
might cause problems.
(It is possible to change the value between jsp:setProperty and
isValid())
What exactly is the purpose of the serial id ?
-Original Message-
From: Denise Mangano [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 5:05 PM
To: Tomcat Users List
Subject: RE: Possible thread crossing
%@ 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()) { %
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
-
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]
This e-mail, including any attachments, is a confidential business communication, and
may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved, copied, printed, disclosed or used by anyone else. If you are not the(an)
intended recipient, please immediately delete this e-mail from your computer system
and notify the sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible thread crossing
For the life of me I cannot recall why I made them static!!! There are
a few other variables that I had static as well. I want to say that
when I was writing the program I was getting compile errors stating that
I cannot reference non-static variables and changing them to static
allowed the program to compile (major newbie mistake/assumption I am
sure).
I just created a copy of my program and removed static from the
serialNumber as well as a few other variables I had made static and
everything compiled fine. Very strange though that it has been working
fine this entire time??? :-/ I guess the next step is to make this
change in the live program and monitor it very closely...
Thanks again.
Denise Mangano
Complus Data Innovations, Inc.
914-747-1200
-Original Message-
From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 12:16 PM
To: Tomcat Users List
Subject: RE: Possible thread crossing
Ha ! Gotcha !
That's no instance variable
It's a class variable
It is shared by all instances of the bean !!!
change it to:
private String serialNumber=;
-Original Message-
From: Denise Mangano [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 6:14 PM
To: Tomcat Users List
Subject: RE: Possible thread crossing
In the bean there is an instance variable:
private static String serialNumber=;
And it is set using the regular set method:
public void setserialNumber(String sn) { serialNumber = sn; }
-
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]
RE: Possible thread crossing
Denise Mangano wrote: For the life of me I cannot recall why I made them static!!! There are a few other variables that I had static as well. I want to say that when I was writing the program I was getting compile errors stating that I cannot reference non-static variables and changing them to static allowed the program to compile (major newbie mistake/assumption I am sure). It's a common mistake to make. I just created a copy of my program and removed static from the serialNumber as well as a few other variables I had made static and everything compiled fine. Very strange though that it has been working fine this entire time??? :-/ I guess the next step is to make this change in the live program and monitor it very closely... It will appear to work fine under light testing or light load scenarios. Once load increases or requests happen to come in at the same time these types of concurrency issues will show up. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible thread crossing
Probably you tried to access the variables from a static method.
(Which isn't static any longer or has been removed or changed in
way that it doesn't access the variabled)
That the problem shows up only recently may be caused be a change
in the usage pattern of the site or because your updated environment
has different timings than before.
I also have seen errors that where just not noticed for several
months, than you make a change to the system, look closer at the
system, see the error and think 'Oh how can this change cause
such an error.
-Original Message-
From: Denise Mangano [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 6:32 PM
To: Tomcat Users List
Subject: RE: Possible thread crossing
For the life of me I cannot recall why I made them static!!!
There are
a few other variables that I had static as well. I want to say that
when I was writing the program I was getting compile errors
stating that
I cannot reference non-static variables and changing them to static
allowed the program to compile (major newbie mistake/assumption I am
sure).
I just created a copy of my program and removed static from the
serialNumber as well as a few other variables I had made static and
everything compiled fine. Very strange though that it has
been working
fine this entire time??? :-/ I guess the next step is to make this
change in the live program and monitor it very closely...
Thanks again.
Denise Mangano
Complus Data Innovations, Inc.
914-747-1200
-Original Message-
From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 12:16 PM
To: Tomcat Users List
Subject: RE: Possible thread crossing
Ha ! Gotcha !
That's no instance variable
It's a class variable
It is shared by all instances of the bean !!!
change it to:
private String serialNumber=;
-Original Message-
From: Denise Mangano [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 6:14 PM
To: Tomcat Users List
Subject: RE: Possible thread crossing
In the bean there is an instance variable:
private static String serialNumber=;
And it is set using the regular set method:
public void setserialNumber(String sn) { serialNumber = sn; }
-
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]
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]
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]
Re: Possible thread crossing
Denise Mangano wrote, On 3/23/2004 9:01 PM: 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? As Nix mentioned earlier, I suspect that you have a static variable (or shared scope variable) which gets stepped on by other threads when load gets high. It is highly unlikely it's a Java/Tomcat issue, and highly likely it's a web app bug. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: Possible thread crossing
Hi, One thing I have noticed is that there is only one java thread when I start tomcat. On a previous install there had been about 8. Here is the output of ps -ef relative to tomcat: tomcat 13074 1 0 Mar11 ?00:00:32 /usr/local/java/bin/java -Djava.endorsed.dirs=/usr/local/tomcat/common/endorsed -classpath /usr/local/java/lib/t Then your previous install was strange ;) There's only one (per instance of tomcat) OS-level thread. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
