[
https://issues.apache.org/jira/browse/CAMEL-10829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Antinori updated CAMEL-10829:
-----------------------------------
Description:
There is a rare to hit issue with {{camel-script}} component and {{jruby}}.
{{camel-script}} passes through this method chain to create a {{jruby}}
{{ScriptEngine}}:
https://github.com/apache/camel/blob/master/components/camel-script/src/main/java/org/apache/camel/builder/script/ScriptBuilder.java#L267-L269
{code:java}
public static boolean supportScriptLanguage(String language) {
return createScriptEngine(language, true) != null;
}
{code}
*The problem with that code is that it creates a Script Engine instance, but it
doesn't keep a reference to that object.*
JRuby gives a specialized behavior to {{finalize()}} method of its runtime:
https://github.com/jruby/jruby/blob/jruby-1_7/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L1907-L1929
The combination of the 2 conditions is able to cause situation where the
{{gc()}} thread, reaps JRuby instances, triggering their clean up methods:
https://github.com/jruby/jruby/blob/jruby-1_7/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L1907-L1929t
before Camel has really finished using it.
This behavior can be noticed in
https://github.com/apache/camel/blob/master/components/camel-script/src/test/java/org/apache/camel/builder/script/JRubySingletonTest.java
failing every now and then. Event more frequent when we tried to upgrade to
jruby 1.7.26:
https://issues.apache.org/jira/browse/CAMEL-10477
{code}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.apache.camel.builder.script.ScriptBuilder.tryCreateScriptEngine(ScriptBuilder.java:359)
at
org.apache.camel.builder.script.ScriptBuilder.createScriptEngine(ScriptBuilder.java:336)
at
org.apache.camel.builder.script.ScriptBuilder.supportScriptLanguage(ScriptBuilder.java:268)
at
org.apache.camel.builder.script.ScriptLanguageResolver.resolveLanguage(ScriptLanguageResolver.java:30)
at
org.apache.camel.builder.script.RubyLanguage.createExpression(RubyLanguage.java:38)
at
org.apache.camel.component.language.LanguageEndpoint.createProducer(LanguageEndpoint.java:96)
at
org.apache.camel.impl.ProducerCache.doGetProducer(ProducerCache.java:439)
- locked <0x1806> (a org.apache.camel.impl.ProducerCache)
at
org.apache.camel.impl.ProducerCache.acquireProducer(ProducerCache.java:160)
at
org.apache.camel.processor.SendProcessor.doStart(SendProcessor.java:243)
{code}
Now, I honestly don't know if this should be fixed on Camel side (and reason if
the scripting API needs to be changed for other runtimes too), or this should
be handled on JRuby one.
was:
There is a rare to hit issue with {{camel-script}} component and {{jruby}}.
{{camel-script}} passes through this method chain to create a {{jruby}}
{{ScriptEngine}}:
https://github.com/apache/camel/blob/master/components/camel-script/src/main/java/org/apache/camel/builder/script/ScriptBuilder.java#L267-L269
{code:java}
public static boolean supportScriptLanguage(String language) {
return createScriptEngine(language, true) != null;
}
{code}
The problem with that code is that it creates a Script Engine instance, but it
doesn't keep a reference to that object.
JRuby gives a specialized behavior to {{finalize()}} method of its runtime:
https://github.com/jruby/jruby/blob/jruby-1_7/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L1907-L1929
The combination of the 2 conditions is able to cause situation where the
{{gc()}} thread, reaps JRuby instances, triggering their clean up methods:
https://github.com/jruby/jruby/blob/jruby-1_7/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L1907-L1929t
before Camel has really finished using it.
This behavior can be noticed in
https://github.com/apache/camel/blob/master/components/camel-script/src/test/java/org/apache/camel/builder/script/JRubySingletonTest.java
failing every now and then. Event more frequent when we tried to upgrade to
jruby 1.7.26:
https://issues.apache.org/jira/browse/CAMEL-10477
{code}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.apache.camel.builder.script.ScriptBuilder.tryCreateScriptEngine(ScriptBuilder.java:359)
at
org.apache.camel.builder.script.ScriptBuilder.createScriptEngine(ScriptBuilder.java:336)
at
org.apache.camel.builder.script.ScriptBuilder.supportScriptLanguage(ScriptBuilder.java:268)
at
org.apache.camel.builder.script.ScriptLanguageResolver.resolveLanguage(ScriptLanguageResolver.java:30)
at
org.apache.camel.builder.script.RubyLanguage.createExpression(RubyLanguage.java:38)
at
org.apache.camel.component.language.LanguageEndpoint.createProducer(LanguageEndpoint.java:96)
at
org.apache.camel.impl.ProducerCache.doGetProducer(ProducerCache.java:439)
- locked <0x1806> (a org.apache.camel.impl.ProducerCache)
at
org.apache.camel.impl.ProducerCache.acquireProducer(ProducerCache.java:160)
at
org.apache.camel.processor.SendProcessor.doStart(SendProcessor.java:243)
{code}
Now, I honestly don't know if this should be fixed on Camel side, or if
{{finalize()}} or if this should be handled on JRuby one.
> [jruby] Issue with multithreading and finalize()
> ------------------------------------------------
>
> Key: CAMEL-10829
> URL: https://issues.apache.org/jira/browse/CAMEL-10829
> Project: Camel
> Issue Type: Bug
> Components: camel-script
> Affects Versions: 2.18.2
> Reporter: Paolo Antinori
>
> There is a rare to hit issue with {{camel-script}} component and {{jruby}}.
> {{camel-script}} passes through this method chain to create a {{jruby}}
> {{ScriptEngine}}:
> https://github.com/apache/camel/blob/master/components/camel-script/src/main/java/org/apache/camel/builder/script/ScriptBuilder.java#L267-L269
> {code:java}
> public static boolean supportScriptLanguage(String language) {
> return createScriptEngine(language, true) != null;
> }
> {code}
> *The problem with that code is that it creates a Script Engine instance, but
> it doesn't keep a reference to that object.*
> JRuby gives a specialized behavior to {{finalize()}} method of its runtime:
> https://github.com/jruby/jruby/blob/jruby-1_7/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L1907-L1929
> The combination of the 2 conditions is able to cause situation where the
> {{gc()}} thread, reaps JRuby instances, triggering their clean up methods:
> https://github.com/jruby/jruby/blob/jruby-1_7/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L1907-L1929t
> before Camel has really finished using it.
> This behavior can be noticed in
> https://github.com/apache/camel/blob/master/components/camel-script/src/test/java/org/apache/camel/builder/script/JRubySingletonTest.java
> failing every now and then. Event more frequent when we tried to upgrade to
> jruby 1.7.26:
> https://issues.apache.org/jira/browse/CAMEL-10477
> {code}
> "main@1" prio=5 tid=0x1 nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.camel.builder.script.ScriptBuilder.tryCreateScriptEngine(ScriptBuilder.java:359)
> at
> org.apache.camel.builder.script.ScriptBuilder.createScriptEngine(ScriptBuilder.java:336)
> at
> org.apache.camel.builder.script.ScriptBuilder.supportScriptLanguage(ScriptBuilder.java:268)
> at
> org.apache.camel.builder.script.ScriptLanguageResolver.resolveLanguage(ScriptLanguageResolver.java:30)
> at
> org.apache.camel.builder.script.RubyLanguage.createExpression(RubyLanguage.java:38)
> at
> org.apache.camel.component.language.LanguageEndpoint.createProducer(LanguageEndpoint.java:96)
> at
> org.apache.camel.impl.ProducerCache.doGetProducer(ProducerCache.java:439)
> - locked <0x1806> (a org.apache.camel.impl.ProducerCache)
> at
> org.apache.camel.impl.ProducerCache.acquireProducer(ProducerCache.java:160)
> at
> org.apache.camel.processor.SendProcessor.doStart(SendProcessor.java:243)
> {code}
> Now, I honestly don't know if this should be fixed on Camel side (and reason
> if the scripting API needs to be changed for other runtimes too), or this
> should be handled on JRuby one.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
