Data corruption with Nashorn + Handlebars and concurrent requests

Sebastien Deleuze sdeleuze at pivotal.io
Fri May 22 14:16:45 UTC 2015


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 <
sundararajan.athijegannathan at oracle.com> 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)
>>
>
>


More information about the nashorn-dev mailing list