>From the description of the symptom - months' testing experience, we could pretty much confirm that it is a MP issue, not a MT issue. Chasing the stack dump of Java may not get to any significant point. If you try to fix the MP specific issue like this at the high level like Tomcat/JAVA app code, you will get to a situation like: fix one issue, another issue will come up eventually.
The producer of MSVCR80.dll may be interested in knowing this. This may be Win32 OS or JVM specific. Appreciate your findings and solution! Dong -----Original Message----- From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: Saturday, 9 December 2006 6:18 AM To: Tomcat Users List Subject: Re: Multi processor issue the affinity 'trick' is a replacement dll for the 80 runtime stock libraries The individual most familiar with interfacing to the runtime is mladen turk I would make all attempts to ping him on the solution As a comparison between the 2 dlls Here are the binary characteristics of the stock msvcr80.dll that ships with retail windows packages Section contains the following exports for MSVCR80.dll 0 characteristics 40ECD724 time date stamp Thu Jul 08 01:09:56 2004 0.00 version 1 ordinal base 1367 number of functions 1367 number of names ordinal hint RVA name /*and the replacement msvcr80.dll provided in setaffinity*/ Section contains the following exports for MSVCR80.dll 0 characteristics 4333A455 time date stamp Fri Sep 23 02:44:37 2005 0.00 version 1 ordinal base 1459 number of functions 1459 number of names ordinal hint RVA name so the new msvcr80.dll from setaffinity has 92 new functions which allow it to work reliably with MP calls HTH, Martin-- --------------------------------------------------------------------------- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --------------------------------------------------------------------------- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. > But the evidence seems to show two threads are manipulating the same > request, otherwise you wouldn't get the error on the ParameterMap. > Does a full thread dump show any threads that aren't part of the set > started by Tomcat? > either that, or a Request is reused before recycle() has been executed completely. We assumed this as well but after instrumenting more our code, we concluded it was not possible because the corruption seemed to occur before the end of the 2 requests processing and so before recycle() was called. I got some logs which sort of showed this but I can't find them right now, I have stopped working on this issue 3 weeks ago. > Alas, you could do a test and check whether the method getParameter is > actually ever called by two threads during one lifecycle (patching the > ParameterMap class, storing last accessing thread, and checking whether > another thread is already stored on access) We did it but for some reason the log statements did not get logged in our usual log file. Then after we tried the affinity trick which made the symptom to disappear and got no chance to try again. > And Gael, the CPU is the most valuable resource in the production environment, > are you really ready to give up your scaleability but simply not investigating > further? Well, this application is load balanced on 4 servers and the load is currently pretty low on each of them even when running on a single CPU. We did add more logs to our application and we did also instrument Tomcat but with no luck and as we were unable to reproduce it in a dev environment, it's difficult to ask for short downtimes to restart a server in production. On top of that, my team is being moved to another project... Gael --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
