Hi, folks. We are facing a strange problem while m...
# questions
g
Hi, folks. We are facing a strange problem while migrating our application from Grails 2.5.6 to Grails 4.1.3. When compiling assets using
./gradlew assetCompile
, the gradle task compiles nicely until the first
.scss
file.
Copy code
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
It happens mostly when using Docker with Java Temurin 8 image, but it sometimes happens locally on some devs computers. We are using the 3.2.5 version of asset pipeline plugin
Copy code
classpath "com.bertramlabs.plugins:asset-pipeline-gradle:3.2.5"
        classpath "com.bertramlabs.plugins:asset-pipeline-core:3.2.5"
        classpath "com.bertramlabs.plugins:sass-asset-pipeline:3.2.5"
When I tried moving to 3.4.0 with Sass Dart version, I saw the memory used by the process on System Monitoring jump from 3GB to 24GB in less than a minute. The files were being processed correctly and looking the debug logs I didn't find any circular injection, for example. Do anybody else had this problem or something similar? Thanks in advance
g
I used to have some similar issues like this. I did exclude some of them to avoid the issue. Then tried to identify which lines of code introduced the error then work around of it.
Copy code
assets {
    minifyJs = true
    minifyCss = true

    enableSourceMaps = true
    configOptions = [:]

    minifyOptions = [
            languageMode     : 'ES6',
            targetLanguage   : 'ES6', //Can go from ES6 to ES5 for those bleeding edgers
            optimizationLevel: 'SIMPLE',
            excludes         : ['**/static/*.*', '**/*.html']
    ]

    includes = ['**/*.hbs']
    excludes = [
            '**/*.less',
            '**/static/*.*',
    ] //Example Exclude GLOB pattern

    //for plugin packaging
    packagePlugin = false //set to true if this is a library

    //developmentRuntime can be turned off
    developmentRuntime = false

    //if you want to customize the jar task this task runs on you can specify a jarTaskName
    jarTaskName = null

    // Can add custom asset locations (directories or individual jar files)
    from '/vendor/lib'
}
g
I'm trying this, but it's not a particular file, seems to be a leak because we have "too many files" (there are 270 SCSS files in the project). The thing is that it compiles nicely until it reaches the firsts SCSS file (doesn't matter which one), then it starts to consume memory in big steps: • From 3.7GB to 4.2GB • From 4.2GB to 5GB • ... until 25GB in a matter of seconds We are thinking about preprocessing SCSS using another strategy, because we didn't find a solution for this
šŸ‘ 1
g
Yeah manually compose css and minify it can be another solutions.
šŸ™Œ 1
j
@Galeno de Melo we wrote the Sass Dart version and I didn't think it was compatible with asset pipeline until later versions. One of the reasons we changed the asset pipeline to forked compiling in Grails 7 was b/c the memory would never go down / free up. So this is likely addressed by the newer versions. We can't easily build teh older version due to the organization change of the asset pipeline
g
@jdaugherty I see, we are going to proceed with another precompiler solution instead. In our Grails 5 applications we use Dart and don't have this issue. Thanks for the information.