SASS @import statements not working with parallelPreprocessing

[rj.ku...@gmail.com]

Last week we turned on parallelPreprocessing to speed up CSS generation, which was very slow. Now I see errors of SASS mixins not being defined during preprocessing.

I keep mixins in a separate .scss file and import them using @import(relativePath); when needed. In this example I import a file _mixins.scss that is defining few mixins including one named box-sizing. I import it in a file buttons.scss with @import "_mixins.scss"; and get this error:

2014-07-15 12:32:54,174 ERROR [ro.isdc.wro.model.resource.processor.decorator.ExceptionHandlingProcessorDecorator] [wro4j-parallelPreprocessing-3-thread-8] Failed to process the resource: ro.isdc.wro.model.resource.Resource@6b450c9c[CSS,/eis/resources/shared/buttons.scss,true] using processor: ro.isdc.wro.extensions.processor.css.RubySassCssProcessor@7d54799. Reason: org.jruby.embed.EvalFailedException: (SyntaxError) Undefined mixin 'box-sizing'

Looks like the problem is that the imported file with mixins hasn't yet been processed when the importing file is. Does anybody knows a way to fix that? Is that a bug?

[Alex Objelean]

The  parallelPreprocessing is not reliable for this kind of situations. It would work only if each resource could be processed independently. 

Are you using the build time solution (maven plugin)? If yes, to fix the slowness, enable the incrementalBuildEnabled flag (see details here).

For runtime solution, use the configuration options: (resourceWatcherUpdatePeriod & resourceWatcherAsync). More details here.

Cheers,

Alex

--
You received this message because you are subscribed to the Google Groups "wro4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wro4j+un...@googlegroups.com.
To post to this group, send email to wr...@googlegroups.com.
Visit this group at http://groups.google.com/group/wro4j.
For more options, visit https://groups.google.com/d/optout.

[rj.ku...@gmail.com]

We're using runtime solution. I'll try experimenting with those values.

[rj.ku...@gmail.com]

It doesn't solve our issues, as these arguments only control cache, so save the time on further calls to the same file. In our development we often restart our servers and the problem is that the first call to the CSS file takes very long (8-20 seconds) to be processed. The slowness seems to be caused by rubySassCss pre-processor. The other problem that only adds to it is caching mechanism which always works only since the 4rd call to the same CSS file - first 3 call seem to not be using cache, as they take long to process and since the 4th it's immediate.

I have 2 questions:

• Is sassCss (JavaScript implementation) faster than rubySassCss?
• Why does caching works since the 4th call? Is there a way to change that behavior? 

[Alex Objelean]

To answer your questions:

1) The javascript implementation uses rhino, which is not fast at all (rhino is slow by nature). But there is no benchmark comparing ruby implementation with rhino (you could try, but I don't expect any performance improvement). If you are using Java 8, you could create a custom processor using nashorn (I'm planning to add support in future), which is comparable to V8 js engine. But this require some work on your side. 

I would also suggest the following approach: precompile (using build-time solution) some of the sass libraries and use sass only for a small subset of resources.

2) The cache is supposed to work for the second call. If it doesn't, than it is likely a bug. As far as I remember, I have covered with unit tests this scenario and there was no changes for long time on that part of code. If you can prove this bug (try debugging), let me know and I will open an issue and will fix it for next release.

Cheers,

Alex

[Alex Objelean]

One more thing,

how do you configure the sassProcessor? Could you share your configuration?

I would expect the sassProcessor to be applied only to sass resources (css shouldn't be touched), otherwise it performs unnecessary processing. I assume you know about extensions aware processor decorator which allows very easy to achieve that.

Cheers,

Alex

[rj.ku...@gmail.com]

This is our configuration (wro.properties):

managerFactoryClassName=ro.isdc.wro.manager.factory.ConfigurableWroManagerFactory
preProcessors=cssUrlRewriting,cssImport,semicolonAppender,rubySassCss.scss,cssMinJawr
postProcessors=cssVariables,jsMin
uriLocators=servletContext,uri,classpath
connectionTimeout=30000
parallelPreprocessing=false
resourceWatcherUpdatePeriod=10
resourceWatcherAsync=true
ignoreMissingResources=false
disableCache=false

[Alex Objelean]

Yes, apparently you already use the extension aware decorator. 

I think you should consider either creating a faster sass based processor (which is not easy and requires java8) or use the build-time solution to process the large part of your sass resources.

Thanks,

Alex

[Alex Objelean]

I'm still trying to understand what you consider the bigger problem: time you need to wait for first request or change feedback slowness during development? 

The second problem should be fixed with resourceWatcherUpdatePeriod and resourceWatcherAsync, while the first one could be somehow improved (ex: automatically process the resources after startup, so that user wouldn't have to wait when requesting the page for the first time).

Alex

[rj.ku...@gmail.com]

Time that I need to wait for the first request is the biggest problem. Is there a wro4j option that could force processing of the resources soon after server startup? Though I'm not sure if that would solve the problem. We often restart the server during development and usually make the HTTP requests soon (1-3 seconds) after the server starts.

I don't have any problems with "change feedback slowness". You must have misunderstood me in that matter.

The other issue I consider a problem is that the cache is working only since the 4th call, as each processing takes a long time. I'm planning to debug the code in that matter, as you have advised. I'll share my results when I do.

[Alex Objelean]

I agree that the time spent on first request is painful, but this is the cost you pay for having processing on the fly and using a slow processor .. 

There is no  support for triggering processing after start-up yet, but there was a similar request from somebody else, so I will consider creating an issue for this.

Thanks,

Alex

[rj.ku...@gmail.com]

Alright. I think that's all for now. Thank you for your help. When I'll debug the code in the matter of not caching 2nd and 3rd request I'll share my results here.

[rj.ku...@gmail.com]

I started debugging the code and I think I see the problem. But first I need to tell you that today it's not the 4th call that is first to retrieve the value directly from cache but the 3rd. It's changed since yesterday. So the 1st call for the resource is taking very long to process, then the 2nd one is much shorter but still quite long and every call since the 3rd retrieves the value from cache and is almost instant.

The problem is ResourceWatcher, which is invoked AFTER the 1st request for the resource when the value is already stored in cache. As it looks like it's invoked for the first time, it sees all the resources as new and so invalidates the cached value. The 2nd request for the resource sees empty cache and so loads the resouces again, then storing it in the cache. As there is no ResourceWatcher invoked this time (BTW I've set resourceWatcherUpdatePeriod to 600 seconds) the 3rd call properly retrieves the value from cache.

Shouldn't the ResourceWatcher be invoked for the first time soon after the server start?

[Alex Objelean]

Interesting bug :)... I will open an issue. 

The ResourceWatcher is invoked only after the first request (it is lazy).

Thanks,

Alex

[rj.ku...@gmail.com]

If it should be lazy, then it shouldn't invalidate the cache on the first invoke, right?

[Alex Objelean]

That is correct. This is a bug and it should be fixed.

Thanks,

Alex

[rj.ku...@gmail.com]

Then I'll be looking forward to the next release : ).