[Java] Génération XLS avec Jasper : OutOfMemoryError

[lr]

Salut,

J'ai une application qui génère des rapports PDF, XLS etc avec Jasper Reports.

Le volume des données augmente et j'ai commencé a avoir des OutOfMemoryErrors. J'ai alors trouvé ça qui semblait être la solution et j'ai essayé de la mettre en oeuvre.

Il me semble que tout est correct mais pourtant le problème persiste. En fait j'ai l 'impression que les Virtualizer ne sont pas utilités.

Est-ce que qqun a utilisé avec succès les virtualizer ? Pouvez-vous me dire ce qui cloche dans le code ci-dessous ?

La génération du document XLS plante dans "exportReport". J'utilise jasperreports-1.3.2.jar mais le résultat est le même avec la version 1.3.3.

Merci d'avance pour toute aide
Lilian

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
JRFileVirtualizer virtualizer = new JRFileVirtualizer( 2, Configuration.getParameter("report.virtualizer.physical.temp.path") );
parameters.put( JRParameter.REPORT_VIRTUALIZER, virtualizer );
 
DataSource dataSource = new DataSource( parameters, jasperReport.getQuery().getText(), connection );
 
JasperPrint jasperPrint = JasperFillManager.fillReport( jasperReport, parameters, dataSource );
//-----------------------------------------------------
 
JRXlsExporter exporterXLS = new JRXlsExporter();
exporterXLS.setParameter( JRXlsExporterParameter.JASPER_PRINT, jasperPrint );
//exporterXLS.setParameter( JRXlsExporterParameter.OUTPUT_STREAM, output );
exporterXLS.setParameter( JRXlsExporterParameter.OUTPUT_FILE_NAME, PDFReportCreator.BASE_PATH_FOR_PDF + report.getPdfFilePath() );
exporterXLS.setParameter( JRXlsExporterParameter.IS_ONE_PAGE_PER_SHEET, Boolean.TRUE );
exporterXLS.setParameter( JRXlsExporterParameter.IS_AUTO_DETECT_CELL_TYPE, Boolean.FALSE );
exporterXLS.setParameter( JRXlsExporterParameter.IS_WHITE_PAGE_BACKGROUND, Boolean.FALSE );
exporterXLS.setParameter( JRXlsExporterParameter.IS_REMOVE_EMPTY_SPACE_BETWEEN_ROWS, Boolean.TRUE );
exporterXLS.exportReport();

Code :

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
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
/**
 * 
 */
package com.dotbase.jasper.model;
 
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.Map;
import java.util.Set;
 
import net.sf.jasperreports.engine.JRDataSource;
import net.sf.jasperreports.engine.JRException;
import net.sf.jasperreports.engine.JRField;
 
/**
 * @author lrobert
 * Dataset pour la virtualisation (traîtement de gros rapports)
 */
public class DataSource implements JRDataSource
{
    private static final int MAX_RESULT_PER_PAGE = 1000;
 
    private String query;
    private Connection connection;
    private ResultSet rsReportData;
    private int currentPage = 0;
 
    public DataSource( Map<String, Object> parameters, String query, Connection connection ) throws SQLException
    {
        //exécuter la requête
        connection.setAutoCommit( false );
        PreparedStatement statement = connection.prepareStatement( query );
        statement.setFetchSize( 100 );
        this.rsReportData = Database.executeSelect( statement );
    }
 
    public Object getFieldValue( JRField jrField ) throws JRException
    {
        try
        {
            Object field = rsReportData.getObject( jrField.getName() );
            return field;
        }
        catch( SQLException e )
        {
            throw new JRException( e );
        }
    }
 
    private int iNext = 0;
    public boolean next() throws JRException
    {
        try
        {
            return rsReportData.next();
        }
        catch( SQLException e )
        {
            throw new JRException( e );
        }
    }
 
}

[CyberChouan]

Et sinon, sans aller chercher aussi compliqué, un paramètre Xmx à ta JVM ne suffirait pas à régler ton problème (si la volumétrie ne continue pas d'augmenter indéfiniment)?

[lr]

Envoyé par CyberChouan

Et sinon, sans aller chercher aussi compliqué, un paramètre Xmx à ta JVM ne suffirait pas à régler ton problème (si la volumétrie ne continue pas d'augmenter indéfiniment)?

C'est ça le problème, j'ai besoin d'avoir un truc pérenne, pas que je doive augmenter la valeur de Xmx tous les deux mois jusqu'à arriver à saturation complète...

De plus, dans l'article que j'ai cité l'auteur semble s'en sortir avec une valeur faible (10M je crois) alors que moi avec 300M ça plante :S

[natha]

Et si tu affiches le viewer et que tu fais sauvegarder en XLS, ça plante aussi ?

[tnodev]

Bonjour

ce que tu fais, m'intéresse !!!!
As-tu résolu ton problème ?

[lr]

Envoyé par tnodev

Bonjour

ce que tu fais, m'intéresse !!!!
As-tu résolu ton problème ?

Salut,

Non mais j'ai du laisser tomber pour l'instant

Tu trouveras peut-être qq éléments ici : http://www.jasperforge.org/index.php...id=26154#26154

a+

[tnodev]

j'ai fait quelques petits tests et ça marche..., très simple en plus !
Je récupère ma liste de pojo par morceau de 5000 en jouant avec le limit et le offset et Jasper les met au fur et à mesure dans des fichiers de swap.

Code :

1
2
3
4
 
        JRSwapFile swapFile = new JRSwapFile("/tmp/jr/", 2048, 2048);
        JRSwapFileVirtualizer virtualizer = new JRSwapFileVirtualizer(2, swapFile, true);        
        model.put(JRParameter.REPORT_VIRTUALIZER, virtualizer);

Tout simplement...

J'ai généré un pdf de de 12Mo contenant 2403 pages..., on doit pouvoir faire mieux