java.lang.OutOfMemoryError: Java heap space [LUNGO]
Umberto Carrara
levarci le gambe e ora comincia a essere un problema (devo consegnare), in
breve ho un'applicazione che visualizza su un monitor dei pdf e dei flash
che sono serviti da una servelet, come jpa utilizzo OpenJPA 1.3.0-SNAPSHOT
e come server Tomcat 6.0, per fare l'applicazione ho usato MyFaces.
I files che vengono serviti sono generalmente all'intorno dei 500k, sotto ho
messo le impostazioni del server tomcat e come potete vedere ho settato già
i parametri per aumentare l'heap space,sotto ci sono due estratti dai logs
di tomcat dove si vede che sicuramente non ho configurato jopenjpa a dovere
e che il programma crascha sula servelet FileProvider.
Il problema è che non c'è un punto preciso dove si blocca ma lo fa random
senza alcuna regola apparente e non capisco perchè debba riempirsi lo heap
space.
se qualcuno volesse aiutarmi gli sarei enormemente grato
-Dcatalina.home=C:\Programmi\Apache Software Foundation\Tomcat 6.0
-Dcatalina.base=C:\Programmi\Apache Software Foundation\Tomcat 6.0
-Djava.endorsed.dirs=C:\Programmi\Apache Software Foundation\Tomcat
6.0\endorsed
-Djava.io.tmpdir=C:\Programmi\Apache Software Foundation\Tomcat 6.0\temp
-Xmx256m
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=C:\Programmi\Apache Software
Foundation\Tomcat 6.0\conf\logging.properties
-Xms64m
localhost.2009-02-06.log:
0 ePressPU INFO [http-8080-1] openjpa.Runtime - Starting OpenJPA
1.3.0-SNAPSHOT
0 ePressPU INFO [http-8080-1] openjpa.jdbc.JDBC - Using dictionary
class "org.apache.openjpa.jdbc.sql.PostgresDictionary".
3766 ePressPU INFO [http-8080-1] openjpa.Enhance - Creating subclass
for "[class com.webkey.epress.persistence.Documents, class
com.webkey.epress.persistence.PresentationsListPK, class
com.webkey.epress.persistence.Monitors, class
com.webkey.epress.persistence.Menus, class
com.webkey.epress.persistence.DocumentsTypes, class
com.webkey.epress.persistence.PresentationsList, class
com.webkey.epress.persistence.Presentations]". This means that your
application will be less efficient and will consume more memory than it
would if you ran the OpenJPA enhancer. Additionally, lazy loading will not
be available for one-to-one and many-to-one persistent attributes in types
using field access; they will be loaded eagerly instead.
Exception in thread "ContainerBackgroundProcessor[StandardEngine[Catalina]]"
java.lang.OutOfMemoryError: Java heap space
stdout_20090204.log:
5-feb-2009 22.37.18 org.apache.catalina.core.StandardWrapperValve invoke
GRAVE: Servlet.service() for servlet FileProvider threw exception
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Unknown Source)
at java.io.ByteArrayOutputStream.write(Unknown Source)
at java.io.DataOutputStream.writeShort(Unknown Source)
at serp.bytecode.Code.write(Code.java:2045)
at serp.bytecode.Attributes.writeAttributes(Attributes.java:171)
at serp.bytecode.BCMember.write(BCMember.java:372)
at serp.bytecode.BCClass.write(BCClass.java:237)
at serp.bytecode.BCClass.toByteArray(BCClass.java:250)
at serp.bytecode.BCClassLoader.findClass(BCClassLoader.java:46)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at
org.apache.openjpa.util.GeneratedClasses.loadBCClass(GeneratedClasses.java:67)
at
org.apache.openjpa.enhance.ManagedClassSubclasser.write(ManagedClassSubclasser.java:265)
at org.apache.openjpa.enhance.ManagedClassSubclasser.access$00
(ManagedClassSubclasser.java:55)
at
org.apache.openjpa.enhance.ManagedClassSubclasser$1.write(ManagedClassSubclasser.java:125)
at org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:592)
at org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:580)
at
org.apache.openjpa.enhance.ManagedClassSubclasser.prepareUnenhancedClasses(ManagedClassSubclasser.java:147)
at
org.apache.openjpa.kernel.AbstractBrokerFactory.loadPersistentTypes(AbstractBrokerFactory.java:317)
at
org.apache.openjpa.kernel.AbstractBrokerFactory.initializeBroker(AbstractBrokerFactory.java:235)
at
org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:197)
at
org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:142)
at
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:192)
at
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:145)
at
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:56)
at com.webkey.epress.servlet.FileProvider.doGet(FileProvider.java:55)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
5-feb-2009 22.37.54 org.apache.catalina.core.StandardWrapperValve invoke
GRAVE: Servlet.service() for servlet FileProvider threw exception
FileProvider.java:
try {
is = new FileInputStream(doc.getUrl());
response.setContentType(doc.getIdDocumentsTypes().getMime());
out = response.getOutputStream();
byte[] buf = new byte[1024];
int len;
while ((len = is.read(buf)) > 0) {
out.write(buf, 0, len);
}
out.flush();
} catch (Exception e) {
e.printStackTrace();
}finally{
out.close();
is.close();
}
Umberto
Pablo Xon
> -Xmx256m
> -Xms64m
Mi sembrano valori decisamente bassi: partire da 64Mb e mettere come
limite 256Mb mi sembra rischioso.
Ora sul mio pc ho un tomcat mono-applicazione che gira "senza nulla
fare" e occupa oltre 300Mb (solo le librerie che vengono caricate allo
startup ne occupano circa 120).
Prova a quadruplicare i valori e tieni monitorato l'uso della memoria.
> com.webkey.epress.persistence.Presentations]". This means that your
> application will be less efficient and will consume more memory than it
> would if you ran the OpenJPA enhancer.
Quel "more memory" mi sembra sospetto...
> at java.io.ByteArrayOutputStream.write(Unknown Source)
Anche se l'errore si verifica in momenti diversi il metodo incriminato è
sempre questo (write)?
> FileProvider.java: [...]
Ad occhio il codice mi sembra corretto, IMHO è un problema di parametri
di startup.
Umberto Carrara
intanto grazie della risposta
> Umberto Carrara ha scritto:
>> -Xmx256m
>> -Xms64m
>
> Mi sembrano valori decisamente bassi: partire da 64Mb e mettere come
> limite 256Mb mi sembra rischioso.
> Ora sul mio pc ho un tomcat mono-applicazione che gira "senza nulla
> fare" e occupa oltre 300Mb (solo le librerie che vengono caricate allo
> startup ne occupano circa 120).
> Prova a quadruplicare i valori e tieni monitorato l'uso della memoria.
ok ho alsato il valore e per adesso non si blocca
>
>> com.webkey.epress.persistence.Presentations]". This means that your
>> application will be less efficient and will consume more memory than it
>> would if you ran the OpenJPA enhancer.
>
> Quel "more memory" mi sembra sospetto...
>
>> at java.io.ByteArrayOutputStream.write(Unknown Source)
>
> Anche se l'errore si verifica in momenti diversi il metodo incriminato è
> sempre questo (write)?
>
>> FileProvider.java: [...]
>
> Ad occhio il codice mi sembra corretto, IMHO è un problema di parametri
> di startup.
il fatto è che ho l'impressione che si riempia fino ad esaurirsi quindi
aumentare l'heap space avrebbe il solo effetto di allontanare il momento
del crash, non mi spiego perche non si ferma subito, comunque le mie sono
illazioni dato che non conosco bene la materia e comunque ora vediamo che
fa, poi semmai se ne riparla
Grazie ancora
Umberto
Pablo Xon
> il fatto è che ho l'impressione che si riempia fino ad esaurirsi quindi
> aumentare l'heap space avrebbe il solo effetto di allontanare il momento
In questo caso però il crash tenderebbe a verificarsi _più o meno_
sempre nello stesso punto, mentre in fatto che avvenga in momenti random
personalmente mi fa propendere per l'altra ipotesi.
Ma le mie sono, appunto, solo ipotesi, non potendo verificare
direttamente l'uso della memoria.
> comunque ora vediamo che fa, poi semmai se ne riparla
Puoi provare a fare delle verifiche usando degli metodi specifici, ad
esempio con il parametro "-verbose:gc" oppure verificando direttamente
via codice cosa avviene in memoria alla chiamata del GC (es.
java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html paragrafo 5.2.3).
O male che vada verificando con il TaskManager o con strumenti più
adeguati (vedo dai log che usi windows e su questo posso aiutarti poco) .
Ciao.
Umberto Carrara
> In questo caso però il crash tenderebbe a verificarsi _più o meno_
> sempre nello stesso punto, mentre in fatto che avvenga in momenti random
> personalmente mi fa propendere per l'altra ipotesi.
> Ma le mie sono, appunto, solo ipotesi, non potendo verificare
> direttamente l'uso della memoria.
>
da quello che dici mi sembra che questo messaggio che mi da OpenJPA possa
entrarci in qualche modo
>>3766 ePressPU INFO [http-8080-1] openjpa.Enhance - Creating subclass
>>for.......
>>..."This means that your
>>application will be less efficient and will consume more memory than it
>>would if you ran the OpenJPA enhancer. Additionally, lazy loading will not
>>be available for one-to-one and many-to-one persistent attributes in types
>>using field access; they will be loaded eagerly instead"
hai mica qualche info da darmi a riguardo? credo di aver capito che
l'OpenJPA enhancer è un sistema per cui si attaccano dei metodi al volo
alle entità ma non sono riscito a caire se è importante o meno
>> comunque ora vediamo che fa, poi semmai se ne riparla
>
> Puoi provare a fare delle verifiche usando degli metodi specifici, ad
> esempio con il parametro "-verbose:gc" oppure verificando direttamente
> via codice cosa avviene in memoria alla chiamata del GC (es.
> java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html paragrafo 5.2.3).
questa mi sembra una buona idea ora mi leggo il tomo
> O male che vada verificando con il TaskManager o con strumenti più
> adeguati (vedo dai log che usi windows e su questo posso aiutarti poco) .
lasciamo stare.....tuuta colpa dell'uscita video secondaria che non andava e
neanche la primaria...
>
> Ciao.
Ciao e Grazie ancora
Umberto
Umberto Carrara
>>>..."This means that your
>>>application will be less efficient and will consume more memory than it
>>>would if you ran the OpenJPA enhancer. Additionally, lazy loading will
>>>not be available for one-to-one and many-to-one persistent attributes in
>>>types using field access; they will be loaded eagerly instead"
>
> hai mica qualche info da darmi a riguardo? credo di aver capito che
> l'OpenJPA enhancer è un sistema per cui si attaccano dei metodi al volo
> alle entità ma non sono riscito a caire se è importante o meno
>
si è bloccato di nuovo, più tardi ma si è bloccato
Umberto
Pablo Xon
> si è bloccato di nuovo, più tardi ma si è bloccato
Hai provato / sei riuscito a fare delle verifiche sull'occupazione di
memoria?
Oltre hai metodi (forse complessi) che ti ho suggerito nel precedente
post puoi usare i più "diretti" metodi di Runtime:
Runtime.getRuntime().totalMemory();
Runtime.getRuntime().freeMemory();
per effettuare un log a livello di codice.
Umberto Carrara
si sono riuscito a riproporre l'errore anche su linux e adesso si presenta
molto presto, si parte da
Fri Feb 13 10:17:39 CET 2009
total - 746127360
free - 46463256
used - 699664104
e in circa mezzora si arriva a
Fri Feb 13 10:23:07 CET 2009
total - 750845952
free - 13648952
used - 737202336
di quì si rallenta paurosamente tomcata non risponde più e esce
java.lang.OutOfMemoryError: Java heap space , la servlet è questa, l'ho
modificata rispetto alla precedente
is = new FileInputStream(doc.getUrl());
bis = new BufferedInputStream(is);
try {
response.setContentType(doc.getIdDocumentsTypes().getMime());
out = response.getOutputStream();
bos = new BufferedOutputStream(out);
byte[] buff = new byte[2048*2];
int bytesRead;
while (-1 != (bytesRead = bis.read(buff, 0, buff.length))) {
bos.write(buff, 0, bytesRead);
}
} catch (Exception e) {
e.printStackTrace();
} finally {
if (bos!=null) {
bos.close();
}
if (bis!=null) {
bis.close();
}
}
in caso non fosse chiaro spiego che fa questa servlet:
viene chiamata da ina pagina html ( creata anc'essa da un'altra servlet ) in
questo modo:
<iframe onload="setTimeout('window.opener.location.reload()',10);"
src="/ePress/FileProvider?idDocument=25" >
</iframe>
e può fornire diversi tipi di file html, pdf , immagine, doc, xls etc
e naturalmente si rinfresca e cambia file a tempo, una presentazione di
documenti eterogenei insomma
birra virtuale e se passate di quì anche reali, a chi mi da una dritta, sono
alla frutta
Umberto
watanabe
>
> is = new FileInputStream(doc.getUrl());
> bis = new BufferedInputStream(is);
> try {
> response.setContentType(doc.getIdDocumentsTypes().getMime());
>
> out = response.getOutputStream();
> bos = new BufferedOutputStream(out);
>
> byte[] buff = new byte[2048*2];
> int bytesRead;
>
> while (-1 != (bytesRead = bis.read(buff, 0, buff.length))) {
> bos.write(buff, 0, bytesRead);
> }
>
> } catch (Exception e) {
> e.printStackTrace();
> } finally {
> if (bos!=null) {
> bos.close();
> }
> if (bis!=null) {
> bis.close();
> }
> }
>
prova a portare:
byte[] buff = new byte[2048*2];
int bytesRead;
prima del try .... in modo da creare buffer e contatore una sola volta e
non ad ogni esecuzione della servlet.
Poi chiudi anche is, non se la chiusura di bis basti, se dovesse
rimanere aperte, occuperebbe parecchio.
ciao.
watanabe
>
> is = new FileInputStream(doc.getUrl());
> bis = new BufferedInputStream(is);
> try {
> response.setContentType(doc.getIdDocumentsTypes().getMime());
>
> out = response.getOutputStream();
> bos = new BufferedOutputStream(out);
>
> byte[] buff = new byte[2048*2];
> int bytesRead;
>
> while (-1 != (bytesRead = bis.read(buff, 0, buff.length))) {
> bos.write(buff, 0, bytesRead);
> }
>
> } catch (Exception e) {
> e.printStackTrace();
> } finally {
> if (bos!=null) {
> bos.close();
> }
> if (bis!=null) {
> bis.close();
> }
> }
>
Prova a porre buff=null quando rilasci le altre risorse nel finally...
Poi chiudi anche "is", non se la chiusura di "bis" basti, se dovesse
rimanere aperto, occuperebbe parecchio.
Prova a chiamare esplicitamente il garbage colletor System.gc(), se non
sbaglio, alla fine della servlet e vedi che succede, ma non dovrebbe
essere necessario.
ciao.
Umberto Carrara
>
> Prova a porre buff=null quando rilasci le altre risorse nel finally...
>
> Poi chiudi anche "is", non se la chiusura di "bis" basti, se dovesse
> rimanere aperto, occuperebbe parecchio.
>
> Prova a chiamare esplicitamente il garbage colletor System.gc(), se non
> sbaglio, alla fine della servlet e vedi che succede, ma non dovrebbe
> essere necessario.
>
> ciao.
ho fatto come hai detto e la cosa è peggiorata....non che sia un male eh?!
continua a riempire l'heap space, per prova ho fatto una app di test con una
pagina html che ogni 10 secondi richiama una servlet che fornisce un pdf in
stream come il codice che ho postato prima e questa è ok, allora deduco che
il problema è OpenJPA che è l'altra componente del sistem in oggetto se c'è
qualcuno che ha esperienza in merito si faccia avanti per favore.
ora si ferma con questo errore
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0635d400, pid=8828, tid=2146773904
#
# Java VM: Java HotSpot(TM) Server VM (11.0-b16 mixed mode linux-x86)
# Problematic frame:
# V [libjvm.so+0x35d400]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
questa è l'intestazione del file che scrive dopo il crash poi ci sono tutte
le info per il debug che non sto a inviare
qualcuno sa spiegarmi cosa significa questo?
non credo di aver compreso bene a questo punto e non so se è un problema o
meno
ePressPU INFO [http-8080-4] openjpa.Enhance - Creating subclass
for "[class com.webkey.epress.persistence.Documents, class
com.webkey.epress.persistence.PresentationsListPK, class
com.webkey.epress.persistence.Monitors, class
com.webkey.epress.persistence.Menus, class
com.webkey.epress.persistence.DocumentsTypes, class
com.webkey.epress.persistence.PresentationsList, class
com.webkey.epress.persistence.Presentations]". This means that your
application will be less efficient and will consume more memory than it
would if you ran the OpenJPA enhancer. Additionally, lazy loading will not
be available for one-to-one and many-to-one persistent attributes in types
using field access; they will be loaded eagerly instead.
306
in rete ho trovato alcune info in cui si proponeva di lanciare
l'openjpa.Enhance a build time con ant cosa che ho fatto puntualmnte ma che
non ha sortito nessun risultato a seguito il mio persistence.xml
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="ePressPU">
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<class>com.webkey.epress.persistence.PresentationsListPK</class>
<class>com.webkey.epress.persistence.PresentationsList</class>
<class>com.webkey.epress.persistence.Presentations</class>
<class>com.webkey.epress.persistence.Monitors</class>
<class>com.webkey.epress.persistence.Menus</class>
<class>com.webkey.epress.persistence.DocumentsTypes</class>
<class>com.webkey.epress.persistence.Documents</class>
<exclude-unlisted-classes>true</exclude-unlisted-classes>
<properties>
<property name="openjpa.ConnectionDriverName"
value="org.postgresql.Driver" />
<property name="openjpa.ConnectionURL"
value="jdbc:postgresql://localhost:5432/epress" />
<property name="openjpa.ConnectionUserName" value="epress" />
<property name="openjpa.ConnectionPassword" value="epress" />
<property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema" />
</properties>
</persistence-unit>
</persistence>
grazie
Umberto Carrara
così sembra dal log, per lo stesso file
Umberto
watanabe
> watanabe wrote:
>
>
>> Prova a porre buff=null quando rilasci le altre risorse nel finally...
>>
>> Poi chiudi anche "is", non se la chiusura di "bis" basti, se dovesse
>> rimanere aperto, occuperebbe parecchio.
>>
>> Prova a chiamare esplicitamente il garbage colletor System.gc(), se non
>> sbaglio, alla fine della servlet e vedi che succede, ma non dovrebbe
>> essere necessario.
>>
Con quale delle tre è peggiorata (penso la terza, le prime due al
massimo sono innoque)?
> per prova ho fatto una app di test con una pagina html che ogni 10 secondi richiama una servlet che fornisce un pdf in
> stream come il codice che ho postato prima e questa è ok, allora deduco che
> il problema è OpenJPA.
In effetti la tua servlet è corretta, il 99% delle persone l'avrebbe
scritta così, inoltre vari evolte mi sono trovato in casi simili e non
ho mai avuto problemi, quindi credo si tratterà di un bug ma spiegami
una cosa, nel "servire" il file JPA dove entra in gioco? il path del
file sta in un db? insomma nella servlet c'e' anche una chiamata JPA?
Puoi fare due prove:
1) scrivi una servlet che fa una chiamata jpa tipo una query e
restituisce solo una frase tipo "ciao", chiamala un numero considerevole
di volte e vedi se si presenta il problema, e a qual punto il problema
è sicuramente JPA.
2) l'app di test che hai fatto e funzionava, usava JPA? o JPA non era
nelle librerie e neanche veniva usato? metti la tua servlet di test
nell'applicazione originale che ti da errore e vedi che succede.
ciao
Umberto Carrara
> Con quale delle tre è peggiorata (penso la terza, le prime due al
> massimo sono innoque)?
non saprei le ho fatte tutte contemporaneamente
>
>
>> per prova ho fatto una app di test con una pagina html che ogni 10
>> secondi richiama una servlet che fornisce un pdf in stream come il
>> codice che ho postato prima e questa è ok, allora deduco che il problema
>> è OpenJPA.
>
> In effetti la tua servlet è corretta, il 99% delle persone l'avrebbe
> scritta così, inoltre vari evolte mi sono trovato in casi simili e non
> ho mai avuto problemi, quindi credo si tratterà di un bug ma spiegami
> una cosa, nel "servire" il file JPA dove entra in gioco? il path del
> file sta in un db? insomma nella servlet c'e' anche una chiamata JPA?
sono due servlet che lavorano in sincronismo la prima mediante alcune
variabili di sessione interroga le jpa per sapere quale documeto deve
essere visualizzato e genera una pagina html di questo tipo
<body>
<iframe src="/ePress/FileProvider?docId=12"></iframe>
</body>
la seconda è quel FilePrivider che riceve l'id del documento, interroga le
jpa recupera il path, il documento è sul disco, e fornisce il file
impostando anche il mime type giusto
>
> Puoi fare due prove:
>
> 1) scrivi una servlet che fa una chiamata jpa tipo una query e
> restituisce solo una frase tipo "ciao", chiamala un numero considerevole
> di volte e vedi se si presenta il problema, e a qual punto il problema
> è sicuramente JPA.
mi sembra un buona idea
>
> 2) l'app di test che hai fatto e funzionava, usava JPA? o JPA non era
> nelle librerie e neanche veniva usato?
la seconda che hai detto JPA non c'era
> metti la tua servlet di test
> nell'applicazione originale che ti da errore e vedi che succede.
>
>
provo
> ciao
ciao e grazie
Umberto Carrara
> watanabe wrote:
>> Puoi fare due prove:
>>
>> 1) scrivi una servlet che fa una chiamata jpa tipo una query e
>> restituisce solo una frase tipo "ciao", chiamala un numero considerevole
>> di volte e vedi se si presenta il problema, e a qual punto il problema
>> è sicuramente JPA.
> mi sembra un buona idea
>
Mon Feb 16 12:59:20 CET 2009
************************START*************************
total - 770572288 free - 25464200 used - 745108088
0 ePressPU INFO [http-8080-2] openjpa.Runtime - Starting OpenJPA 1.2.0
1 ePressPU INFO [http-8080-2] openjpa.jdbc.JDBC - Using dictionary
class "org.apache.openjpa.jdbc.sql.PostgresDictionary".
18992 ePressPU INFO [http-8080-2] openjpa.Enhance - Creating subclass
for "[class com.webkey.epress.persistence.Documents, class
com.webkey.epress.persistence.PresentationsListPK, class
com.webkey.epress.persistence.Monitors, class
com.webkey.epress.persistence.Menus, class
com.webkey.epress.persistence.DocumentsTypes, class
com.webkey.epress.persistence.PresentationsList, class
com.webkey.epress.persistence.Presentations]". This means that your
application will be less efficient and will consume more memory than it
would if you ran the OpenJPA enhancer. Additionally, lazy loading will not
be available for one-to-one and many-to-one persistent attributes in types
using field access; they will be loaded eagerly instead.
Feb 16, 2009 1:06:31 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet TestJpa threw exception
java.lang.OutOfMemoryError: Java heap space
at java.nio.HeapByteBuffer.<init>(Unknown Source)
at java.nio.ByteBuffer.allocate(Unknown Source)
at sun.nio.cs.StreamEncoder.<init>(Unknown Source)
at sun.nio.cs.StreamEncoder.<init>(Unknown Source)
at sun.nio.cs.StreamEncoder.forOutputStreamWriter(Unknown Source)
at java.io.OutputStreamWriter.<init>(Unknown Source)
at org.postgresql.core.Encoding.getEncodingWriter(Encoding.java:235)
at org.postgresql.core.PGStream.setEncoding(PGStream.java:139)
at org.postgresql.core.PGStream.<init>(PGStream.java:60)
at
org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:77)
at
org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66)
at
org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125)
at
org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30)
at
org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:18)
at org.postgresql.jdbc4.Jdbc4Connection.<init>(Jdbc4Connection.java:24)
at org.postgresql.Driver.makeConnection(Driver.java:382)
at org.postgresql.Driver.connect(Driver.java:260)
at
org.apache.openjpa.jdbc.schema.SimpleDriverDataSource.getConnection(SimpleDriverDataSource.java:81)
at
org.apache.openjpa.jdbc.schema.SimpleDriverDataSource.getConnection(SimpleDriverDataSource.java:76)
at
org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:113)
at
org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:93)
at
org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:113)
at
org.apache.openjpa.jdbc.schema.DataSourceFactory$DefaultsDataSource.getConnection(DataSourceFactory.java:305)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connectInternal(JDBCStoreManager.java:879)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connect(JDBCStoreManager.java:864)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.getConnection(JDBCStoreManager.java:229)
at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:371)
at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:339)
at
org.apache.openjpa.jdbc.sql.LogicalUnion$UnionSelect.execute(LogicalUnion.java:420)
at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:230)
at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:220)
at org.apache.openjpa.jdbc.sql.LogicalUnion.execute(LogicalUnion.java:206)
Feb 16, 2009 1:36:08 PM org.apache.catalina.connector.CoyoteAdapter service
SEVERE: An exception or error occurred in the container during the request
processing
java.lang.OutOfMemoryError: Java heap space
at java.util.LinkedHashMap.createEntry(Unknown Source)
at java.util.LinkedHashMap.addEntry(Unknown Source)
at java.util.HashMap.put(Unknown Source)
at sun.util.resources.OpenListResourceBundle.loadLookup(Unknown Source)
at
sun.util.resources.OpenListResourceBundle.loadLookupTablesIfNecessary(Unknown
Source)
at sun.util.resources.OpenListResourceBundle.handleGetObject(Unknown
Source)
at sun.util.resources.TimeZoneNamesBundle.handleGetObject(Unknown Source)
at java.util.ResourceBundle.getObject(Unknown Source)
at java.util.ResourceBundle.getObject(Unknown Source)
at java.util.ResourceBundle.getStringArray(Unknown Source)
at sun.util.TimeZoneNameUtility.retrieveDisplayNames(Unknown Source)
at sun.util.TimeZoneNameUtility.retrieveDisplayNames(Unknown Source)
at java.util.TimeZone.getDisplayNames(Unknown Source)
at java.util.TimeZone.getDisplayName(Unknown Source)
at java.text.SimpleDateFormat.subFormat(Unknown Source)
at java.text.SimpleDateFormat.format(Unknown Source)
at java.text.SimpleDateFormat.format(Unknown Source)
at java.text.DateFormat.format(Unknown Source)
at
org.apache.tomcat.util.http.FastHttpDateFormat.getCurrentDate(FastHttpDateFormat.java:116)
at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1567)
at
org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:935)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.sendHeaders(Response.java:379)
at
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273)
at org.apache.catalina.connector.Response.finishResponse(Response.java:492)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:310)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)
Exception in thread "ContainerBackgroundProcessor[StandardEngine[Catalina]]"
java.lang.OutOfMemoryError: Java heap spaceFeb 16, 2009 1:37:21 PM
org.apache.coyote.http11.Http11Processor process
SEVERE: Error finishing response
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOfRange(Unknown Source)
at java.lang.String.<init>(Unknown Source)
at java.lang.StringBuffer.toString(Unknown Source)
at java.io.StringWriter.toString(Unknown Source)
at java.util.logging.SimpleFormatter.format(Unknown Source)
at java.util.logging.StreamHandler.publish(Unknown Source)
at java.util.logging.ConsoleHandler.publish(Unknown Source)
at java.util.logging.Logger.log(Unknown Source)
at java.util.logging.Logger.doLog(Unknown Source)
at java.util.logging.Logger.logp(Unknown Source)
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167)
at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1603)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
at java.lang.Thread.run(Unknown Source)
watanabe
> Umberto Carrara wrote:
>
>> watanabe wrote:
>
>>> Puoi fare due prove:
>>>
>>> 1) scrivi una servlet che fa una chiamata jpa tipo una query e
>>> restituisce solo una frase tipo "ciao", chiamala un numero considerevole
>>> di volte e vedi se si presenta il problema, e a qual punto il problema
>>> è sicuramente JPA.
>> mi sembra un buona idea
>>
>
> Feb 16, 2009 1:06:31 PM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Servlet.service() for servlet TestJpa threw exception
> java.lang.OutOfMemoryError: Java heap space
Quindi siamo sicuri che è l'implementazione JPA.... a questo punto o
c'e' un problema nel codice che usi per fare la query, tipo non rilasci
tutte le risorse + eager loading (come dice il messaggio), oppure c'e'
un bug in OpenJPA o nel driver Postgresql (ma è più difficile).
Umberto Carrara
> Quindi siamo sicuri che è l'implementazione JPA.... a questo punto o
> c'e' un problema nel codice che usi per fare la query, tipo non rilasci
> tutte le risorse + eager loading (come dice il messaggio), oppure c'e'
> un bug in OpenJPA o nel driver Postgresql (ma è più difficile).
a questo punto direi che dopo aver "sistemato" l'enhance con questo build
per ant
<project name="enahnceJPA">
<target name="enhance">
<!-- define the openjpac task; this can be done at the top of the -->
<!-- build.xml file, so it will be available for all targets -->
<taskdef name="openjpac"
classname="org.apache.openjpa.ant.PCEnhancerTask"/>
<openjpac>
<config propertiesFile="./META-INF/persistence.xml"/>
<fileset dir=".">
<include name="**/com/webkey/epress/persistence/*.java" />
</fileset>
</openjpac>
</target>
</project>
le cose vanno meglio, cioè non è più critica come prima ma non credo che sia
risolta anche perchè non ho ben capito dove fosse il problema, per
recuperare l'EntityManager io utilizzo questo metodo
private EntityManager getEm() {
if (em == null) {
try {
em =
Persistence.createEntityManagerFactory("ePressPU").createEntityManager();
} catch (Exception e1) {
e1.printStackTrace();
}
}
return em;
}
e poi chiudo tutte le connessioni all'uscita dei metodi
potrebbe essere un problema di versioni? ho letto su una pagina che OpenJPA
1.2 non è compatibile con java6 che io attualmente uso ma sul sito delle
OpenJPA è dato per java 1.5 e superiori,
intanto mi leggo un'altro po di roba
ciao
Umberto