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]
