Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

SF Standup 3/1/2010: JRuby skips ensure blocks when killed

Jacob Maine
Monday, March 1, 2010

When you kill a JRuby process (e.g. with a SIGINT) you can’t bank on ensure blocks being executed. Of course, this is worrisome – file handles and other connections won’t be closed. The problem boils down to this example:

$ cat kill_me.rb
begin
  sleep
ensure
  puts 'executed ensure'
end
$
$ ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
$
$ ruby kill_me.rb
^Cexecuted ensure
kill_me.rb:2:in `sleep': Interrupt
    from kill_me.rb:2
$
$ jruby -v
jruby 1.4.0 (ruby 1.8.7 patchlevel 174) (2009-11-02 69fbfa3) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_13) [x86_64-java]
$
$ jruby kill_me.rb
^C$
  • 0 Shares
  • Share on Facebook
  • Share on Twitter

4 Comments

  1. Mike Perham says:

    File handles and descriptors are associated with the process. The OS will clean them up when the process dies.

    March 1, 2010 at 12:16 pm

  2. Abhi Hiremagalur says:

    @Mike In the specific case that led us to this issue we were trying to ensure a connection to a JMS queue is closed gracefully; unfortunately this isn’t something the OS does when the JRuby process dies.

    March 1, 2010 at 1:54 pm

  3. Mike Perham says:

    When the process dies, the OS should close the socket and the JMS process on the other machine get notified of the socket closure. That’s the whole point of TCP (the infamous ‘remote server closed socket unexpectedly’ error). Now of course your JMS server might misbehave in this case…

    March 2, 2010 at 10:43 am

  4. Jacob Maine says:

    For a more detailed discussion, check out the [JRuby dev mailing list](http://archive.codehaus.org/lists/org.codehaus.jruby.dev).

    @Mike Good point – things get cleaned up eventually, although not very gracefully. But there are a lot of scenarios where app code would want to tidy up after itself (delete files, etc.) that would be skipped if it were in the rescue/ensure blocks. In this case, we’re trying to be polite to the JMS server which, as you suggested, complains when we drop connections abruptly. Fortunately, there are work-arounds (register finalizers and/or write our own signal trapping).

    As we’ve researched, we’ve decided that it’s an expectations problem. As a Ruby programmer, I expect signals to raise Ruby exceptions, and trigger ensure blocks. But Java programmers have different expectations. So, it depends on whether you focus on the J(VM) part or Ruby part of JRuby.

    March 3, 2010 at 1:54 pm

Add New Comment Cancel reply

Your email address will not be published.

Jacob Maine

Jacob Maine
Boston

Recent Posts

  • Standup 2012/2/1: Speed kills
  • Standup 2012/1/31: The bleeding edge
  • Standup 1/30/2012: It’s all about sharing
Subscribe to Jacob's Feed

Author Topics

agile (14)
testing (6)
rails (2)
prototype (2)
jruby (1)
hpricot (1)
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >