Errore di spazio Heap Java nel glassfish

Question

Sto utilizzando una nuova installazione di Glassfish con personalizzazioni molto ridotte.

Possiedo un messaggio Driven Bean (ObjectUpdateMDB) che ascolta un argomento, quindi aggiorna l'oggetto che riceve in un database. Ci sono molti oggetti in fase di aggiornamento. Dopo un po 'di esecuzione ottengo questa eccezione:

 
SEVERE: JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [rollback] operation. 
SEVERE: MDB00049: Message-driven bean [Persistence:ObjectUpdateMDB]: Exception in postinvoke : [javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [rollback] operation. vmcid: 0x0 minor code: 0 completed: No] 
SEVERE: javax.transaction.SystemException 
javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [rollback] operation. vmcid: 0x0 minor code: 0 completed: No 
    at com.sun.jts.jta.TransactionManagerImpl.rollback(TransactionManagerImpl.java:350) 
    at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.rollback(J2EETransactionManagerImpl.java:1144) 
    at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.rollback(J2EETransactionManagerOpt.java:426) 
    at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3767) 
    at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3571) 
    at com.sun.ejb.containers.MessageBeanContainer.afterMessageDeliveryInternal(MessageBeanContainer.java:1226) 
    at com.sun.ejb.containers.MessageBeanContainer.afterMessageDelivery(MessageBeanContainer.java:1197) 
    at com.sun.ejb.containers.MessageBeanListenerImpl.afterMessageDelivery(MessageBeanListenerImpl.java:79) 
    at com.sun.enterprise.connectors.inflow.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:139) 
    at $Proxy98.afterDelivery(Unknown Source) 
    at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:324) 
    at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:76) 
    at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555) 

INFO: MDB00037: [Persistence:ObjectUpdateMDB]: Message-driven bean invocation exception: [java.lang.OutOfMemoryError: Java heap space] 
INFO: java.lang.OutOfMemoryError 
java.lang.OutOfMemoryError: Java heap space 

Sembra che si tratti di un problema con Heap Space. Di cosa ho bisogno per regolare lo spazio dell'heap? Il server delle app stesso o il broker? Come faccio a fare questo?

Answer 1

È necessario assegnare più RAM all'installazione di Glassfish.

Vedi http://spaquet.blogspot.com/2006/07/liferay-glassfish-part-ii-configuring.html

e http://docs.sun.com/app/docs/doc/820-4495/gepzd?a=view.

Answer 2

Ho un post sul mio blog su VM tuning e sto indicando i lettori allo Java Tuning White Paper.

In ogni modo, per ottenere una risposta rapida probabilmente si dovrebbe guardare in un paio di impostazioni di base:

-Xms: dimensione iniziale mucchio

-Xmx: dimensione heap massima

Per ottenere un descrizioni rapide per questi appena eseguiti: java -X.

./alex

Answer 3

Non so se questo è legato, ma abbiamo ottenuto alcune strane eccezioni quando si utilizzano transazioni XA che hanno provocato eccezioni CORBA. Il motivo era il driver MySQL e l'aggiornamento al più recente driver JDBC MySQL (5.1.7) e poi questi problemi XA sono scomparsi.

Answer 4

ho usato i seguenti asadmin comandi per ordinare il problema su Glassfish 3.1:

asadmin create-jvm-options --target server-config -- '-XX\:+UnlockExperimentalVMOptions' 
asadmin create-jvm-options --target server-config -- '-XX\:+UseG1GC' 
asadmin delete-jvm-options --target server-config -- '-Xmx512m' 
asadmin create-jvm-options --target server-config -- '-Xmx1024m' 
asadmin delete-jvm-options --target server-config -- '-XX\:MaxPermSize=192m' 
asadmin create-jvm-options --target server-config -- '-XX\:MaxPermSize=256m' 

asadmin create-jvm-options --target default-config -- '-XX\:+UnlockExperimentalVMOptions' 
asadmin create-jvm-options --target default-config -- '-XX\:+UseG1GC' 
asadmin delete-jvm-options --target default-config -- '-Xmx512m' 
asadmin create-jvm-options --target default-config -- '-Xmx1024m' 
asadmin delete-jvm-options --target default-config -- '-XX\:MaxPermSize=192m' 
asadmin create-jvm-options --target default-config -- '-XX\:MaxPermSize=256m' 

Esso è una variante Michael Myers suggerimento. L'utilizzo dei comandi asadmin rende la modifica facilmente ripetibile.

Inoltre, sono passato al nuovo collezionista G1 che è molto meglio del normale raccoglitore. Aiuta anche con Eclipse ;-)

Si noti che la sintassi è per TakeCommand su Windows. Se si utilizza una combinazione diversa di shell e sistema operativo, potrebbero essere necessari caratteri di escape diversi (ad es. Ticks strait anziché backtick per la maggior parte delle shell unix).

Se si configura la configurazione con i comandi *-jvm-options, è possibile correggerla con il file domain.xml.