You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Carl Zetterberg <ca...@telia.com> on 2002/12/28 17:39:43 UTC

SSL hangs on Tomcat 4.1.18

I´m running Tomcat 4.1.18 om Win2000 and j2sdk1.4.1_01.

After a couple of days usage the HTTPS connector hangs. The following is
witten to stdout:

2002-dec-28 07:40:11 org.apache.tomcat.util.log.CommonLogHandler log
INFO: All threads are busy, waiting. Please increase maxThreads or check the
servlet status75 75

In server.xml, the default parameters are used except for port number:

    <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
               port="443" minProcessors="5" maxProcessors="75"
               enableLookups="true"
	       acceptCount="10" debug="0" scheme="https" secure="true"
               useURIValidationHack="false">
      <Factory
className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
               clientAuth="false" protocol="TLS" />
    </Connector>

It seems the CoyoteConnector is running out of threads, even though the load
on the server is low. Not reusing threads properly?

I've had the same problem on Tomcat 4.1.12 and 4.1.17

Best regards,

Carl Zetterberg

carl.zetterberg@telia.com
www.tidrapp.nu



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: SSL hangs on Tomcat 4.1.18

Posted by Remy Maucherat <re...@apache.org>.
Carl Zetterberg wrote:
> Xiaojian Wang of infowisesys.com writes:
> 
> "After starting Tomcat , open a navigator to visit any page,then press F5
> to  fresh.After a few minutes,a message accured: "All threads are busy,
> waiting. Please increase maxThreads or check the servlet status75 75" 75
> is the maxProcess of my setting. It's a normal message that sugguest you
> to increst your mxProcessing setting. In normal mode,tomcat accept new
> connection after processed the pooled connection. But in SSL mode,it
> hang!!!"
> 
> And he suggests a solution:
> 
> "... download the source code jakarta-tomcat-connectors-4.1.18-src on www.
> apache.org, change PoolTcpPoint.java at:
> Line 515:continue==>break
> Line 528:continue==>break
> Maybe you also have to change
> Line 434 from
> if(linger >= 0 )
> 	socket.setSoLinger( true, linger);
> to
> //if(linger >= 0 )
> 		//socket.setSoLinger( true, linger);
> because soLinger is OS sensitive.Tell me if you what does soLinger mean
> or how to set it :-(
> 
> Recompile and replace the relate class in tomcat-uitl.
> 
> I believe it work well."
> 
> Going to try this when I get to work tomorrow.

The report is valid (although a bit hard to understand). Only the change 
for line 515 is useful (as well as a change of the logging priority line 
510 to debug to avoid abusive logging).

The if block line 527-528 should be removed (it cannot happen).

The soLinger doesn't seem harmful.

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: SSL hangs on Tomcat 4.1.18

Posted by Carl Zetterberg <ca...@telia.com>.
Xiaojian Wang of infowisesys.com writes:

"After starting Tomcat , open a navigator to visit any page,then press F5
to  fresh.After a few minutes,a message accured: "All threads are busy,
waiting. Please increase maxThreads or check the servlet status75 75" 75
is the maxProcess of my setting. It's a normal message that sugguest you
to increst your mxProcessing setting. In normal mode,tomcat accept new
connection after processed the pooled connection. But in SSL mode,it
hang!!!"

And he suggests a solution:

"... download the source code jakarta-tomcat-connectors-4.1.18-src on www.
apache.org, change PoolTcpPoint.java at:
Line 515:continue==>break
Line 528:continue==>break
Maybe you also have to change
Line 434 from
if(linger >= 0 )
	socket.setSoLinger( true, linger);
to
//if(linger >= 0 )
		//socket.setSoLinger( true, linger);
because soLinger is OS sensitive.Tell me if you what does soLinger mean
or how to set it :-(

Recompile and replace the relate class in tomcat-uitl.

I believe it work well."

Going to try this when I get to work tomorrow.

Regards/Carl

> -----Ursprungligt meddelande-----
> Fran: Remy Maucherat [mailto:remm@apache.org]
> Skickat: den 29 december 2002 17:56
> Till: Tomcat Users List
> Amne: Re: SSL hangs on Tomcat 4.1.18
>
>
> mech wrote:
> > I was just trying around with minProcessors="1" and maxProcessors="2"
> >
> > Although I get this warnings quite easily (just 2 or 3 browser windows
> > are enough), after one request (really slow) is completed the next
> > request is processed. So obviously the threads must have been reused.
> > If I set acceptCount="1" the browser comes up with page not found if all
> > threads are in use.
> >
> > Maybe play around with the acceptCount setting. Even If your load is
> > low, some "nervous" user might keep clicking on https links, if the page
> > is not loading quickly enough.
> > I wonder not to see an "connectionTimeout" attribut? I set to 20000 for
> > http and https (default should be 60000 according to documentation).
> > Maybe that makes a difference, too?
> >
> > By the way I encountered the following exception, if I stress test too
> > much:
>
> I don't know why you get that exception, but if you actually get it,
> then the root cause should be that something went bad during the socket
> accept.
> Standard socket processing is obviously better tested than SSL sockets,
> so I doubt this happens; could you debug this further, and give more
> details ?
>
> It would be a good idea to test stability with PureTLS or the newest
> JSSE (that might help if the problems come from JSSE from JDK 1.4).
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: SSL hangs on Tomcat 4.1.18

Posted by mech <me...@rz.fh-augsburg.de>.
That's my Tomcat 4.1.18 server.xml used for testing. Running on Win98,
JDK 1.4.1b21

    <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
               port="8443" minProcessors="1" maxProcessors="2"
               enableLookups="true"
	       acceptCount="10" debug="0" scheme="https" secure="true"
connectionTimeout="20000"
               useURIValidationHack="false">

Tried it again, after a while of "wild and crazy" clicking in my Mozilla
and IE simultaniously and loading/waiting for https resources to be
loaded on my localhost (sometimes the request stall because of to much
load):

Caught exception executing
org.apache.tomcat.util.net.TcpWorkerThread@497062, terminating thread
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Jdk14Logger does not implement Log
	at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImp
l.java:555)
	at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImp
l.java:289)
	at
