Forum Programmation.web Tomcat : Postgres/JDBC Datasource fait planter Tomcat.

Posté par  . Licence CC By‑SA.
Étiquettes :
1
11
nov.
2015

Bonjour à tous,

Bonjour à tous,

J'ai fait une petite appli web qui fonctionne. Rien de bien sorcier, on peut uploader ou downloader des images à travers un site ou une appli Android. J'utilise postgres pour la base, la gestion des requêtes vers postgres est basique, ouverture et fermeture de requête dans le code.

Mais voilà, j'ai voulu passer par une datasource, gérée par Tomcat. Je renseigne META-INF/context.xml et WEB-INF/web.xml comme il faut, enfin je l'espère :

context.xml :

<Context antiJARLocking="true" path="/Globby">
<Resource name="jdbc/GlobbyDB" auth="Container"
    type="javax.sql.DataSource" driverClassName="org.postgresql.Driver"
    url="jdbc:postgresql://127.0.0.1:5432/globby"
    username="postgres" password="gni" maxActive="500" maxIdle="20"
        factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" 
    maxWait="-1"/>
</Context>

et dans web.xml : 

    <resource-ref>
        <description>GlobbyDB</description>
        <res-ref-name>jdbc/GlobbyDB</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
    </resource-ref>

Si je charge une page avec 40 élèment, le site plante et dans les logs postgres, j'ai "sorry, too many clients already". Mais le but de Datasource/JDBC ce n'est pas justement de ne pas avoir ce cas ? De mettre les requêtes en queue ?

Merci d'avance pour vos conseils.

  • # removeAbandoned

    Posté par  . Évalué à 3.

    Arf, je cherchais depuis des heures et je ne trouve une piste qu'après avoir posté.

    En fait, dans ma ressource (dans context.xml), rien ne specifiait quand une session pouvait être "détruite", en ajoutant cela, ça supprime les sessions au bout de 10 secondes. 

            removeAbandoned="true"
        removeAbandonedTimeout="10"

    ça va un peu mieux, mais ce n'est pas parfait.

    • [^] # Re: removeAbandoned

      Posté par  . Évalué à 3.

      Sur ce site, les parametres sont bien expliqués :

      http://www.tomcatexpert.com/blog/2010/04/01/configuring-jdbc-pool-high-concurrency

      Mon context.xml est maintenant comme ci-dessous, ça à l'air presque parfait, je vais tester la monté en charge : 

      <Context antiJARLocking="true" path="/Globby">
    <!-- Read this for a great doc :
    http://www.tomcatexpert.com/blog/2010/04/01/configuring-jdbc-pool-high-concurrency -->
<Resource name="jdbc/GlobbyDB" auth="Container"
    type="javax.sql.DataSource"
        driverClassName="org.postgresql.Driver"
        factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" 
    url="jdbc:postgresql://127.0.0.1:5432/globby"
    username="postgres" password="niceTryNSA" 
        maxActive="500"
        maxIdle="30"
        removeAbandoned="true"
        removeAbandonedTimeout="10"
        abandonWhenPercentageFull="60"
    maxWait="1000"
/>
</Context>

  • # nombre de connexions

    Posté par  . Évalué à 3.

    Dans la configuration de ton datasource, tu accepte jusqu'à 500 connexions, est-ce que PostgreSQL est configuré pour en accepter également autant que ça? (par défaut, c'est 100)

    Et puis, une webapp pour laquelle tu prévois d'avoir besoin de jusqu'à 500 connexions simultanées à la DB, je n'appelle pas ça une "petite" appli.
    Tu as vraiment autant de monde que ça qui visite ton appli?

    • [^] # Re: nombre de connexions

      Posté par  . Évalué à 2.

      Oui, PostgreSQL est bien configuré pour recevoir 500 connexions.

      Et puis, une webapp pour laquelle tu prévois d'avoir besoin de jusqu'à 500 connexions simultanées à la DB

      C'est ou je pense qu'il y a un problème. Par exemple, mon appli à une page avec 60 images. Mais comme je ne veux pas que les images soient visible pour les gens non connectés/autorisés, cette simple page génère donc 66 requêtes.

      La solution que j'ai retenu c'est de faire une servlet getImage avec comme paramètre l'ID de la photo et un num de session.

      Je pensais bêtement qu'avec une ressource/JDBC les requêtes pourraient utiliser la même connexion. Et la en fait, chaque connection=datasource.getConnection() m'ouvre une connection alors que ce que je voulais était plutot que cela utilise une connection déja utiliséé.

  • # Je suis un gland...

    Posté par  . Évalué à 2.

    En réécrivant ma classe pour utiliser la resource/JDBC Tomcat, j'ai créer une fuite connection stupide. Du coup, maintenant, ça a bien le comportement attendu.

    Merci à tous !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.