[ 
https://issues.apache.org/jira/browse/NIFI-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Percivall updated NIFI-3406:
-----------------------------------
    Description: 
The issue prompting this is that JRuby's default configuration uses a Singleton 
scope[1]. So all threads will see the same runtime and variables. This means if 
a FlowFile is currently running within the body of a script, and a new one 
comes in, the first thread will use the new variables (session, flowfile, 
etc.). This is obviously a problem and can lead "flowfile not known in this 
session" and livelocks in the FF repo due to multiple sessions updating the 
same flowfile[2].

ExecuteScript needs to 
   1: give more information about the script engine being run
   2: provide more configuration options for the script engine it self
   3: warn the user about the nuances of script engines and how they are not 
maintained by Apache NiFi so may not follow our best practices.

This also probably

[1] 
https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L198

Specifically the line: "However, the default, singleton local context scope 
behave slightly different. If Ruby runtime has been already instantiated by 
another ScriptingContainer, application, etc, the same runtime will be used."
[2] 
https://github.com/JPercivall/nifi/blob/1be08714731f01347ac1f98e18047fe7d9ab8afd/nifi-commons/nifi-write-ahead-log/src/main/java/org/wali/MinimalLockingWriteAheadLog.java#L69-L69

  was:
The issue prompting this is that JRuby's default configuration uses a Singleton 
scope[1]. So all threads will see the same runtime and variables. This means if 
a FlowFile is currently running within the body of a script, and a new one 
comes in, the first thread will use the new variables (session, flowfile, 
etc.). This is obviously a problem and can lead "flowfile not known in this 
session" and livelocks in the FF repo due to multiple sessions updating the 
same flowfile[2].

ExecuteScript needs to 
   1: give more information about the script engine being run
   2: provide more configuration options for the script engine it self
   3: warn the user about the nuances of script engines and how they are not 
maintained by Apache NiFi so may not follow our best practices.

[1] 
https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L198

Specifically the line: "However, the default, singleton local context scope 
behave slightly different. If Ruby runtime has been already instantiated by 
another ScriptingContainer, application, etc, the same runtime will be used."
[2] 
https://github.com/JPercivall/nifi/blob/1be08714731f01347ac1f98e18047fe7d9ab8afd/nifi-commons/nifi-write-ahead-log/src/main/java/org/wali/MinimalLockingWriteAheadLog.java#L69-L69


> Multiple Improvements needed to ExecuteScript ScriptEngines 
> configuration/information
> -------------------------------------------------------------------------------------
>
>                 Key: NIFI-3406
>                 URL: https://issues.apache.org/jira/browse/NIFI-3406
>             Project: Apache NiFi
>          Issue Type: Improvement
>    Affects Versions: 1.1.1
>            Reporter: Joseph Percivall
>            Priority: Blocker
>
> The issue prompting this is that JRuby's default configuration uses a 
> Singleton scope[1]. So all threads will see the same runtime and variables. 
> This means if a FlowFile is currently running within the body of a script, 
> and a new one comes in, the first thread will use the new variables (session, 
> flowfile, etc.). This is obviously a problem and can lead "flowfile not known 
> in this session" and livelocks in the FF repo due to multiple sessions 
> updating the same flowfile[2].
> ExecuteScript needs to 
>    1: give more information about the script engine being run
>    2: provide more configuration options for the script engine it self
>    3: warn the user about the nuances of script engines and how they are not 
> maintained by Apache NiFi so may not follow our best practices.
> This also probably
> [1] 
> https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L198
> Specifically the line: "However, the default, singleton local context scope 
> behave slightly different. If Ruby runtime has been already instantiated by 
> another ScriptingContainer, application, etc, the same runtime will be used."
> [2] 
> https://github.com/JPercivall/nifi/blob/1be08714731f01347ac1f98e18047fe7d9ab8afd/nifi-commons/nifi-write-ahead-log/src/main/java/org/wali/MinimalLockingWriteAheadLog.java#L69-L69



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to