Hi, I have added a very simple unit test, without any Spring Boot code, that reproduces the issue [1].
Rendering concurrently templates with Mustache works as expected. Rendering concurrently templates with Handlebars generates the exceptions described previously, even if I use loadWithNewGlobal(). Does that help you to find the issue? Is it the expected way to use loadWithNewGlobal() to avoid concurrency issues? Regards, Sébastien [1] https://github.com/sdeleuze/script-engine-test/blob/master/src/test/java/demo/NashornConcurencyIssueTests.java On Tue, May 12, 2015 at 6:49 PM, A. Sundararajan < [email protected]> wrote: > Hi, > > Sorry for the delayed response. It has been very difficult locating > anything in particular. > > Is it possible for you to reduce the test further? I think you'd in better > position because of the domain knowledge.. > > Thanks, > > -Sundar > > > On Wednesday 06 May 2015 05:32 AM, Sebastien Deleuze wrote: > >> Hi, >> >> I currently try to implement support for Script based templating in Spring >> Framework [1] using Nashorn and template engines like Mustache or >> Handlebars. >> >> As discussed today on Twitter [2], I have some strange argument corruption >> issues when using Nashorn + Handlebars with concurrent request. I am aware >> of loadWithNewGlobal() but it seems I don't use it properly because I >> still >> see the issue using it. >> >> In order to make things simpler, I have created a repo project [3]. To >> make >> it work, simply execute TestApplication main class. >> >> MustacheJS seems to works with concurrent requests : >> ab -n 5000 -c 4 http://localhost:8080/mustache/ >> >> But Handlebars seems to have some strange data corruption issues [4] (the >> template contains <title>{{title}}</title> but <title>{title}}</title> is >> printed in the log error message !!!) running both raw >> and loadWithNewGlobal() alternatives: >> ab -n 5000 -c 4 http://localhost:8080/handlebars/ >> ab -n 5000 -c 4 http://localhost:8080/handlebars/newglobal/ >> (the errors are displayed in the system output) >> >> Could you please have a look to this repro project in order to see if: >> - There is a better way to use loadWithNewGlobal() (without the >> intermediate render() function maybe) >> - If there is an issue in my code ? >> - If there is an issue in Nashorn ? >> >> Running ab -n 5000 -c 1 http://localhost:8080/handlebars/ produces no >> error, so this is really related to concurrency. >> >> This is a feature we would like to ship with Spring Frameworks 4.2, so >> making it running flawlessly is mandatory for us, I hope it will be >> possible! >> >> Thanks in advance for your help, >> Sébastien Deleuze >> >> [1] https://jira.spring.io/browse/SPR-12266 >> [2] https://twitter.com/sdeleuze/status/595586467298222082 >> [3] https://github.com/sdeleuze/script-engine-test >> [4] jdk.nashorn.internal.runtime.ECMAException: Error: Parse error on line >> 3: >> ...ead> <title>{title}}</title> >> ----------------------^ >> Expecting 'EOF', 'COMMENT', 'CONTENT', 'END_RAW_BLOCK', 'OPEN_RAW_BLOCK', >> 'OPEN_BLOCK', 'OPEN_INVERSE', 'OPEN_INVERSE_CHAIN', 'INVERSE', >> 'OPEN_ENDBLOCK', 'OPEN', 'OPEN_UNESCAPED', 'OPEN_PARTIAL', got 'INVALID' >> at >> >> jdk.nashorn.internal.scripts.Script$\^eval\_$2._L36$_L874$_L880$parseError(<eval>:1025) >> at >> >> jdk.nashorn.internal.scripts.Script$\^eval\_$2._L36$_L874$_L880$parse(<eval>:1077) >> at >> >> jdk.nashorn.internal.scripts.Script$\^eval\_$4._L36$_L1910$parse(<eval>:1936) >> at >> >> jdk.nashorn.internal.scripts.Script$\^eval\_$5._L36$_L1944$compile$compileInput(<eval>:2396) >> at >> >> jdk.nashorn.internal.scripts.Script$\^eval\_$4._L36$_L1944$compile$_L2403(<eval>:2405) >> at >> jdk.nashorn.internal.scripts.Script$\^eval\_.renderHandlebars(<eval>:17) >> at >> >> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:502) >> > >
