[tomcat / JSP] No processor available *

[Bjoss]

We hebben problemen met onze jsp hosting, als er vele connecties gebeuren naar een JSP zorgt ie voor een mooie 500 error.

Nu dacht ik wat te neuzen in de logs en vond het volgende vele malen terug:

code:

Ajp13Connector[22888] about to create a processor, available=0, created=75, maxProcessors=75
Ajp13Connector[22888] No processor available, rejecting this connection
Ajp13Connector[22888] accepting socket...
Ajp13Connector[22888] active threads=76

Af en toe wordt dit dan nog eens bevestigd met zulke error message in log:

code:

Ajp13Processor[22888][12] [Ajp13] Error receiving message
Ajp13Processor[22888][12] received next request, status=500
Ajp13Processor[22888][12] closing ajp13 object...
Ajp13Processor[22888][12] [Ajp13] close()
Ajp13Processor[22888][12] ajp13 object closed.
Ajp13Processor[22888][12] closing socket...
Ajp13Processor[22888][12] socket closed.
Ajp13Processor[22888][12] process:  done

MaxProcessors staat inderdaad om 75, maar is het wel een goed idee om deze te verhogen? (Mag dit wel van onze hosting en zo?)
Is er een vorm van timeout voor zulke dingen? Dat ie automatisch zijn "processors" gaat sluiten.

Opvallend is wel dat het nooit gebeurt met simpele jsp'tjes, altijd met jsp waar een database connectie of XML wordt geparst (90% van de gevallen).


Nota: ik heb topic maar onder P&W gegooid, hopelijk staat ie hier goed.

[ Voor 7% gewijzigd door Bjoss op 08-04-2003 11:45 ]

[Verwijderd]

Het lijkt erop dat je gebruik maakt van een gedeelde resource die je niet synchroniseerd...

[Bjoss]

Wat bedoel je juist?

[Verwijderd]

als je van een gedeelde resource gebruik maakt zoals biojvoorbeeld een xml bestand, kunnen er conflicten en ongewenste resultaten onstaan. Deze problemen onstaan uiteraard pas als je met twee(of meerdere) clients tegelijkertijd een resource benaderen. Als je de verschillende threads(lees: clients) synchroniseerd zet je ze alsware in een wachtrij en handel je ze een voor een af. Meer over het synchroniseren van threads kun je uiteraard vinden op java.sun.com

[Bjoss]

Ow, ik denk niet dat dit het geval is hier. Buiten een database wordt er niets gedeeld.

Ik denk dat ik maar MaxProcessors ga verhogen in de server.xml en zien hoe het afloopt.

code:

<Connector className="org.apache.ajp.tomcat4.Ajp13Connector"
               port="22888" minProcessors="5" maxProcessors="75"
               acceptCount="10" debug="1"/>

[Bjoss]

Ondertussen zijn onze jsp pagina's niet meer bereikbaar. (Ik heb nog niet zitten prutsen met de server.xml )

Errorlog:

code:

Ajp13Connector[22888] accepted socket, assigning to processor.
Ajp13Connector[22888] about to create a processor, available=0, created=75, maxProcessors=75
Ajp13Connector[22888] No processor available, rejecting this connection
Ajp13Connector[22888] accepting socket...
Ajp13Connector[22888] accepted socket, assigning to processor.
Ajp13Connector[22888] about to create a processor, available=0, created=75, maxProcessors=75
Ajp13Connector[22888] No processor available, rejecting this connection
Ajp13Connector[22888] accepting socket...

Iemand goede raad?

[ProgrammerX]

Heb niet echt goede raad voor je, maar het lijkt er toch op dat er een resource niet wordt vrijgegeven (database connectie misschien?). Kun je misschien ontdekken of er ook processors worden vrijgegeven ? Krijg een beetje het idee dat het aantal processors in gebruik gewoon blijft oplopen.

Misschien kun je ook eens contact opnemen met je hosting provider, misschien hebben meerdere mensen problemen met hun jsp's op diezelfde computer ?

[Bjoss]

De mensen van de hosting provider weten ook geen oplossing volgens mij.

Het verhogen van de connectors is geen oplossing en we raden u dit ten zeerste af aangezien dit problemen met overload van de server kan veroorzaken met mogelijke gevolgen voor uw accounts.
U zal dienen uit te zoeken waarom de connecties open blijven en zorgen dat u uw servlets zo aanpast dat ze dit niet meer doen.

Volgens mij ligt het totaal niet aan de code maar aan de configuratie van tomcat vs apache. Mja, er moet toch iemand zijn bij de provider die daar iets van afweet?

[Verwijderd]

Die 75 processors wil gewoon aangeven dat hij 75 concurrent aanroepen kan verwerken.
Je hebt dan een aardig drukke site. Als je zwaardere dingen doet in een jsp zal je eerder tegen
je maximum van 75 lopen. Je kan je maximum gewoon verhogen. Je merkt zelf wel wanneer het
te traag wordt. Op dat moment moet je maar eens aan optimalisatie van je code of een nieuwe
machine gaan denken....

Succes

[Bjoss]

Maar ik zie zelden in de logfile dat die processors weer worden vrijgegeven. Er mist ergens een soort van timeout of zo?

In de tomcat docs wordt niet gesproken van een connectionTimeout of zo in het stuk:

code:

<Connector className="org.apache.ajp.tomcat4.Ajp13Connector"
               port="22888" minProcessors="5" maxProcessors="75"
               acceptCount="10" debug="1"/>

[Verwijderd]

In principe word de processor meteen na de response weer vrij gegeven.
Sessions worden op een ander niveau geregeld.

[zneek]

Misschien een idee om de db con in een aparte Class te gooien? En die gebruik te laten maken van een db connection pool? Beetje synchronisatie erin (meeste pools hebben dat zelf al) en er blijft geen process meer hangen op een db verbinding.

[Verwijderd]

Dit kan meerdere problemen hebben en heeft ook meerdere oplossingen. Ten eerste lijkt het me stug dat je site echt 75 actieve procs heeft, dan praat je echt over een super drukke site. Er zijn diverse mogelijke oorzaken:

(1) Je site/script laat procs actief
(2) De database connectie danwel mysql is zo traag, dat de procs te lang open staan
(3) Je site is gigantisch druk

Oplossingen hiervoor

(1) Optimaliseer je code
(2) Neem een eigen server of andere webhost
(3) idem als 2 of zet de procs hoger

Ik heb een paar zeer grote sites met tomcat (vrijwel elke recente versie) draaien met honderden bezoekers/uur, en geen problemen met bovenstaande (procs staat standaard op 75). Het is dus in ieder geval geen probleem van Tomcat zelf.

[ Voor 4% gewijzigd door Verwijderd op 21-04-2003 21:07 ]

[Verwijderd]

Kan je eens timen hoe lang het duurt voordat een request wordt afgehandeld...
En meteen ook waarin die tijd zit? Misschien dat de situatie voor ons dan wat duidelijker wordt.
Het aantal concurrent request is ook interessant.