Error de Java Heap Space en glassfish

Question

Estoy utilizando una instalación reciente de Glassfish con muy pocas personalizaciones.

Tengo un Message Driven Bean (ObjectUpdateMDB) que escucha un tema y luego actualiza el objeto que recibe en una base de datos. Hay muchos objetos que se actualizan. Después de un tiempo de ejecución obtengo esta excepción:

 
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 

Parece que es un problema con Heap Space. ¿Para qué necesito ajustar el espacio del montón? ¿El servidor de aplicaciones en sí o el intermediario? ¿Cómo hago esto?

Answer 1

Debe asignar más memoria RAM a su instalación de Glassfish.

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

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

Answer 2

Tengo una publicación en mi blog sobre VM tuning y estoy apuntando a los lectores al Java Tuning White Paper.

De todas formas, para conseguir una respuesta rápida, probablemente debería mirar en un par de ajustes básicos:

-Xms: tamaño inicial del almacenamiento dinámico

-Xmx: tamaño máximo del montón

Para obtener una descripciones rápidas para estos solo ejecutar: java -X.

./alex

Answer 3

No sé si esto está relacionado, pero tenemos algunas excepciones extraños al utilizar transacciones XA que dieron lugar a excepciones CORBA. La razón fue el controlador MySQL y nos actualizamos al último controlador JDBC de MySQL (5.1.7) y luego estos problemas XA desaparecieron.

Answer 4

He utilizado los asadmin comandos siguientes para solucionar el problema en 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' 

Es una variación sobre Michael Myers pista. El uso de los comandos asadmin hace que el cambio sea fácilmente repetible.

También cambié al nuevo colector G1 que es mucho mejor que el colector normal. También ayuda con Eclipse ;-)

Tenga en cuenta que la sintaxis es para TakeCommand en Windows. Si usa una combinación diferente de shell y sistema operativo, es posible que necesite diferentes caracteres de escape (es decir, marcas de acceso estrechas en lugar de barras invertidas para la mayoría de las capas de Unix).

Si modifica su configuración con los comandos *-jvm-options, puede arreglarlo con el archivo domain.xml.