> From: JiaDong Huang [mailto:[EMAIL PROTECTED] > Subject: RE: Multi processor issue > > It is a MT issue, but MP specific.
Strictly speaking, it's not MP-specific. If run long enough, the problem will appear on a single CPU. Its occurrence would require the first thread to exhaust its CPU time slice at a critical point, and have the second thread be dispatched immediately. (In most operating systems, when a thread uses up its time slice, it's placed at the end of the dispatch queue for its priority, thus allowing other threads of the same or higher priority to run ahead of it. Note that the OS-defined priority in this case often has little to do with the Java-specified priority for a thread.) That said, the situation is certainly much, much more likely to occur on an MP system. > The Tomcat code you had dug out (having problem and throwing > the exception) has been designed as single threaded. But in MP > environment, multiple threads get in and cause issue like this. > That means somewhere in Tomcat or JVM, the synchronization > facility has already been broken While that would be true in general, it's not the case here. Objects of the Request class are never intended to be used concurrently by multiple threads, so there is no synchronization defined or implemented for them. No second thread - whatever its origin - should be operating on the same Request object that another thread is handling. > As far as I understand, Tomcat connector may use JNI The APR and AJP connects are implemented with JNI, the standard HTTP and HTTPS ones are pure Java. > not sure the threads we are talking about had run through the > code implemented with JNI. They did not, but it's not really relevant, given the Tomcat requirement of only one thread manipulating a Request object at a time. > Threads running through JNI may be re-marshaled between OS spaces - > switching OS rings or VM. They can change ring (generically, the thread privilege level), but not VMs. If you're suggesting that one thread may change its process association, that is theoretically possible on some OS implementations (anybody remember Multics?), but it is certainly not happening here, and, in any event, is completely irrelevant. (Any such change from one process to another must be extremely tightly controlled for security purposes, and is a capability simply not available to typical user threads.) > In another word, while switching between rings, the lock associated > with the objects may have been lost, etc. That's erroneous, even if it were relevant to this situation, which it isn't. There's no synchronization issue involved, since the Request object is not intended to be manipulated concurrently by multiple threads. This problem is almost certainly an application problem, either starting an additional thread somewhere or exposing the Request object improperly (e.g., storing a reference to it in the session) so that another thread erroneously starts working with this Request instead of the one its supposed to be working on. > Also, the JVM or OS API may need other synchronization > facility underneath while switching rings. These are > only my guess anyway. No code in the JVM depends on or expects to change privilege level (other than the privileges controlled entirely within the JVM), due to its platform independence. I think you may be trying to apply some rather esoteric capabilities of certain operating systems, but they really have no bearing on this situation. > It could be the JVM's synchronization facility does not work > properly in MP, for Tomcat. Or, Tomcat could be enhanced to > prevent this sort synchronization issue from happening. You're ignoring one basic fact: this problem has been reported on only *one* system running *one* particular application. If there were a general synchronization problem in Tomcat, the JVM, or the OS, it would certainly show up on some of the thousands (millions?) of other multi-processor systems running Tomcat. As I stated earlier, we have zero problems running Tomcat on our 32x servers (of various architectures). There is a very small chance that something in the hardware on this particular system has gone bad (e.g., lock signal not being propagated on the bus), but such a problem would undoubtedly show up in more places than this one spot in Tomcat. > After reviewing the messages, it is tomcat5.exe has been modified. > That means it may be tomcat5.exe should be considered to enhance, > in the area of thread synchronization/scheduling. Completely off base. The tomcat5.exe program is simply another way to launch a standard JVM; it does almost nothing other than apply the configured JVM options. It is merely the starting point for the process, so it's the easiest spot at which to impose affinity rules that will apply to all threads of the process. > To have the thread scheduler single threaded with single CPU would be > safer/better, and a reasonable thing to do. Perhaps safer (not guaranteed), but certainly not better, since it eliminates the chance of processing multiple requests in parallel, and thereby severely impacts response time and throughput. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
