Hi Lipi,
are you by any chance integrating Tomcat with IIS using JK2? And does the death lock 
occur whether you use port 80 or 8080?

/Thomas




"rlipi" <[EMAIL PROTECTED]>
06-05-2004 09:25
Besvar venligst til "Tomcat Users List"

 
        Til:    "'Tomcat Users List'" <[EMAIL PROTECTED]>
        cc: 
        Vedr.:  RE: How to limit time for Connector threads?



Yes, I did it.

But it is not solution. Server doesn't answer slowly or for only some
requests. It doesn't answer at all. It means that treads are not
terminated and resources are not released. Sometimes, server doesn't
answer without "All threads are currently busy" exception. That is why I
think that the problem is some death lock.

Lipi


> -----Original Message-----
> From: STOCKHOLM, Raymond [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 06, 2004 8:56 AM
> To: Tomcat Users List
> Subject: RE: How to limit time for Connector threads?
> 
> Maybe you should increase the number of threads in your connector.
> 
> check attribut maxProcessors in your server.xml
> In this example, I set it to 500 instead of 75 (default value)
> 
>     <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
>                port="80" minProcessors="30" maxProcessors="500"
>                enableLookups="true" redirectPort="8443"
>                acceptCount="100" debug="0" connectionTimeout="20000"
>                useURIValidationHack="false"
disableUploadTimeout="true" />
> 
> -----Message d'origine-----
> De : rlipi [mailto:[EMAIL PROTECTED]
> Envoyé : jeudi 6 mai 2004 08:40
> À : 'Tomcat Users List'
> Objet : How to limit time for Connector threads?
> 
> 
> Hallo,
> is it possible in any way to limit time for threads that realize user
> requests?
> 
> Sometimes (once a day in average), the Tomcat 5.0.19 server doesn't
> answers. The reason is in error message "All threads are currently
> busy". Probably there is a bug in the web application. Some kind of
> synchronization death lock, I think.
> But localization of this bug is very hard. So, termination (and
release
> of all resources) of long time threads can be a work around.
> 
> Thank you for any suggestions,
> Lipi.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





<FONT SIZE=1 FACE="Arial">_______________
Vi gør opmærksom på, at denne e-mail kan indeholde fortrolig information. Hvis du ved 
en fejltagelse modtager e-mailen, beder vi dig venligst informere afsender om fejlen 
ved at bruge svar-funktionen. Samtidig beder vi dig slette e-mailen i dit system uden 
at videresende eller kopiere den.
Selv om e-mailen og ethvert vedhæftet bilag efter vores overbevisning er fri for virus 
og andre fejl, som kan påvirke computeren eller it-systemet, hvori den modtages og 
læses, åbnes den på modtagerens eget ansvar. Vi påtager os ikke noget ansvar for tab 
og skade, som er opstået i forbindelse med at modtage og bruge e-mailen.
_______________
Please note that this message may contain confidential information. If you have 
received this message by mistake, please inform the sender of the mistake by sending a 
reply, then delete the message from your system without making, distributing or 
retaining any copies of it.
Although we believe that the message and any attachments are free from viruses and 
other errors that might affect the computer or IT system where it is received and 
read, the recipient opens the message at his or her own risk. We assume no 
responsibility for any loss or damage arising from the receipt or use of this message.
</FONT>

Reply via email to