Domanda

Negli ultimi anni, che abbiamo visto in modo casuale questo messaggio nei registri di uscita durante l'esecuzione di operazioni pianificate in ColdFusion:

ricorsione troppo profondo; lo stack overflow.

Il codice all'interno del compito che viene chiamata può variare, ma in questo caso è molto semplice codice che non fa altro che ripristinare un contatore nel database e poi mi mandi un'email per dirmi che era successo. Ma ho visto accadere con tutti i tipi di codice, quindi sono abbastanza sicuro Non è il codice che sta causando il problema.

Essa ha anche un application.cfm / CFC vuoto per bloccare qualsiasi altro codice chiamato.

L'unica altra volta che vediamo questo è quando stiamo riavviando CF e stiamo tentando di visualizzare una pagina prima che il servizio è completamente avviato.

L'errore accade raramente, ma adesso abbiamo alcune operazioni pianificate piuttosto critiche che le questioni di causa se non corrono. (Da qui sto postando qui per aiuto)

L'utilizzo della memoria va bene. Il compito che correva appena prima che ha riferito di memoria libera oltre l'80%. Il monitoraggio della memoria per tutta la notte non presenta picchi di out-of-the-ordinario. La macchina dispone di 4 GB di memoria e nient'altro esecuzione su di esso, ma il sistema operativo e CF. Recentemente abbiamo provato a reinstallare CF per risolvere il problema, ma non ha aiutato. Succede in molti dei nostri altri assistenti pure.

Questo è un server interno, quindi l'utilizzo alle 3 del mattino dovrebbe essere inesistente. Non ci sono altre attività in programma in esecuzione in quel momento.

Abbiamo visto questo sulle nostre scatole CF7, CF8 e CF9 (fully patched).

  

Il dialogo corrente nelle informazioni domanda:

     
      
  • Versione CF: 9,0,1,274733
  •   
  • Edizione: Enterprise
  •   
  • OS: Windows 2003 Server
  •   
  • Java Version: 1.6.0_17
  •   
  • Min JVM Heap: 1024
  •   
  • Max JVM Heap: 1024
  •   
  • Min Perm Dimensione: 64m
  •   
  • Max Perm Dimensione: 384m
  •   
  • Memoria Server: 4gb
  •   
  • macchina Quad core che vede raramente più del 5% l'utilizzo della CPU
  •   

impostazioni 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

Ecco il codice complesso incredibile che non è riuscito a correre la scorsa notte, ma è in corso da anni, e molto probabilmente run domani:

<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>

Se ho perso qualcosa me lo faccia sapere. Grazie!

È stato utile?

Soluzione

Abbiamo avuto questo problema per un po 'dopo il nostro server è stato aggiornato a ColdFusion 9. La correzione sembra essere in questa tecnica di Adobe su JRun 4: http://kb2.adobe.com/cps/950/950218dc.html

È probabilmente bisogno di fare alcune modifiche alle autorizzazioni come indicato nella nota tecnica.

Altri suggerimenti

Hai provato la riduzione delle dimensioni del vostro mucchio da 1024 a dire 800 qualcosa. Tu dici che non v'è oltre l'80% della memoria resta disponibile in modo, se possibile, vorrei guardare a ridurre il max.

Si tratta di un sistema operativo a 32 o 64 bit? Quando si assegna lo spazio di heap si deve prendere in considerazione tutte le spese generali della JVM (stack, biblioteche, ecc) in modo che non si va oltre il limite del sistema operativo per il processo.

quello che si potrebbe provare è quello di impostare Minimo Dimensione heap JVM per lo stesso del vostro massima Dimensione heap JVM (MB), con l'amministratore in CF.

aggiornare anche la JVM per l'ultimo (21) o almeno 20.

In passato ho sempre aggiornato JVM ogni volta che qualcosa stravagante ha cominciato ad accadere come che di solito ha risolto il problema.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top