Data corruption with Nashorn + Handlebars and concurrent requests

[Sebastien Deleuze]

Hi,

Thanks for your feedback. I have asked the question on Handlerbars.js issue
tracker [1], let's see what is their answer.

Regards,
Sébastien Deleuze

[1] https://github.com/wycats/handlebars.js/issues/1031

On Mon, May 25, 2015 at 9:56 AM, A. Sundararajan <
sundararajan.athijegannathan at oracle.com> wrote:

> Hi,
>
> Thanks for (near!) standalone test. I've further simplified -- copied all
> relevant scripts, removed testng dependency. Just a main class, Comment
> class and associated scripts. I've filed a nashorn bug to track this
> issue/thread:
>
> https://bugs.openjdk.java.net/browse/JDK-8080975
>
> I've attached a .zip file with the standalone program which I mentioned.
>
> Now, even with loadWithNewGlobal, you're leaking Handlebars object to the
> new global - that is quite not an isolation. New global isolation will work
> only if you use simple data being passed (like string, numbers etc.). In
> your case, you're passing "Handlebars: object to the script executed in new
> global. And "compile" method of Handlebars object is called. That compile
> method is executed in the old global- i.e., it'd refer to global variables
> in which Handlebars object was picked from! We do *not* really know if
> handlebars.js is designed with concurrency in mind at all!! In other words,
> is handlebars library thread safe? For eg. if "compile" function uses any
> global variable, the variable is from that old global in which Handlebars
> object is defined. That is asking for trouble.
>
> -Sundar
>
>
> On Friday 22 May 2015 07:46 PM, Sebastien Deleuze wrote:
>
>> 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)
>>>>
>>>>
>>>
>