jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • JRuby
  • JRUBY-823

Threaderror invoking singleton (different behaviour than MRI)

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: JRuby 0.9.9
  • Fix Version/s: JRuby 1.0.0RC2
  • Component/s: Core Classes/Modules
  • Labels:
    None
  • Environment:
    jdk1.5.08
    rails 1.2.3

Description

The following occurs within a rails project:

From within environment.rb, place the following:

MANAGER_PREFS = {
:development => {
:threads => 10,
:root_dir => "/jboss/deploy",
:util_dir => "/usr2/bea/bin"
},
:test => { },
:production => { }
}

if ENV['RAILS_ENV'] != nil
require "lib/manager"
MANAGER=Manager.instance
end

Here's the snippet of Manager which is causing theissue:

  1. manager
    require 'singleton'
    require 'socket'
    require 'thread'
    require 'threadpool'
    require 'logger'
    require 'tasker'
  2. The manager uses the MANAGER_PREFS variable defined in the
  3. config/environment.rb
  1. The manager has two parts:
  2. + the first periodically checks for servers which
  3. are managed and checks to see if they are running
  4. + the second looks in the tasks table for tasks to be
  5. performed and performs the tasks
    class Manager < Thread
    include Singleton

def initialize()
@logger = RAILS_DEFAULT_LOGGER

  1. $DEBUG = true
    pool_size = MANAGER_PREFS[ENV['RAILS_ENV'].to_sym][:threads] || 10
    @pool = ThreadPool.new(pool_size,@logger)
    @continue = true
    @tasker = Tasker.instance
    super do
    cycle = 0
    @logger.debug "Manager is sleeping for 60 seconds to give system time to stabilize"
    sleep 60 # give time to stabilize
    @logger.debug "Manager is now awake"
    while @continue do
    @logger.debug "Manager doing stuff: #{cycle}"
  2. set true by default
    monitor_active = false # fixme
    tasker_active = true
    begin
    settings = GlobalSetting.find_first
    @logger.debug "Manager: #{settings.inspect}"
    monitor_active = settings.monitor_active
    tasker_active = settings.tasker_active
    rescue Exception => e
    @logger.info "Manager: Exception occurred reading global settings: #{e.message}"
    @logger.info "Manager: Exception Backtrace:\n #{e.backtrace.inspect}"
    end
    check_managed_servers if ((cycle == 0) && (monitor_active))
    @logger.debug "Manager stage 1"
    perform_tasks if tasker_active
    @logger.debug "Manager sleeping"
    sleep 10
    cycle = (cycle + 1) % 6
    end
    @logger.debug "Manager Finished"
    end
    end
    end

Here's the stack trace:
/usr2/common/jruby/lib/ruby/1.8/singleton.rb:95:in `new': must be called with a block (ThreadError)
from /usr2/common/jruby/lib/ruby/1.8/singleton.rb:95:in `instance'
from /usr2/common/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `instance'
from ./script/../config/../config/environment.rb:106
from /usr2/common/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from /usr2/common/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from /usr2/common/jruby/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/commands/servers/webrick.rb:52
from /usr2/common/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from /usr2/common/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from /usr2/common/jruby/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/commands/server.rb:39
from /usr2/common/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from /usr2/common/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
from script/server:2

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Matt Williams added a comment - 16/Apr/07 10:02 AM

I ripped out the Singleton code, and it's complaining yet – it seems as though the root cause is that Manager is a child of Thread and while I'm calling super with a block, it's not good enough........

I know that there's differences between MRI and jruby's threading; I'm guessing that I've run into it..... Still, figure y'all would like to know

Show
Matt Williams added a comment - 16/Apr/07 10:02 AM I ripped out the Singleton code, and it's complaining yet – it seems as though the root cause is that Manager is a child of Thread and while I'm calling super with a block, it's not good enough........ I know that there's differences between MRI and jruby's threading; I'm guessing that I've run into it..... Still, figure y'all would like to know
Hide
Permalink
Charles Oliver Nutter added a comment - 16/Apr/07 1:48 PM

This seems like something really small. The following fails also:

class MyThread < Thread; def initialize(); super do; puts 'hello'; end; end; end; MyThread.new

So I think it's a simple zsuper issue again, where we're not passing the block through super to Thread.new correctly.

This shouldn't be too hard to fix.

Show
Charles Oliver Nutter added a comment - 16/Apr/07 1:48 PM This seems like something really small. The following fails also:
class MyThread < Thread; def initialize(); super do; puts 'hello'; end; end; end; MyThread.new
So I think it's a simple zsuper issue again, where we're not passing the block through super to Thread.new correctly. This shouldn't be too hard to fix.
Hide
Permalink
Charles Oliver Nutter added a comment - 05/May/07 6:42 PM

Moving to post RC but marking critical.

Show
Charles Oliver Nutter added a comment - 05/May/07 6:42 PM Moving to post RC but marking critical.
Hide
Permalink
Charles Oliver Nutter added a comment - 16/May/07 1:37 PM

Actually this isn't a zsuper issue, it's an issue where Thread::new checks whether a block was passed, rather than allowing initialize to make that determination. This prevents overriding initialize to not require a block. I will commit a fix that makes Thread::new call initialize correctly, along with a test case based on the reduced case.

Show
Charles Oliver Nutter added a comment - 16/May/07 1:37 PM Actually this isn't a zsuper issue, it's an issue where Thread::new checks whether a block was passed, rather than allowing initialize to make that determination. This prevents overriding initialize to not require a block. I will commit a fix that makes Thread::new call initialize correctly, along with a test case based on the reduced case.
Hide
Permalink
Charles Oliver Nutter added a comment - 16/May/07 1:52 PM

Fixed in 3665.

Show
Charles Oliver Nutter added a comment - 16/May/07 1:52 PM Fixed in 3665.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Matt Williams
Vote (0)
Watch (0)

Dates

  • Created:
    16/Apr/07 9:43 AM
    Updated:
    22/May/07 5:51 PM
    Resolved:
    16/May/07 1:52 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.