Re: SSL hangs on Tomcat 4.1.18

[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

[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>