Jiadong/Gael Can you download the code to a sandbox and implement your synchronized algorithm in setLocked to test out the intended result? Or is the code not available?
M- --------------------------------------------------------------------------- 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. ----- Original Message ----- From: "JiaDong Huang" <[EMAIL PROTECTED]> To: "'Tomcat Users List'" <users@tomcat.apache.org> Sent: Tuesday, December 12, 2006 7:24 PM Subject: RE: Multi processor issue > Great to see the bottom of the MT issue has been revealed/understood. I > believe Gael may be able to fix his app now. Hope it can be an easy fix... > > Not sure if the app really cares which thread should do the parameterMap > initialization. If it does not, then it would be a good idea for Tomcat to > refine/enhance the parameterMap initialization procedure to be MT safe. > > Apparently, the current lock facility (isLocked() and setLocked()) does not > protect MT case properly, while initializing. > > Is it worthwhile and appropriate to have certain MT synchronization facility > like isInitialized() and setInitialized() around the code? In theory, the > second thread can wait for isInitialized() there. Not sure if it will cause > any concern to other apps, like having other racing condition. Really depend > on the parameterMap usage/operation. MT issue fix can never be simple. > > Chuck understands parameterMap usage very well. Maybe he can make further > comments/recommendation to the Tomcat dev team. > > Dong > > -----Original Message----- > From: Marziou, Gael [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 13 December 2006 3:24 AM > To: Tomcat Users List > Subject: RE: Multi processor issue > > >> Anything dealing with a session must be careful not to expose a >> Request object to the session scope, since there's the risk another >> request for the same session may get confused with the first - I >> suspect that's what's happening here. > > Will do. > >> You should take a careful look at all the com.hp code in the stack >> trace (not just the above three places) and verify that Request >> objects are not getting mixed up. Might want to add some trace code >> in various places to insure that a given thread is procesing the same >> Request object at all points. > > Yes, it makes sense. > >> Could also try turning off APR (remove or rename tcnative-1.dll) and >> see if that has an effect. > > I already did at the beginning of our investigation as I suspected the > JNI code but it had no effect. > > 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] > >
