mmh.. "You may hear the terms "green threads" and "native threads". This refers to the Unix implementations of Java. When Java 1.0 first came out on Solaris, it did not use the native Solaris library libthread.so to support threads. Instead it used runtime thread support that had been written in Java for an earlier project code-named "Green." That thread library came to be known as "green threads."
"Thread support on Windows used the native libraries from the start, but on Solaris green threads were used. That meant that threaded programs running on Solaris didn't get the benefit of the native libraries. In particular, if your Java program was executing on a multi processor Solaris system, it was never the case that different threads could execute truly in parallel by being dispatched on different processors. There are other benefits too, to do with more efficient mapping of I/O system calls." -> Just Java 2, Fourth Edition, by Peter van der Linden So Windows always uses native threads. Seems to me like a Windows system or license limit. I have already asked tech support of the hosting provider who installed the server, but no answer yet. -- Michael On Fri, Jul 01, 2005 at 11:02:44AM +0200, delbd wrote: > I may be wrong, but as far as my knowledge goes on green threads, this is > just a matter of > dedactivating native system thread to use an internal threading / sheduling > system in the jvm. > I see no reason why this wouldn't exist on windows version of jvm. > > Le Vendredi 1 Juillet 2005 10:39, Michael Kleinhenz a écrit : > > > > as far as I know, the concept of green and native threads only applies > > to Unix systems...? > > > > -- Michael > > > > > > On Fri, Jul 01, 2005 at 10:44:38AM +0200, delbd wrote: > > > Maybe you could switch the jvm to green threads ? > > > Le Vendredi 1 Juillet 2005 09:57, Michael Kleinhenz a écrit : > > > > > > > > maybe. I can't confirm, because it fails so fast, I can't take a look > > > > in > > > > the manager app to see the exact number of threads when it begins > > > > hanging. > > > > > > > > I experienced the problem with Tomcat 5.0.28+JDK1.4.2 and Tomcat > > > > 5.5.9+JDK1.5.0 while my (somewhat slower) notebook can do 800+ threads > > > > with Debian and 5.0.28+1.4.2 without problems. > > > > > > > > Seems to me like a Windows problem, but I can't find anything in the > > > > docs nor via Google.. ;-( > > > > > > > > Windows sucks.. > > > > > > > > -- Michael > > > > > > > > delbd schrieb: > > > > > Just by curiosity, does it have something like '511 Threads is ok but > > > > > 512 fails?' :D > > > > > Le Jeudi 30 Juin 2005 15:09, Michael Kleinhenz a écrit : > > > > > > > > > >>Hi, > > > > >> > > > > >>I'm currently integrating a SOAP-based middleware on Tomcat (5.5.9) > > > > >>with > > > > >>Sun JDK 1.5.0_02 and get into problems when using maxThreads with a > > > > >>value greater than 500. > > > > >> > > > > >>Tomcat locks up completely without getting back to normal operations > > > > >>after a while. No exception or error is reported in the logs, it just > > > > >>stops. All connections are refused after the lockup. Tomcat has enough > > > > >>memory (>1GB) assigned with the JVM options. > > > > >> > > > > >>If I use maxThreads="500", the server runs fine, but 500 is not enough > > > > >>for my project ;-( > > > > >> > > > > >>I tried to increase the stack size, but this doesn't help.. > > > > >> > > > > >>The connector is defined as: > > > > >> > > > > >><Connector port="8888" maxHttpHeaderSize="8192" maxThreads="500" > > > > >> minSpareThreads="50" maxSpareThreads="150" enableLookups="false" > > > > >> redirectPort="8443" acceptCount="200" connectionTimeout="20000" > > > > >> disableUploadTimeout="true"/> > > > > >> > > > > >>If I change 500 to 700 or more, Tomcat locks up. Is this a Windows > > > > >>problem?? > > > > >> > > > > >>Hardware is not an issue, I think.. (dual Xeon 3,4GHz, 4GB).. > > > > >> > > > > >>Thanks, > > > > >>Michael > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > David Delbecq > > > Royal Meteorological Institute of Belgium > > > > > > - > > > Is there life after /sbin/halt -p? > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > David Delbecq > Royal Meteorological Institute of Belgium > > - > Is there life after /sbin/halt -p? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Michael Kleinhenz tarent GmbH . Bahnhofstr. 13 . 53123 Bonn fon +49 (228) / 52 67 5-0 . fax +49 (228) / 52 67 5-25 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
