Problema memoria con Socket

[mvillara]

Buenas, tengo una conexión mediante Sockets, donde solo se conecta un programa cliente y claro, todo funciona de maravilla hasta que a las 4 o 5 horas te das cuenta que hace 'CRASH', osea, que peta el Servidor!!!. Falla la memoria virtual(error Java Heap Space), viendo cosas por ahí llego a la conclusión de que cada vez que mando paquetes por el canal de salida hacia el cliente, dicho Buffer intermedio donde se ubican los paquetes antes de ejecutar la instrucción flush(), no llega a limpiarse y va acumulando basura que no llega a limpiarse. La cosa por lo visto se solucionaría cerrando la conexión Socket y abriendo de nuevo entre cada paquete y así sí que se limpiaría (según llego a la conclusión). Mi pregunta es si alguien supiera alguna otra técnica que no sea la de Cerrar la conexión y abrirla de nuevo entre cada envío de paquete. Una cosa cabe mencionar es que el flujo de información entre servidor y cliente es constante, se podrán estar enviando entre 35 y 300 paquetes por segundo.

Gracias de antemano....

[GreenEyed]

Has pocas posibilidades, aunque haberlas haylas, de que sea un fallo del socket en sí, ya que hay multitud de programas hechos en Java con sockets que no tienen estos problemas, así que es mucho más probable que sea un fallo de aplicación por que no estés liberando la memoria que usas de forma adecuada, que en Java se traduce en que no estás dejando que el GC la libere.

Lo más directo sería usar un "profiler" como Java VisualVM que viene en Java 6, si estás usando o puedes usar esa versión, o algún otro parecido para ver en ejecución donde se está consumiendo la memoria.

S!

[mvillara]

Gracias por la respuesta. La verdad es que es bastante raro. Antes de incorporar los socket al programa, no tenía este fallo, y fue incorporar esa funcion de conexion y fallar. En fin, veré como funciona eso del Profiler que no se que es a ver como me soluciona el problema.

Gracias.

[tistklehoff]

Hola.

Mientras tanto, trata de ejecutar la aplicación con el parámetro -Xmx.

Por defecto, una máquina virtual Java toma (creo recordar) 64Mb de memoria. Con este parámetro puedes hacer que tome más memoria para que tarde más tiempo en llenarse.

Además, echa un vistazo a los métodos Runtme.freeMemory, maxMemory y totalMemory, que te dicen cuánta memoria hay libre, máxima utilizable y máxima total en la máquina virtual. Es una forma rápida y algo tonta de verlo, pero puedes hacerlo fácilmente y después completar mirando un profiler.

Por cierto. ¿Devuelve una excepción o un error grave? ¿Has tratado de capturar Exception? ¿y capturar Throwable?

Tu programa usa un objeto ServerSocket para esperar las conexiones, ¿cómo haces la lectura de lo que te viene? ¿el procesamiento que haces de la información recibida es pesado? Pregunto esto porque podría ser que al leer los paquetes y tardar en procesarlos, los restantes queden en el socket y, si la información es tan ta, al final lo colapsen. ¿Podría ser?


Un saludo.

[chuidiang]

Hola:

Otra posibilidad más es que si el flujo de información es constante como dices y más o menos alto, el del otro lado no los esté retirando con suficiente rapidez, por lo que poco a poco los bufferes internos de sockets van acumulando mensajes.

Cuando se llena el buffer interno del que recibe (porque no los va retirando con suficiente rapidez), los mensajes empiezan a acumularse en el buffer interno del que envía. Cuando el buffer interno del que envía se llena, las llamadas a write() empiezan a bloquearse hasta que queda hueco en ese buffer interno. No sé qué código tienes para la llamada a los write(), pero quizás donde se generen los mensajes a enviar empiecen a acumularse datos en alguna ista.

Al ser cada cuatro horas más o menos, si el motivo fuese este que te indico, quiere decir que la velocidad de leer mensajes es un pelín inferior a la de generarlos. Si la diferencia fuera muy grande, pasaría antes. O quizás se debe a una punta de envio de mensajes a más velocidad de la cuenta.

Se bueno.