Discussion :

[tchize_]

parce qu'on fait un redémarrage automatique de TOMCAT chaque 15 minutes

Quel est l'intéret?? (à par éjecter les users toutes les 15 minutes). Un tomcat peut très bien fonctionner pendant des mois sans aucun soucis.

[OButterlin]

Personnellement, je ne pense pas que Tomcat soit pour quoi que ce soit dans la lenteur, je parierais que le problème vient de ton code...

Peux-tu montrer le code de l'appel de l'édition ?

Les données sont générées à l'appel ou c'est jasper qui créé la connexion et exécute la requête ?

Dans tous les cas, 5 minutes d'usage, c'est 'achement court

[JauB]

Je ne pense pas que le problème vient du code, en tout cas voici la fonction qui fait l'édition :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
public String processActionViewReport() throws KernelException,
            QlorException, JRException, IOException, SecurityException,
            NoSuchMethodException {
 
 
        try {
 
        // try{
        reportPanel.setRendered(true);
        HtmlInputHidden reportIdHidden = (HtmlInputHidden) titledPanel
                .findComponent("reportId");
 
        Map params = new HashMap();
 
        fillMapWithRequest(params);
        params.putAll(getPanelParameters(componentsPanel));
 
        String reportId = (String) reportIdHidden.getValue();
        File file = (File) Kernel.getObject("reporting/reportsDir");
 
        ConnectionProvider connectionProvider = ((QlorServer) Kernel
                .getObject("dalService/server")).getConnectionProvider();
        Connection connection = connectionProvider.newConnection(true);
 
        JasperPrint jasperPrint = JasperFillManager.fillReport(
                new FileInputStream(new File(file, reportId + ".jasper")),
                params, connection);
 
        getSessionMap().put(Constants.SESPARAM_JASPER_PRINT, jasperPrint);
 
        byte[] bytes = JasperExportManager.exportReportToPdf(jasperPrint);
        FacesContext context = FacesContext.getCurrentInstance();
        HttpServletResponse response = (HttpServletResponse) context
                .getExternalContext().getResponse();
        response.setContentLength(bytes.length);
        response.getOutputStream().write(bytes);
        response.setContentType("application/pdf");
        context.responseComplete();
        connectionProvider.releaseConnection(connection);
        return null;
        } catch (Exception e) {
            // insertion report non abouti
        }
        return null;
 
    }

Il ne faut pas oublier les requêtes SQL qui sont dans les fichiers Jasper qui peuvent être gourmande en exécution.

Personnellement, je ne pense pas que Tomcat soit pour quoi que ce soit dans la lenteur, je parierais que le problème vient de ton code...

Peux-tu montrer le code de l'appel de l'édition ?

Les données sont générées à l'appel ou c'est jasper qui créé la connexion et exécute la requête ?

Dans tous les cas, 5 minutes d'usage, c'est 'achement court

[JauB]

Le fait de redémarrer TOMCAT au bout d'un certain moment nous a montré que les éditions peuvent aller plus vite, enfin c'est ça le problème d'origine pour moi (cf l'objet de ce poste )

Quel est l'intéret?? (à par éjecter les users toutes les 15 minutes). Un tomcat peut très bien fonctionner pendant des mois sans aucun soucis.

[tchize_]

je vois deux choses qui me font sauter au plafond dans ce code. La première:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
catch(Exception e){
  //bloc vide
}

qui fait que, si t'as une erreur, tu ne le vois pas

Le deuxième, c'est le code libérant la connection, qui n'est pas placé dans un bloc finally (et donc n'est pas garanti d'être exécuté en cas de la sus-mentionnée exception invisible), entrainant un gros risque de connection leak.

La création d'un connection devrait toujours avoir lieu comme çà:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
connection = ....
try{
 // code utilisant connection
} finally {
  // liberer connection
}

[JauB]

non pour le try catch je vais les enlever, ya pas de raison de les laisser dans cette méthode.
Autre chose ?

[tchize_]

commence par çà, y a aussi le fait de générer le report dans un byte[] plutot que directement dans la réponse. Si t'as 200 users simultané avec chacun un pdf de 2M en byte[] je te laisse faire les calculs d'occupation mémoire

[OButterlin]

Il y a au moins 2 problèmes :