org.apache.commons.logging.LogFactory.getLog(LogFactory.java:409)
	at
org.apache.tomcat.util.log.CommonLogHandler.log(CommonLogHandler.java:97
)
	at org.apache.tomcat.util.log.Log.log(Log.java:198)
	at org.apache.tomcat.util.log.Log.log(Log.java:192)
	at
org.apache.tomcat.util.net.PoolTcpEndpoint.log(PoolTcpEndpoint.java:427)
	at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:51
0)
	at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:530)
	at java.lang.Thread.run(Thread.java:536)
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Jdk14Logger does not implement Log
	at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFact
oryImpl.java:420)
	at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImp
l.java:548)
	... 9 more
Caused by: org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Jdk14Logger does not implement Log
	at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFact
oryImpl.java:416)
	... 10 more





> I don't know why you get that exception, but if you actually get it, 
> then the root cause should be that something went bad during 
> the socket 
> accept.
I think I saw some error about sockets, too. But couldn't reproduce it
now. Maybe mixed it up. The only thing I can definitely reproduce as
often as I try is the above setting leading to those exceptions.
> Standard socket processing is obviously better tested than 
> SSL sockets, 
> so I doubt this happens; could you debug this further, and give more 
> details ?

Stopping service Tomcat-Standalone
29.12.2002 18:08:12 org.apache.tomcat.util.log.CommonLogHandler log
SCHWERWIEGEND: Caught exception executing
org.apache.tomcat.util.net.TcpWorkerThread@497062, terminating thread
java.lang.IllegalStateException
	at
org.apache.tomcat.util.threads.ThreadPool.runIt(ThreadPool.java:245)
	at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50
3)
	at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:530)
	at java.lang.Thread.run(Thread.java:536)

> 
> It would be a good idea to test stability with PureTLS or the newest 
> JSSE (that might help if the problems come from JSSE from JDK 1.4).
> 
Actually this all was just a simple test myself. I didn't experience
problems with ssl under normal "setting". This thing with processors 1-2
was just a test I wouldn't do in real life.

My advice: Simply don't try those stupid settings. I wouldn't even know
where to start debugging more. I'm happy if everything works with the
default setup ;-)

> Remy
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: SSL hangs on Tomcat 4.1.18

Posted by Remy Maucherat <re...@apache.org>.
mech wrote:
> I was just trying around with minProcessors="1" and maxProcessors="2"
> 
> Although I get this warnings quite easily (just 2 or 3 browser windows
> are enough), after one request (really slow) is completed the next
> request is processed. So obviously the threads must have been reused.
> If I set acceptCount="1" the browser comes up with page not found if all
> threads are in use.
> 
> Maybe play around with the acceptCount setting. Even If your load is
> low, some "nervous" user might keep clicking on https links, if the page
> is not loading quickly enough.
> I wonder not to see an "connectionTimeout" attribut? I set to 20000 for
> http and https (default should be 60000 according to documentation).
> Maybe that makes a difference, too?
> 
> By the way I encountered the following exception, if I stress test too
> much:

I don't know why you get that exception, but if you actually get it, 
then the root cause should be that something went bad during the socket 
accept.
Standard socket processing is obviously better tested than SSL sockets, 
so I doubt this happens; could you debug this further, and give more 
details ?

It would be a good idea to test stability with PureTLS or the newest 
JSSE (that might help if the problems come from JSSE from JDK 1.4).

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: SSL hangs on Tomcat 4.1.18

Posted by mech <me...@rz.fh-augsburg.de>.
I was just trying around with minProcessors="1" and maxProcessors="2"

Although I get this warnings quite easily (just 2 or 3 browser windows
are enough), after one request (really slow) is completed the next
request is processed. So obviously the threads must have been reused.
If I set acceptCount="1" the browser comes up with page not found if all
threads are in use.

Maybe play around with the acceptCount setting. Even If your load is
low, some "nervous" user might keep clicking on https links, if the page
is not loading quickly enough.
I wonder not to see an "connectionTimeout" attribut? I set to 20000 for
http and https (default should be 60000 according to documentation).
Maybe that makes a difference, too?

By the way I encountered the following exception, if I stress test too
much:

---

Caught exception executing
org.apache.tomcat.util.net.TcpWorkerThread@c62080, terminating thread
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Jdk14Logger does not implement Log
	at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImp
l.java:555)
	at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImp
l.java:289)
	at
org.apache.commons.logging.LogFactory.getLog(LogFactory.java:409)
	at
org.apache.tomcat.util.log.CommonLogHandler.log(CommonLogHandler.java:97
)
	at org.apache.tomcat.util.log.Log.log(Log.java:198)
	at org.apache.tomcat.util.log.Log.log(Log.java:192)
	at
org.apache.tomcat.util.net.PoolTcpEndpoint.log(PoolTcpEndpoint.java:427)
	at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:51
0)
	at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:530)
	at java.lang.Thread.run(Thread.java:536)
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Jdk14Logger does not implement Log
	at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFact
oryImpl.java:420)
	at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImp
l.java:548)
	... 9 more
Caused by: org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Jdk14Logger does not implement Log
	at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFact
oryImpl.java:416)
	... 10 more

---

Class "org.apache.commons.loggin.impl.Jdk14Logger does not implement
Log" ??? BTW why doesn't it implement "Log", guess it should, shouldn't
it?



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>