Closures not thread-safe?

[João Paulo Varandas]

Hi Jorg.

Could you send us a code snippet?

I have never seem such problem when using closures. In my project, I use a
single engine for whole web application. My tomcat is running with 150
maxThreads and it seems to be working fine. I test that in each build by
running the test case below:

https://gist.github.com/joaovarandas/f80a9cb5548a9d620e4da1ace2729911

The idea in this test is to use a single engine and run a closure from
one-thread or multiple-threads simultaneously and then read data from those
closures.


PS.: Should I send the source code directly in the mail body for future
readers?





João Varandas
*Arquiteto de Soluções Cloud*
inPaaS - Idéias em Aplicações

p: +55 11 5091-2777  m: +55 11 99889-2321
a: Rua Nebraska, 443 - 1o Andar
  Brooklin Paulista, São Paulo, SP
w: www.inpaas.com  e: joaovarandas at inpaas.com


2017-02-19 18:30 GMT-03:00 Frantzius, Jörg <Joerg.Frantzius at aperto.com>:

> … to correct myself, with code that contains closures, it’s probably
> global-per-thread on a single engine that remains as the least
> resource-consuming option (we were using a single global on single engine
> for all threads, in order to share expensively computed Javascript state
> between them).
>
> From what I understand, global-per-thread could be implemented e.g. by
> having a ThreadLocal<ScriptContext> and always using that as the context in
> ScriptEngine.eval(script, context).
>
> It would be good to know then whether global-per-thread on single engine
> still allows for sharing Nashorn’s code optimization between threads? That
> would already be great (and as Nashorn *is* great, I’m positive here :)
>
> Regards,
> Jörg
>
>
> Am 19.02.2017 um 00:47 schrieb Frantzius, Jörg <Joerg.Frantzius at aperto.com
> <mailto:Joerg.Frantzius at aperto.com>>:
>
> Hi,
>
> it begins to dawn on me that closures aren’t thread-safe, at least that
> would explain crosstalk issues we’re seeing in JMeter tests (with a single
> engine for multiple threads).
>
> It would be good to know (and I guess for others as well) if somebody can
> confirm this?
>
> Perhaps thread-safety of closures was thinkable if Nashorn somehow stored
> closure state in ThreadLocals, but I guess that’s neither happening nor
> planned?
>
> From what I understand, closures are pervasive in Javascript code out
> there, and anybody using such code will currently be forced to use
> engine-per-thread.
>
> Thanks for any hints,
> Jörg
>
>
> ---
>
> Dipl. Inf. Jörg von Frantzius, Technical Director
>
> E-Mail joerg.frantzius at aperto.com<mailto:joerg.frantzius at aperto.com>
>
> Phone +49 30 283921-318
> Fax +49 30 283921-29
>
> Aperto GmbH – An IBM Company
> Chausseestraße 5, D-10115 Berlin
> http://www.aperto.com<http://www.aperto.de/>
> http://www.facebook.com/aperto
> https://www.xing.com/companies/apertoag
>
> HRB 77049 B, AG Berlin Charlottenburg
> Geschäftsführer: Dirk Buddensiek, Kai Großmann, Stephan Haagen, Daniel
> Simon
>
>
>
> ---
>
> Dipl. Inf. Jörg von Frantzius, Technical Director
>
> E-Mail joerg.frantzius at aperto.com
>
> Phone +49 30 283921-318
> Fax +49 30 283921-29
>
> Aperto GmbH – An IBM Company
> Chausseestraße 5, D-10115 Berlin
> http://www.aperto.com<http://www.aperto.de/>
> http://www.facebook.com/aperto
> https://www.xing.com/companies/apertoag
>
> HRB 77049 B, AG Berlin Charlottenburg
> Geschäftsführer: Dirk Buddensiek, Kai Großmann, Stephan Haagen, Daniel
> Simon
>
>

-- 
"Esta mensagem, incluindo seus anexos, pode conter informacoes 
confidenciais e privilegiadas. 
Se voce a recebeu por engano, solicitamos que a apague e avise o remetente 
imediatamente. 
Opinioes ou informacoes aqui contidas nao refletem necessariamente a 
posicao oficial da Plusoft."

"Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO 
AMBIENTE"