29
Replies
Thanks Dave:
You can safely disregard that file path. Precompiled templates contain the path from which they were originally compiled.
- noted.
Charlie;
Very comprehensive, thank you, and yes a nod to Carl is due as well.[Thanks again Carl]
I think I may have said "panic mode" maybe I should downgrade that to severe frustration mode - at least mail, dns & most httpd were unaffected & I did get a blast email out noting "emergency maintenance" so any damage was/is minimized.....
on to it....
I've never heard of a situation where deleting a class file solves such a dramatic problem as you reported. I'd really wonder if there may not be more going on.
Me too, the closest I can figure is that the class files may be related to one another in some way [like a database] i.e. one function called on page A is compiled, the CF comes across the same function on pages B, C & D.... instead of compiling that one function into classes for B, C & D icompiles classes for those pages WITHOUT the one function & just a pointer or reference to class file A.
Disclaimer: That was a WAG [Wild Wssed Guess] - I have no knowledge of how the class files are compiled or related to one another - but it would explain why deleting the one offending file made the rest of the classes work again.
Logs:
yea- I pretty much figured they were platform differences, in fact you can convince CF to log everything to syslog facilities with a little acrobatics... but worthwhile?? prolly not.
Strange Path:
Dave mentioned as wel... noted, thanks.
Scheduler/Logs/When to look:
Yes, the scheduler thing became apparent when I tested it - worked - I encourage users to use cron instead.... so there were no tasks scheduled, anyway... as far as logging goes and how far back, it's very difficult as this seems to be an issue that pops up 'whenever' I might go for 2 weeks or 2 months without an issue [actually I ran for close to a year with no problems before July this year] by the time I'm looking at logs the problem has already been rotated out and pruned [yea- yea - I know, increase log file size & number of archives , time to live 
] Also looking at those java logs sucks, I can find my way around any linux syslem log easily, but that java stuff makes my eyes bleed!
cf/Runtime/bin:
Ahhhhhhh! these are very interesting indeed, however the last if from Sept 25.... a little too far back, but deservers some investigation anyway.
Memory heep too low, yes - I am trying to make it crash so I can examine/dfferentiate the errors... [though so far it is running quite smooth and smart - a lot of the sites on the server are not actual loaded applications, usually simple website includes, light scripting and maybe a few database calls - so the load on CF is not heavy at all]
The one thing I did notice [or rather jumped out at me] was that the java log in cf/Runtime/bin reported 8-4core CPUs available to it.
Keeping in mind that this is a VM and those CPU's are shared, I have had significant problems with php caching accelerators Xcache to be specific when I tried to use more than 1 CPU. I'm curious if my concurrent threads in CFAdmin could have been causing problems.... according to the official docs, I should be able to set my threads to between 8 & 16... [is it number of CPUs = threads x 2 or number of CORES? i.e. 32 - 64 threads?????]
In the past if I tried to set xcache to more than 2 CPU, I got an immediate & unforgiving ticket to hell while being escorted by Nazis. Apache would not even start.
Still testing & monitoring.
-thanks a bunch [everyone!]
-sean
AdChoices