JRuby

ActiveMessaging poller stops silently with JRuby 1.3.0RC1 and RC2. Works with JRuby 1.2.0

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.3RC1
  • Fix Version/s: JRuby 1.3
  • Component/s: Application Error
  • Labels:
    None
  • Environment:
    Fedora 10, Sun Java 1.6.0_13, JRuby 1.3.0RC1 and RC2, Rails 2.3.2, ActiveMessaging
  • Number of attachments :
    0

Description

We start the ActiveMessaging poller with

jruby --server script/jruby_poller

After running for few seconds, the java process dies. No output in stdout or stderr.

I'll investigate further.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Uwe Kubosch added a comment -

The code that fails relies on thread#alive?

Have you done anything to this since 1.2.0?

Show
Uwe Kubosch added a comment - The code that fails relies on thread#alive? Have you done anything to this since 1.2.0?
Hide
Permalink
Uwe Kubosch added a comment -

Found an error:

uninitialized class variable @@running in #<Class:01x1978611>

The variable is initialized. Here is the code:

http://gist.github.com/119648

The error occurs in line 32.

Show
Uwe Kubosch added a comment - Found an error: uninitialized class variable @@running in #<Class:01x1978611> The variable is initialized. Here is the code: http://gist.github.com/119648 The error occurs in line 32.
Hide
Permalink
Uwe Kubosch added a comment -

Here is a minimal example that fails:

module ActiveMessaging
  class Gateway
    @@running = true
    class <<self
      def start
        Thread.start do
          begin
            puts @@running
          rescue Object
            puts $!.message
            puts $!.backtrace.join("\n")
          end
        end
      end
    end
  end
end

ActiveMessaging::Gateway.start
sleep 2
Show
Uwe Kubosch added a comment - Here is a minimal example that fails: 
module ActiveMessaging
  class Gateway
    @@running = true
    class <<self
      def start
        Thread.start do
          begin
            puts @@running
          rescue Object
            puts $!.message
            puts $!.backtrace.join("\n")
          end
        end
      end
    end
  end
end

ActiveMessaging::Gateway.start
sleep 2
Hide
Permalink
Charles Oliver Nutter added a comment -

Hmm, ok...this is another problem with class variables. I hate class variables.

I think we need to fix this before 1.3 final.

Show
Charles Oliver Nutter added a comment - Hmm, ok...this is another problem with class variables. I hate class variables. I think we need to fix this before 1.3 final.
Hide
Permalink
Charles Oliver Nutter added a comment -

I've got a test case that illustrates this pretty succinctly:

require 'test/unit'

class TestClassVars < Test::Unit::TestCase
  def test_thread_in_eigenclass
    result = Class.new do
      @@running = true
      class << self
        Thread.new do
          @@running
        end.join
      end
    end

    assert_equal true, result
  end

  def test_thread_in_method_in_eigenclass
    result = Class.new do
      @@running = true
      class << self
        def go
          Thread.new do
            p @@running
          end.join
        end
      end
    end.go

    assert_equal true, result
  end
end

It seems like it's something to do with the thread; any other block in there works fine. Perhaps the thread's block is getting mutilated in some way that damages cvar lookup?

Show
Charles Oliver Nutter added a comment - I've got a test case that illustrates this pretty succinctly: 
require 'test/unit'

class TestClassVars < Test::Unit::TestCase
  def test_thread_in_eigenclass
    result = Class.new do
      @@running = true
      class << self
        Thread.new do
          @@running
        end.join
      end
    end

    assert_equal true, result
  end

  def test_thread_in_method_in_eigenclass
    result = Class.new do
      @@running = true
      class << self
        def go
          Thread.new do
            p @@running
          end.join
        end
      end
    end.go

    assert_equal true, result
  end
end
It seems like it's something to do with the thread; any other block in there works fine. Perhaps the thread's block is getting mutilated in some way that damages cvar lookup?
Hide
Permalink
Charles Oliver Nutter added a comment -

Fixed! The problem was that when we duplicated the scope for a thread (to fix backref/lastline scoping) we did not also copy the previousCRefScope, which meant that class vars were not being looked up correctly at the top level of a Thread's block. I also added tests for it in test_cvar_in_weird_scopes.

Show
Charles Oliver Nutter added a comment - Fixed! The problem was that when we duplicated the scope for a thread (to fix backref/lastline scoping) we did not also copy the previousCRefScope, which meant that class vars were not being looked up correctly at the top level of a Thread's block. I also added tests for it in test_cvar_in_weird_scopes.
Hide
Permalink
Uwe Kubosch added a comment -

Thanks!

Show
Uwe Kubosch added a comment - Thanks!

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.