camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paolo Antinori (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-10829) [jruby] Issue with multithreading and finalize()
Date Tue, 14 Feb 2017 12:51:41 GMT

     [ 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)

Mime
View raw message