Caching broken under certain configurations in v2.1(pre)

[dizzib]

After upgrading from 1.x to 2.1(pre) the caching seems to be broken under certain configurations...

    SassAndCoffee   IIS Output      SASS/CSS    Coffee/JS
Id  cache type      Caching ?       working ?   working ?   Notes

1   NoCache         N               Y           Y           slow
2   NoCache         Y               Y           N
3   File            N               N           Y
4   File            Y               N           N
5   InMemory        N               Y           Y           slow after change then fast
6   InMemory        Y               N           N

A result of 'N' means a stale file gets served.

I'll use configuration #5 for now. Please let me know if you need more info.

Cheers,
Andy.

[kogir]

Thanks so much for doing all this testing!

I need to write a ton of tests around this.

[dizzib]

No probs. Unfortunately v2.1pre config #5 occasionally hangs with cpu pegged at 100% requiring a kill of w3wp.exe. Last night I reverted to v2.0 but this also has issues with serving stale css files. For me v1.x with the V8 engine is a lot more stable.

I can confirm the high cpu occurs intermittently when requesting a css file after an unrelated sass file is updated. This is in v2.0 with output caching disabled and file caching enabled. My 3-core server cpu stays at 100% for around 1 or 2 minutes, then one of the cores drops off leaving the remaining cores at 100%. The client browser (Chrome) is left hanging.

Interestingly, when I then kill w3wp.exe another w3wp.exe immediately fires up and the request completes.

Cheers!

[dizzib]

Not sure if I'm way off mark here, but wouldn't the following code go into an infinite loop if compiler.Initialize() always throws an exception...?

    private static ISassCompiler CreateAndInitializeSassCompiler() {
        var compiler = new SassCompiler();
        bool initialized = false;
        lock (_compilerInitializationLock) {
            while (!initialized) {
                try {
                    compiler.Initialize();
                    initialized = true;
                } catch { }
            }
        }
        return compiler;

I could imagine this scenario occurring if, say, compiler.Initialize() -> Ruby.CreateRuntime() always throws an exception.

[kogir]

You're absolutely correct. 2.1 isn't really ready for use yet. I think in the end I'll need to keep IronRuby in its own AppDomain that I can kill off if needed. The code you found was an attempted work around for some behavior I observed where initialization failed the first two times but worked after that.

[dizzib]

That's a good idea with the AppDomain.

I've raised the 100% cpu issue as a separate bug as I don't think it's related to caching.

Anyway, I just wanted to say thanks for creating SassAndCoffee it's really appreciated!