L'analyse de fermeture de la Connexion Exception dans Spring/JPA/Mysql/Tomcat app

M'a récemment demandé de chercher pourquoi le système de production va parfois jusqu'à. Je voulais partager mes conclusions, puisqu'il implique une corrélation des événements à prendre une machine virtuelle java tomcat app avec JDBC questions exposées ci-dessus pour en fait le plantage de l'application. C'est en utilisant mysql comme un backend donc sans doute plus utile pour ce scénario, mais si la question a frappé sur une autre plateforme cause susceptible d'être la même.

Tout simplement par l'obtention de fermeture de la connexion n'implique pas l'application est cassé

C'est en vertu d'un graal de la demande, mais sera par rapport à l'ensemble de la JVM liées apps:

tomcat/context.xml db configuration, de l'avis de très petites db piscine et
removeAbandonedTimeout="10" vous à droite, nous voulons des choses pour casser

<Resource
 name="jdbc/TestDB"  auth="Container" type="javax.sql.DataSource"
              driverClassName="com.mysql.jdbc.Driver"
              url="jdbc:mysql://127.0.0.1:3306/test"
              username="XXXX"
              password="XXXX"
              testOnBorrow="true"
              testWhileIdle="true"
              testOnReturn="true"
              factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
              removeAbandoned="true"
              logAbandoned="true"
              removeAbandonedTimeout="10"
              maxWait="5000"
              initialSize="1"
              maxActive="2"
              maxIdle="2"
              minIdle="2"
              validationQuery="Select 1" />

Un quartz de travail qui s'exécute à chaque minute, non pas que cela importe l'application que je pense meurt sur la première tentative:

class Test2Job {
    static  triggers = {
               cron name: 'test2', cronExpression: "0 0/1 * * * ?"
        }
        def testerService
        def execute() {
        println "starting job2 ${new Date()}"
        testerService.basicTest3()

    }

}

Maintenant notre testService avec des commentaires, veuillez suivre les commentaires:

def dataSource
/**
* When using this method in quartz all the jdbc settings appear to get ignored
* the job actually completes notice huge sleep times compared to basicTest
* strange and very different behaviour.
* If I add Tester t = Tester.get(1L) and then execute below query I will get
* connection pool closed error
* @return
*/
def basicTest2() {
int i=1
while (i<21) {
def sql = new Sql(dataSource)
def query="""select id as id  from tester t
where id=:id"""
def instanceList = sql.rows(query,[id:i as Long],[timeout:90])
sleep(11000)
println "-- working on ${i}"
def sql1 = new Sql(dataSource)
sql1.executeUpdate(
"update tester t set t.name=? where t.id=?",
['aa '+i.toString()+' aa', i as Long])
i++
sleep(11000)
}
println "run ${i} completed"
}
/**
* This is described in above oddity
* so if this method is called instead you will see connection closed issues
*/
def basicTest3() {
int i=1
while (i<21) {
def t = Tester.get(i)
println "--->>>> test3 t ${t.id}"
/**
* APP CRASHER - This is vital and most important
* Without this declared lots of closed connections and app is working
* absolutely fine,
* The test was originally based on execRun() which returns 6650 records or something
* This test query is returned in time and does not appear to crash app
*
* The moment this method is called and please check what it is currently doing. It is simply
* running a huge query which go beyond the time out values and as explained in previous emails MYSQL states
*
* The app is then non responsive and logs clearly show application is broke 
*/
execRun2()
def sql1 = new Sql(dataSource)
sleep(10000)
sql1.executeUpdate("update tester t set t.name=? where t.id=?",['aa '+i.toString()+' aa', t.id])
sleep(10000)
i++
}
}
def execRun2() {
def query="""select new map (t as tester) from Tester t left join t.children c
left join t.children c
left join c.childrena childrena
left join childrena.childrenb childrenb
left join childrenb.childrenc childrenc , Tester t2 left join t2.children c2 left join t2.children c2
left join c2.childrena children2a
left join children2a.childrenb children2b
left join children2b.childrenc children2c
where ((c.name like (:name) or
childrena.name like (:name) or
childrenb.name like (:name) or (childrenc is null or childrenc.name like (:name))) or
(
c2.name like (:name) or
children2a.name like (:name) or
children2b.name like (:name) or (children2c is null or children2c.name like (:name))
))
"""
//println "query $query"
def results = Tester.executeQuery(query,[name:'aa'+'%'],[timeout:90])
println "Records: ${results.size()}"
return results
}
/**
* This is no different to basicTest2 and yet
* this throws a connection closed error and notice it is 20 not 20000
* quite instantly a connection closed error is thrown when a .get is used vs
* sql = new Sql(..) is a manuall connection
*
*/
def basicTest() {
int i=1
while (i<21) {
def t = Tester.get(i)
println "--- t ${t.id}"
sleep(20)
//println "publishing event ${event}"
//new Thread({
//   def event=new PurchaseOrderPaymentEvent(t,t.id)
//   publishEvent(event)
//} as Runnable ).start()
i++
}
}

