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]
