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

Standup 10/5/2009

Mike Grafton
Tuesday, October 6, 2009

Help

Has anybody seen memcache clients suddenly stop being able to talk to the memcached server and mark it as dead?

In fact many people have seen this. The Pivot with the question is using the memcached gem, while others noted that the memcache-client gem had special retry logic within it to deal with such a situation. In the latter case, some have still seen connections to memcache timeout despite the retry logic and despite the fact that memcache appears to be up and operational by all other checks.

That being said, nobody had any notion of what the root cause was – anybody out on the interwebs have insight on this?


Anybody seen random segmentation faults and bus errors happening in Ruby?

One of our projects is seeing intermittent crashing of the Ruby interpreter (MRI) while running the app. It seems to happen in a random place inside of Rails, but never the exact same place. We can’t find anything suspicious about the code where it is crashing.

It was noted that the project in question is using libxml (to support Nokogiri) and that various combinations of libxml and MRI are known to be incompatible; in fact a few previous Blabs posts exist on this subject. However, in this case the crashes do not happen deterministically, which is unlike the cases described previously.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

One comment

  1. Brian Doll says:

    I’ve had similar issues using a recent memcache-client gem (1.7.4, 1.7.5) where timeout’s occur for unknown reasons. These versions use ruby’s timeout library which is known to be less than stellar. The author, Mike Pernham, had made attempts at using SO_SNDTIMEO and SO_RCVTIMEO socket options instead, but found that they were not supported everywhere (Solaris) and had other issues:
    http://www.mikeperham.com/2009/03/15/socket-timeouts-in-ruby/

    If for you, the real issue isn’t the occasional timeout, but the exception that’s being thrown when you get a timeout (MemCache::MemCacheError: IO timeout), be sure to set raise_errors to false in config/memcached.yml for non-development environments.

    October 6, 2009 at 1:26 pm

Add New Comment Cancel reply

Your email address will not be published.

Mike Grafton

Mike Grafton
San Francisco

Recent Posts

  • SF Standup 5/6/2011: Bundler Blah Blah Blah Blah
  • SF Standup 5/5/2011: The Most Interesting Standup in the World
  • SF Standup 5/4/2011: Tête-à-tête
Subscribe to Mike's Feed

Author Topics

agile (5)
bundler (2)
jquery (1)
ikea (1)
pairing (1)
amazon cloudfront (1)
internet explorer (1)
paperclip (1)
chef (2)
engineyard (1)
fast_xs (1)
rails (5)
activerecord (1)
rvm (1)
memcache (1)
etags (1)
haproxy (1)
mongrel (1)
selenium (1)
imagemagick (1)
jolt awards (1)
mac (1)
rubymine (1)
jruby (1)
postgres (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 >