C'est seulement lorsque la requête puis prend plus de temps que prévu du temps, mais il y a un autre élément, la requête elle-même, puis a frappé assis sur MYSQL, même si il est tué. MYSQL est-il manger à l'écart de traitement.

Je pense que ce qui se passe est

job 1 - hits app -> hits mysql ->    (9/10 left)
{timeout} -> app killed  -> mysql running (9/10)
job 2 - hits app -> hits mysql ->    (8/10 left)
{timeout} -> app killed  -> mysql running (8/10) 
.....
job 10 - hits app -> hits mysql ->    (10/10 left)
{timeout} -> app killed  -> mysql running (10/10)
job 11 - hits app -> 

Si par ce temps tâche1 n'a pas achevé puis nous n'avons plus rien dans la piscine bien app est tout simplement cassé maintenant.. jdbc erreurs jeté etc.. jamais l'esprit si elle se termine après le crash..

Vous pouvez surveiller ce qui se passe par la vérification de mysql
Il est apparu à courir pour une plus longue période qui va à l'encontre de ce qu'ils ont suggéré cette valeur doit être fait, mais là encore peut-être que ce n'est pas vraiment basé sur tout cela, et se rapporte à un problème ailleurs.

Alors que les tests remarqué qu'il y a deux états: l'Envoi des données /de l'Envoi au client:

|  92 | root | localhost:58462 | test | Query   |   80 | Sending data      | select tester0_.id as col_0_0_ from tester tester0_ left outer join tester_childa children1_ on test |
|  95 | root | localhost:58468 | test | Query   |  207 | Sending to client | select tester0_.id as col_0_0_ from tester tester0_ left outer join tester_childa children1_ on test |
|  96 | root | localhost:58470 | test | Query   |  147 | Sending data      | select tester0_.id as col_0_0_ from tester tester0_ left outer join tester_childa children1_ on test |
|  97 | root | localhost:58472 | test | Query   |  267 | Sending data      | select tester0_.id as col_0_0_ from tester tester0_ left outer join tester_childa children1_ on test |
|  98 | root | localhost:58474 | test | Sleep   |   18 |                   | NULL                                                                                                 |
|  99 | root | localhost:58476 | test | Query   |  384 | Sending to client | select tester0_.id as col_0_0_ from tester tester0_ left outer join tester_childa children1_ on test |
| 100 | root | localhost:58478 | test | Query   |  327 | Sending data      | select tester0_.id as col_0_0_ from tester tester0_ left outer join tester_childa children1_ on test |

Sseconds plus tard:

|  91 | root | localhost:58460 | test | Query   |   67 | Sending to client | select tester0_.id as col_0_0_ from tester tester0_ left outer join tester_childa children1_ on test |
|  92 | root | localhost:58462 | test | Query   |  148 | Sending to client | select tester0_.id as col_0_0_ from tester tester0_ left outer join tester_childa children1_ on test |
|  97 | root | localhost:58472 | test | Query   |  335 | Sending to client | select tester0_.id as col_0_0_ from tester tester0_ left outer join tester_childa children1_ on test | |
| 100 | root | localhost:58478 | test | Query   |  395 | Sending to client | select tester0_.id as col_0_0_ from tester tester0_ left outer join tester_childa children1_ on test |
Seconds after that: (all dead)
|  58 | root | localhost       | NULL | Query   |    0 | starting | show processlist |
|  93 | root | localhost:58464 | test | Sleep   |  167 |          | NULL             |
|  94 | root | localhost:58466 | test | Sleep   |  238 |          | NULL             |
|  98 | root | localhost:58474 | test | Sleep   |   74 |          | NULL             |
| 101 | root | localhost:58498 | test | Sleep   |   52 |          | NULL             |

Il se peut qu'un script doit être créé pour surveiller la liste des processus et peut-être un approfondissement de l'ensemble de résultats contenant des requêtes exactes de course de travailler vos requêtes événements est en train de tuer votre application

OriginalL'auteur Vahid