On 18/07/10 20:12, Markus Roberts wrote: > All -- > > After several hours of trying I've been unable to reproduce #4268 > (failing to cache loaded code) or anything that resembles it. > > I'm stumped. > > Has anyone testing 2.6.0 seen anything like this (or seen it on any > previous version) or does anyone have any thoughts on what might be > needed to reproduce it? > > The closest I've come (and it isn't a very realistic simulation) is to > set filetimeout to 0 and then run a bash script that touches the > module source every second; of course, it then re-autoloads them each > time, but that's to be expected.
I wasn't able to reproduce the issue either (under jruby and MRI/mongrel/nginx, all with --no-daemonize in a controlled env). But... I think Peter found something about the compilation time that increased in 2.6.0. I didn't pay attention while testing 2.6 as I was focusing on bugs. But I just tried 0.25.5 on a fast test server to compile my largest host (around 2k resources spread in 100 modules) and found: 0.25.5: 5s (second run, so no import) 2.6.0rc3: 33s (second run, no import logged) Both are with storeconfigs disabled (even though there are some collections in the manifest). Enabling storeconfigs just increase a little bit the compilation time (which is expected). I guess there's something wrong somewhere that I missed. I'm a little bit clueless on how to debug this, any ideas? Looking at the console during compilation, there doesn't seem to be any noticeable stalls. Did anyone notice this too? -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