- le problème de la libération de la connexion (comme te l'a dit tchize_)
- la mémoire utilisée (dans la session à priori si la méthode getSessionMap().put(Constants.SESPARAM_JASPER_PRINT, jasperPrint); utilise bien la session pour enregistrer)

Peux-tu préciser le fonctionnement à ce sujet ?

[JauB]

Il y a au moins 2 problèmes :

- le problème de la libération de la connexion (comme te l'a dit tchize_)
- la mémoire utilisée (dans la session à priori si la méthode getSessionMap().put(Constants.SESPARAM_JASPER_PRINT, jasperPrint); utilise bien la session pour enregistrer)

Peux-tu préciser le fonctionnement à ce sujet ?

Normalement l'utilisateur lorsqu'il visualise l'état, ce denrier s'affiche en format PDF, mais il peut l'exporter vers EXCEL. Si on fait pas de sauvegarde du jasperPrint dans une session alors lorsqu'il va cliquer sur Exporter vers Excel on doit faire le même traitement déjà fait pour le PDF, ce qui risque d'alourdir encore les temps d'exécution.

[JauB]

commence par çà, y a aussi le fait de générer le report dans un byte[] plutot que directement dans la réponse. Si t'as 200 users simultané avec chacun un pdf de 2M en byte[] je te laisse faire les calculs d'occupation mémoire

Oui t'as raison pour le byte[], je fais le changement tout de suite

[tchize_]

la variable JasperPrint est-elle sérialisable? Car en J2EE, tout ce qui est dans la session doit être sérialisable. C'est d'autant plus vrai si tu veux préserver les session de tes users quand tu tue ton tomcat toutes les 15 minutes!

[JauB]

la variable JasperPrint est-elle sérialisable? Car en J2EE, tout ce qui est dans la session doit être sérialisable. C'est d'autant plus vrai si tu veux préserver les session de tes users quand tu tue ton tomcat toutes les 15 minutes!

Cette variable est declarée de cette façon :
JasperPrint jasperPrint = JasperFillManager.fillReport(
new FileInputStream(new File(file, reportId + ".jasper")),
params, connection);
Donc c'est pas sérializable à ce que je sache non?
pour la récupére rlors d'un export EXCEL je fais ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
JasperPrint jasperPrint = 
(JasperPrint)request.getSession().getAttribute(
                    Constants.SESPARAM_JASPER_PRINT);

Alors?

[OButterlin]

Normalement l'utilisateur lorsqu'il visualise l'état, ce denrier s'affiche en format PDF, mais il peut l'exporter vers EXCEL. Si on fait pas de sauvegarde du jasperPrint dans une session alors lorsqu'il va cliquer sur Exporter vers Excel on doit faire le même traitement déjà fait pour le PDF, ce qui risque d'alourdir encore les temps d'exécution.

Moi je garderais une référence en session vers un répertoire du serveur qui contiendrait l'objet pdf, sinon, attention au swap

[tchize_]

Oui, ou je recréerais simplement le report à chaque demande. Faut pas perdre de vue que tu stocke ce truc dans la session utilisateur, qui reste en mémoire un bon bout de temps. Faut essayer de garder sa session utilisateur la plus clean possible

[JauB]

Oui, ou je recréerais simplement le report à chaque demande. Faut pas perdre de vue que tu stocke ce truc dans la session utilisateur, qui reste en mémoire un bon bout de temps. Faut essayer de garder sa session utilisateur la plus clean possible

Une fois l'export vers EXCEL est fait, la session est vidée.
En effet, dans la méthode d'export vers Excel on ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

request.getSession().removeAttribute(Constants.SESPARAM_JASPER_PRINT);

Donc pas de problème dans ce côté.
Mais là je vois qu'on a un peu dérivé du problème initial qu'est une lenteur dans les éditions

[tchize_]

je pense pas qu'on aie vraiment dérivé, si tu bourre les session de gros truc, ca ralentit aussi, car le GC doit travailler comme un malade. Je connais pas ton buisness, donc si ca tombe ce choix est admissible, si on admet que tout utilisateur demandant le pdf demandera systématiquement aussi le excel


Mais dans ce cas, pourquoi ne pas générer les deux d'un coup sur le disque et garder des réfs à ces chemins dans la session?

[JauB]

je pense pas qu'on aie vraiment dérivé, si tu bourre les session de gros truc, ca ralentit aussi, car le GC doit travailler comme un malade. Je connais pas ton buisness, donc si ca tombe ce choix est admissible, si on admet que tout utilisateur demandant le pdf demandera systématiquement aussi le excel


Mais dans ce cas, pourquoi ne pas générer les deux d'un coup sur le disque et garder des réfs à ces chemins dans la session?

Non il y a des états qui ne nécessitent pas d'export vers Excel, je vais les lister et faire en sotre que le lien d'export ne s'affiche que si c'est nécessaire, et par conséquent ne remplir la session que si nécessaire aussi