ColdFusion: Recursión excesiva; la pila se desbordó

Question

En los últimos años hemos estado viendo este mensaje al azar en los registros de salida cuando se ejecutan tareas programadas en ColdFusion:

Recursión excesiva; la pila se desbordó.

El código dentro de la tarea que se está llamando puede variar, pero en este caso se trata de un código muy simple que no hace más que restablecer un contador en la base de datos y luego enviarme un correo electrónico para decirme que fue un éxito. Pero he visto que suceda con todo tipo de código, por lo que soy bastante seguro no es el código que está causando este problema.

Incluso tiene un Application.cfm vacío / CFC para bloquear cualquier otro código que se llama.

La única otra vez que vemos esto es cuando vuelve a empezar CF y estamos tratando de ver una página antes de que el servicio se ha iniciado completamente.

El error rara vez ocurre, pero ahora tenemos algunas tareas programadas y no críticos que causa problemas si no se ejecutan. (De ahí que lo pongo aquí para obtener ayuda)

El uso de memoria está bien. La tarea que corrió justo antes de que informó de más del 80% de memoria libre. Monitorización de la memoria a través de la noche no muestra picos fuera de lo común. La máquina cuenta con 4 gigas de memoria y nada más, pero se ejecuta en el sistema operativo y CF. Hace poco hemos probado a reinstalar CF para resolver el problema, pero no ayuda. Sucede en varios de nuestros otros servidores también.

Este es un servidor interno, por lo que el uso a las 3 am debe ser inexistente. No hay otras tareas programadas que se está ejecutando en ese momento.

Hemos estado viendo esto en nuestras cajas CF7, CF8 y CF9 (con todos los parches).

  

El cuadro actual en la información pregunta:

     

  
• versión CF: 9,0,1,274733
  
• Edición: Enterprise
  
• SO: Windows 2003 Server
  
• Versión de Java: 1.6.0_17
  
• Min pila de JVM: 1024
  
• Max pila de JVM: 1024
  
• Min Perm Tamaño: 64m
  
• Max Perm Tamaño: 384m
  
• Servidor de memoria: 4 GB
  
• Quad máquina de la base de que rara vez se ve más que 5% de uso de la CPU
  

configuración de JVM:

  

-server -Dsun.io.useCanonCaches = false -XX: PermSize = 64m -XX: MaxPermSize = 384m -XX: + UseParallelGC -XX: + AggressiveHeap -Dcoldfusion.rootDir = {application.home} /../   -Dcoldfusion.libPath = {application.home} /../ lib   -Doracle.jdbc.V8Compatible = true

Este es el código complejo increíble que no puede ejecutar la noche anterior, pero ha estado funcionando durante años, y lo más probable carrera de mañana:

<cfquery datasource="common_app">
    update  import_counters
    set current_count = 0
</cfquery>

<cfmail subject="Counters reset" to="my@email.com" from="my@email.com"></cfmail>

Si me perdí nada que me haga saber. Gracias!

Answer 1

Hemos tenido este problema durante algún tiempo después de nuestro servidor se actualizó a ColdFusion 9. La solución parece estar en esta nota técnica de Adobe en JRun 4: http://kb2.adobe.com/cps/950/950218dc.html

Es probable que tenga que hacer algunos ajustes en los permisos como se indica en la nota técnica.

Answer 2

¿Usted ha intentado reducir el tamaño de su montón de 1024 a 800 decir algo. Usted dice que no es más del 80% de la memoria queda así disponible si es posible me gustaría ver a reducir al máximo.

Es un sistema operativo de 32 o 64 bits? Al asignar el espacio de almacenamiento dinámico que tiene que tomar en consideración todos los gastos indirectos de la JVM (pila, bibliotecas, etc.) para que no pasen por encima del límite del sistema operativo para el proceso.

Answer 3

lo que podría intentar es para ajustar el tamaño mínimo de pila de JVM al igual que el tamaño máximo de almacenamiento dinámico de JVM (MB) con su administrador de la FQ.

También actualización a la JVM que la última (21) o, al menos, 20.

En el pasado siempre he actualizado la JVM cuando algo loco empezó a ocurrir como que suele resolver el problema.