Data corruption with Nashorn + Handlebars and concurrent requests

[Sebastien Deleuze]

See Handlebars developers feedback [1].

As suggested before, Handlerbars is not designed with concurrency in mind,
but they may accept some pull requests to improve that if that means no
regression for other regular users.
I will try to have a look to at least identify what should be done and have
an idea of the amount of work needed to fix that.

[1]
https://github.com/wycats/handlebars.js/issues/1031#issuecomment-107271075

On Tue, May 26, 2015 at 7:50 AM, A. Sundararajan <
sundararajan.athijegannathan at oracle.com> wrote:

> Oops. double negative :)
>
> /but the compiled handlebars function may not be MT-unsafe./
>
> should have been
>
> "but the compiled handlebars function may not be MT-safe".
>
> -Sundar
>
>
> On Tuesday 26 May 2015 11:15 AM, A. Sundararajan wrote:
>
>> Actually either the Handlebars.compile or the compiled function could be
>> MT-unsafe. FWIW, I tried the following change to handlebars's render.js
>> script:
>>
>> function renderHandlebars(template, model) {
>>
>>     // Create a real Javascript Object from the model Map
>>     var data = {};
>>     for (var k in model) {
>>         // Convert Java Iterable and List to real Javascript arrays
>>         if (model[k] instanceof Java.type("java.lang.Iterable")) {
>>             data[k] = Java.from(model[k]);
>>         } else {
>>             data[k] = model[k];
>>         }
>>     }
>>     // TODO Manage compiled template cache
>>     var compiledTemplate = Handlebars.compile(template);
>>
>>     // call compiled template function as synchronized
>>     // use Handlebars object as lock
>>
>>     return Java.synchronized(function(data) {
>>         compiledTemplate(data);
>>     }, Handlebars);
>> }
>>
>> With that change, it appears handlebars MT-usage seems fine [i.e., no
>> exception seen]. This suggests that the Handlebars.compile itself is
>> MT-safe but the compiled handlebars function may not be MT-unsafe. FYI.
>>
>
>