petergoldstein/dalli

High performance memcached client for Ruby

Dalli

Dalli is a high performance pure Ruby client for accessing memcached servers.

Dalli supports:

• Simple and complex memcached configurations
• Failover between memcached instances
• Fine-grained control of data serialization and compression
• Thread-safe operation (either through use of a connection pool, or by using the Dalli client in threadsafe mode)
• SSL/TLS connections to memcached
• SASL authentication

The name is a variant of Salvador Dali for his famous painting The Persistence of Memory.

Documentation and Information

• User Documentation - The documentation is maintained in the repository's wiki.
• Announcements - Announcements of interest to the Dalli community will be posted here.
• Bug Reports - If you discover a problem with Dalli, please submit a bug report in the tracker.
• Forum - If you have questions about Dalli, please post them here.
• Client API - Ruby documentation for the Dalli::Client API

Development

After checking out the repo, run bin/setup to install dependencies. You can run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install.

Contributing

If you have a fix you wish to provide, please fork the code, fix in your local project and then send a pull request on github. Please ensure that you include a test which verifies your fix and update the changelog with a one sentence description of your fix so you get credit as a contributor.

Appreciation

Dalli would not exist in its current form without the contributions of many people. But special thanks go to several individuals and organizations:

• Mike Perham - for originally authoring the Dalli project and serving as maintainer and primary contributor for many years
• Eric Wong - for help using his kgio library.
• Brian Mitchell - for his remix-stash project which was helpful when implementing and testing the binary protocol support.
• CouchBase - for their sponsorship of the original development

Authors

• Peter M. Goldstein - current maintainer
• Mike Perham and contributors

Copyright

Copyright (c) Mike Perham, Peter M. Goldstein. See LICENSE for details.

dalli's Issues

ActiveSupport::Cache::DalliStore doesnt implement reset properly

The docs for Dalli suggest that when used with Phusion Passenger some post-spawning code should be executed to reset the client,

    if defined?(PhusionPassenger)
      PhusionPassenger.on_event(:starting_worker_process) do |forked|
        # Only works with DalliStore
        Rails.cache.reset if forked
      end
    end

However, the reset method as implemented is

  def reset
    @pool.reset
  end

And @pool is never initialized, which raises the exception:

irb(main):001:0> Rails.cache.reset
NoMethodError: undefined method `reset' for nil:NilClass
from /Library/Ruby/Gems/1.8/gems/activesupport-3.0.0/lib/active_support/whiny_nil.rb:48:in `method_missing'
from /Library/Ruby/Gems/1.8/gems/dalli-0.9.4/lib/active_support/cache/dalli_store.rb:114:in `reset'
from (irb):1

Invalid Memcache version lets rails server hang

Ruby 1.9.2, Rails 3.0.1, Dalli latest, memcache 1.2.8

Server spins. Looks like the request hangs up, but the browser and server are left spinning.

Expire sessions in rails 2.3.9

How does one configure dalli session store to expire sessions in rails 2.3.9?

Placing the following in the production.rb throws an error:

require 'action_controller/session/dalli_store'
ActionController::Base.session_store = :dalli_store, :expires_in => 5.seconds

Error:
syntax error, unexpected tASSOC, expecting $end (SyntaxError)
... = :dalli_store, :expires_in => 5.seconds,
... ^

and formatting the production.rb as:

require 'action_controller/session/dalli_store'
ActionController::Base.session_store = :dalli_store,{:expires_in => 5.seconds}

does not appear to expire the session.

Thanks

Josh

Support for compression

Hi, something like the following will add a support for compression. You'll probably want to import the activesupport/lib/active_support/gzip.rb file (it has only 24 lines) to keep the client independent on rails.

This also supports a :nocompress option if the client defaults to :compress, but i am not sure, if it is really useful.

--- dalli-0.10.1/lib/dalli/client.rb-orig   2010-10-28 15:08:18.000000000 +0200
+++ dalli-0.10.1/lib/dalli/client.rb        2010-10-28 15:22:57.000000000 +0200
@@ -159,11 +159,23 @@
     end

     def serialize(value, options)
-      options && options[:raw] ? value.to_s : ::Marshal.dump(value)
+      if options && options[:raw]
+        value.to_s
+      elsif (options && options[:compress]) || (@options && @options[:compress] && (!options || !options[:nocompress]))
+        ActiveSupport::Gzip.compress(::Marshal.dump(value))
+      else
+        ::Marshal.dump(value)
+      end
     end

     def deserialize(value, options)
-      options && options[:raw] ? value : ::Marshal.load(value)
+      if options && options[:raw]
+        value
+      elsif (options && options[:compress]) || (@options && @options[:compress] && (!options || !options[:nocompress]))
+        ::Marshal.load(ActiveSupport::Gzip.decompress(value))
+      else
+        ::Marshal.load(value)
+      end
     rescue TypeError
       raise Dalli::DalliError, "Invalid marshalled data in memcached: #{value}"
     end

Is there any docs on how to use this with rails 2.3.5?

Just the basics..the read me isn't clear in terms how to initialize, get, set, fetch etc.

Thanks, this looks very promising!

Any plans on implementing namespacing?

We depend on namespacing to expire keys during deployment. Do you have any plans on implementing this feature?

dalli_store losing entries between requests?

I'm on Rails 2.3.10.

So, in my controller, I have some very simple code:

@something = Rails.cache.read("something_1")
if @something.nil?
  @something = Something.find 1
  Rails.cache.write("something_1", @something)
end

With config.cache_store :dalli_store, I get a cache miss every time. With :memory_store, it works properly, so I don't think I have any larger config issues.

What's even stranger is this: when I put in debugger, and step through, I see the cache miss, I see it getting put in... and then, on the line after the write, if I do a read, it returns the proper @something.

Am I doing something stupid?

Session::DalliStore#get: 127.0.0.1:11211 is currently down:

We're running jruby+warbler+RESIN, it works fine with development mode. but on stagging, we bumped into the following error.

Session::DalliStore#get: 127.0.0.1:11211 is currently down: NoMethodError undefined method `connect_nonblock' for #Dalli::Server::KSocket:0x61642df5

Any hint will be appreciated!

Is version 0.9.3 available on rubygems.org

I think I am using version 0.9.2 and get the following error on start up

/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in gem_original_require': no such file to load -- active_support/cache/dalli_store23 (MissingSourceFile) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:inrequire'
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in require' from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:521:innew_constants_in'
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require'

Cannot use anything but localhost as session store?

Trying your examples, both in the code comments and the README

require 'action_dispatch/middleware/session/dalli_store'
Iwp::Application.config.session_store :dalli_store, ['itwebpriv1:11211', 'itwebpriv2:11211'], :key => '_iwp_session', :expire_after => 1.day

Gives me:
dalli-0.9.10/lib/action_dispatch/middleware/session/dalli_store.rb:14:in `[]': can't convert Symbol into Integer (TypeError)

Also the code examples in the commends and the readme are different. Maybe a good idea to use the same examples in both places?

and in the readme for session store with dalli

Namespacing

Does this library support namespacing your keys like the default Rails memcache library?

Memcached YAML file usage?

Can Dalli use existing memcached.yml file? If so, do you have any instructions for adding Dalli specific options?

Unexpected exception in Dalli

Unexpected exception in Dalli: TypeError: no marshal_dump is defined for class Proc
183892307-This is a bug in Dalli, please enter an issue in Github if it does not already exist.
183892393:/XXXXXXXXXX/vendor/bundle/ruby/1.9.1/gems/dalli-1.0.0/lib/dalli/server.rb:249:in dump' 183892507: /XXXXXXXXXX/vendor/bundle/ruby/1.9.1/gems/dalli-1.0.0/lib/dalli/server.rb:249:inserialize'
183892627: /XXXXXXXXXX/vendor/bundle/ruby/1.9.1/gems/dalli-1.0.0/lib/dalli/server.rb:143:in set' 183892741: /XXXXXXXXXX/vendor/bundle/ruby/1.9.1/gems/dalli-1.0.0/lib/dalli/server.rb:39:inrequest'
183892858: /XXXXXXXXXX/vendor/bundle/ruby/1.9.1/gems/dalli-1.0.0/lib/dalli/options.rb:14:in block in request' 183892985- /home/ubuntu/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/monitor.rb:201:inmon_synchronize'
183893076: /XXXXXXXXXX/vendor/bundle/ruby/1.9.1/gems/dalli-1.0.0/lib/dalli/options.rb:13:in request' 183893194: /XXXXXXXXXX/vendor/bundle/ruby/1.9.1/gems/dalli-1.0.0/lib/dalli/client.rb:227:inperform'
183893312: /XXXXXXXXXX/vendor/bundle/ruby/1.9.1/gems/dalli-1.0.0/lib/dalli/client.rb:111:in set' 183893426- (eval):7:inblock in set_with_newrelic_trace'
183893474- /XXXXXXXXXX/vendor/bundle/ruby/1.9.1/gems/newrelic_rpm-2.13.3/lib/new_relic/agent/method_tracer.rb:141:in trace_execution_scoped' 183893632- (eval):4:inset_with_newrelic_trace'

Passenger smart spawn forking protection

memcache-client had some special stuff you had to do to make sure that when passenger forked, the memcache connection was maintained. It would be good to make sure it exists here as well.

invalid multibyte escape: /[\x00-\x20\x80-\xFF]/ (SyntaxError)

Running ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0] with RUBYOPT="-Ku" and Rails 3.0.1. Installed Dalli gem, configured development env as stated in documentation, and then trying to run rails server:

[~/work/r] rails server
/Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/dalli-0.11.0/lib/dalli.rb:1:in `require': /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/dalli-0.11.0/lib/dalli/client.rb:204: invalid multibyte escape: /[\x00-\x20\x80-\xFF]/ (SyntaxError)
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/dalli-0.11.0/lib/dalli.rb:1:in `<top (required)>'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.3/lib/bundler/runtime.rb:64:in `require'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.3/lib/bundler/runtime.rb:64:in `block (2 levels) in require'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.3/lib/bundler/runtime.rb:62:in `each'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.3/lib/bundler/runtime.rb:62:in `block in require'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.3/lib/bundler/runtime.rb:51:in `each'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.3/lib/bundler/runtime.rb:51:in `require'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.3/lib/bundler.rb:112:in `require'
from /Users/Username/work/r/config/application.rb:7:in `<top (required)>'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/commands.rb:28:in `require'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/commands.rb:28:in `block in <top (required)>'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/commands.rb:27:in `tap'
from /Users/Username/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/commands.rb:27:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'

Adding "# encoding: ascii" at the top of the client.rb seems to help, but i'm not sure if it's the correct fix.
Any comments?..

Strange result of Rails.cache.read with dalli

My development.rb is like that simple:
config.cache_store = :dalli_store

In my controller i'm trying to store a array object in memory and returning it as array to my view, but if I debug it, return a binary object.

Rails.cache.write('presidentes', Candidato.by_cargo(:key => "Presidente"))
@Presidentes = Rails.cache.read('presidentes')
=>
--- !binary |
BAhvOiBBY3RpdmVTdXBwb3J0OjpDYWNoZTo6RW50cnkJOhBAZXhwaXJlc19p

Maybe I'm missing something in Dalli configuration.

fetch options

Does Dalli support regular options for the fetch call for example I see the following error when I try to set a :expires_in option.

CACHE.fetch ("test", :expires_in => 10.seconds) do
?> 2 + 2
end
(irb):16: warning: don't put space before argument parentheses
Unexpected exception in Dalli: TypeError: can't convert Hash into Integer
/usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/server.rb:90:in pack' /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/server.rb:90:inadd'
/usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/server.rb:23:in send' /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/server.rb:23:inrequest'
/usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/options.rb:40:in request' /usr/local/lib/ruby/1.8/monitor.rb:242:insynchronize'
/usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/options.rb:39:in request' /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/client.rb:168:inperform'
/usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/client.rb:70:in add' /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/client.rb:51:infetch'

read_multi behaving wierd

ree-1.8.7-2010.02 > Rails.cache.write('d9663f00b010473faa60b82b53918aec01ed922f', 'test')
=> true
ree-1.8.7-2010.02 > Rails.cache.read('d9663f00b010473faa60b82b53918aec01ed922f')
=> "test"
ree-1.8.7-2010.02 > Rails.cache.read_multi(['d9663f00b010473faa60b82b53918aec01ed922f'])
=> {nil=>"test"}
ree-1.8.7-2010.02 > Rails.cache.write('hej', 'test')
=> true
ree-1.8.7-2010.02 > Rails.cache.read_multi(['hej'])
=> {nil=>"test"}
ree-1.8.7-2010.02 > Rails.cache.read_multi(['hej', 'd9663f00b010473faa60b82b53918aec01ed922f'])
=> {nil=>"test"}

This is on a 2.3 rails application, it connects to the memcache instance fine. Read and writes work.

Support Ruby 2.2.x

There seems to be a strong contingency of Ruby 2.2.x users who for one reason or another can't upgrade to 2.3.

Issue with caching search results

I am not sure if this is a memcached issue or a dalli issue. Wondering if dalli freezes an object while caching it and if there is a chance it might be convering the type of the object?

I am trying to cache search results (which are of type ThininkingSphinx) but when I fetch them they come out as an Array which causes pagination issue.

More details here..

http://stackoverflow.com/questions/3756182/issue-with-thinkingsphinx-pagination-and-mecached

Not working in Rails 3.0

Hi. I'm trying to replace memcache-client with dalli gem.
My config/environments/production.rb:
config.cache_store = :dalli_store

In rails console:
ruby-1.9.2-p0 > Rails.cache.write :testing, 5
=> false

In the same console:
ruby-1.9.2-p0 > dc = Dalli::Client.new('localhost:11211')
=> #<Dalli::Client:0x0000000449eb30 @servers="localhost:11211", @options={:expires_in=>0}>
ruby-1.9.2-p0 > dc.set('abc', 123)
Dalli::NetworkError: localhost:11211 is currently down: Errno::ECONNREFUSED Connection refused - connect(2)
from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/socket.rb:54:in connect_nonblock' from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/socket.rb:54:inrescue in open'
from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/socket.rb:49:in open' from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/server.rb:359:inconnection'
from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/server.rb:336:in write' from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/server.rb:219:intext_version'
from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/server.rb:80:in detect_memcached_version' from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/server.rb:18:ininitialize'
from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/client.rb:195:in new' from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/client.rb:195:inblock in ring'
from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/client.rb:194:in map' from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/client.rb:194:inring'
from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/client.rb:212:in perform' from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/dalli-0.11.1/lib/dalli/client.rb:99:inset'
from (irb):2
from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/railties-3.0.1/lib/rails/commands/console.rb:44:in start' from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/railties-3.0.1/lib/rails/commands/console.rb:8:instart'
from /home/rails3-app/app/shared/bundle/ruby/1.9.1/gems/railties-3.0.1/lib/rails/commands.rb:23:in <top (required)>' from script/rails:6:inrequire'
from script/rails:6:in `

'

Gem memcache-client is working fine.

timeouts?

with pervious versions of memcache-client I'd run into timeout problems when the client/server connection inevitably would get off due to an extra newline slipping in somewhere/etc.

then versions were released that used the systemtimer gem to automatically timeout and reconnect if such a failure occured.

Does the new code do this? Is this no longer a problem with the binary protocol?

ActiveSupport::Cache::DalliStore marshals/unmarshals twice

I just recognized that ActiveSupport::Cache::DalliStor (at least the version for Rails 2.3) will marshal/ unmarshal all values that are read/written twice - once in the store itself and once in the client (at least you specify the :raw option). Is there any special reason to do that? Doesn't that just decrease performance? I think it would make much more sense to always use the Dalli::Client in :raw mode from the DalliStore and then marchal/unmarshal ONLY in the DalliStore.

This behavior also leads to problems when the store is used with running Memcache instances that already contain data that has been written with only one Marshal.dump. If such values are read with the DalliStore in its current state they will be Marshal.load'ed twice which will cause an exception.

15e036adbbc5bb0b2d2214ec829f739db7b234d2 breaks sishen-rtranslate

Hello! Thank you for your work on dalli!

This commit http://github.com/mperham/dalli/commit/15e036adbbc5bb0b2d2214ec829f739db7b234d2 breaks http://github.com/sishen/rtranslate :

Without commit:

$ rails c
Loading development environment (Rails 3.0.1)
irb(main):001:0> require 'rtranslate'
=> nil
irb(main):002:0> Translate.t("你好世界", "CHINESE", "ENGLISH")
=> "Hello World"

With:

$ rails c
Loading development environment (Rails 3.0.1)
irb(main):001:0> require 'rtranslate'
=> nil
irb(main):002:0> Translate.t("你好世界", "CHINESE", "ENGLISH")
=> "You"

Should be "Hello World".

NoMethodError expires_in when attempting fetch for Rails 2.3.2

I get the following on a fetch:

c = ActiveSupport::Cache.lookup_store(:dalli_store)
=> #ActiveSupport::Cache::DalliStore:0x4a15d117
c.fetch('bar') { 1 }

NoMethodError: undefined method expires_in' for #<ActiveSupport::Cache::DalliStore:0x4a15d117> from /opt/jruby-1.5.2/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/active_support/cache/dalli_store23.rb:136:inwrite'
from myapp/vendor/rails/activesupport/lib/active_support/cache/strategy/local_cache.rb:51:in write' from myapp/vendor/rails/activesupport/lib/active_support/cache.rb:153:infetch'
from (irb):14

session_store silently fails with :expire_after => 120.days

I have not done a lot of testing on this, but it took me a while to track down my particular issue. If I set the following:

Rails.application.config.session_store :dalli_store, :memcache_server => '127.0.0.1', :key => '_zedkit', :expire_after => 120.days

The Dalli session store will silently not work. No sessions get saved, Rails does not seem to even update the session with the csrf_token. If I set it to:

Rails.application.config.session_store :dalli_store, :memcache_server => '127.0.0.1', :key => '_zedkit', :expire_after => 30.days

Sessions work as expected.

In your examples all the expire_after settings are quite low, but in my case, I keep the session around for a long time to record the user login, for example, and other interface information to improve usability. I don't want the session expiring unless the user really has gone away and is not likely to come back. I would like to set an expiry much larger than 30.days even.

I have a memcache cluster that maintains the "persistence" that is good enough for these purposes. Anyway, setting a much higher expiry should work.

Of course, the issue is not likely 120.days exactly, but some length of time over 30.days that causes the issue.

Allow for multiple buckets in same client

It seems that with the current setup, you can only supply one set of credentials to the client which means that you can really only use one bucket at a time. I realize that Ruby by default only allows for one cache provider, but a few of our customers have made the necessary modifications to allow for multiple. Would it be possible to extend Dalli to allow a username/password to be supplied during the instantiation of the client so that multiple buckets could be used from the same client code?

Documentation bug

For Rails 3 I think you should use Rails.cache.clear rather than Rails.cache.reset for Phusion memcached tweak

Unexpected exception in Dalli: TypeError: no marshal_dump is defined for class Thread

Hi,

I hope this issue is no duplicate. I didn't find anything though.

I get this error when using Rails.cache.fetch in my application:
Unexpected exception in Dalli: TypeError: no marshal_dump is defined for class Thread
This is a bug in Dalli, please enter an issue in Github if it does not already exist.

This is the line in which it breaks:
Rails.cache.fetch('all_active_deals', :expires_in => 10.minutes) { active_deal }

active_deal is a named scope I have in my model.

My app seems to work but I'm still in my staging environment - switching to Rails 3 now.

This is my system

• Heroku
• Rails 3
• Ruby 1.9.2
• Dalli (couldn't find out which version)

Can anyone help with hits "problem"

Thanks
MobiLutz

ESCAPE_KEY_CHARS

Hey Mike,

I faced 2 issues:

1. The ESCAPE_KEY_CHARS in lib/active_support/cache/dalli_store23.rb gives an "invalid multibyte escape" error in Ruby 1.9.2
2. When there is a key that contains one of the ESCAPE_KEY_CHARS, it bombs because getbyte is not present in Ruby 1.8.x, only in Ruby 1.9.x - in either case, I guess we can use match[0] instead of match.getbyte[0] to make it work in a backward-compatible way?

Also:

Q. Is the % in ESCAPE_KEY_CHARS needed?
Q. Is Dalli designed to work with Ruby 1.9.x only?

Thanks!
Swaroop

Invalid arugment to connect(2) on MacOSX (using ::1 for localhost)

On MacOSX, dalli 0.9.7:
(I've added some debugging messages), Replacing "localhost" with "127.0.0.1" did fix the problem
so the problem seems to be related to MacOSX 10.6.4 resolving localhost to ::1 instead of 127.0.0.1
(Ruby 1.8.7p248)

dc = Dalli::Client.new('localhost:11211')
dc.set("a", "b")

=> exception
=> Connecting to 11211 and ::1
Invalid argument - connect(2)
/usr/local/ruby18/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/server.rb:266:in connect_nonblock' /usr/local/ruby18/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/server.rb:266:inconnection'
/usr/local/ruby18/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/server.rb:17:in initialize' /usr/local/ruby18/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/client.rb:144:innew'

ORIGINAL exception (without message/patching) is:
Dalli::NetworkError: localhost:11211 is currently down: Invalid argument - connect(2)
from /usr/local/ruby18/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/server.rb:269:in connection' from /usr/local/ruby18/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/server.rb:17:ininitialize'
from /usr/local/ruby18/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/client.rb:144:in `new'

failover not really working

When having a list of servers (2 is enough) and one is down, dalli seems to try to connect each time a request is made. When using a setter method, dalli even raises an exception and causes the whole request to fail.

In my opinion, dalli should never (except when NO server is left) report any problems to the application. Also it should mark down servers for some time (ex. 10 minutes) and only after this time try to reconnect - and not on every single request. Otherwise performance will suffer a lot.

Also timeouts should be configurabe. So connect, read, write should have different timeout settings.

No server available (Windows 7. Rails 3)

I am having problem getting a new installation of dalli working. I have not used this plug in before. I am running Windows 7 64bit (development PC), rails 3.0.0, ruby 1.8.7. I can telnet to localhost 11211 and get a response, which indicates to me that my local memcached server is up and running. Can anyone point me in the right direction as to how to fix this?

Below is the output when I try to test the installation.

irb(main):003:0> dc = Dalli::Client.new('127.0.0.1:11211')
=> #<Dalli::Client:0x63043f8 @servers="127.0.0.1:11211", @options{:expires_in=>0}>

irb(main):004:0> dc.set("Hi", "Hello yourself")
Dalli::RingError: No server available
from C:/Ruby187/lib/ruby/gems/1.8/gems/dalli-0.11.2/lib/dalli/ring.rb:45 :in `server_for_key'
from C:/Ruby187/lib/ruby/gems/1.8/gems/dalli-0.11.2/lib/dalli/client.rb:221:in `perform'
from C:/Ruby187/lib/ruby/gems/1.8/gems/dalli-0.11.2/lib/dalli/client.rb:103:in `set'
from (irb):4
from :0

Encoding problem if a utf-8 is given

Ruby 1.9, utf-8 key, error is thrown from the #escape_key method in the AS dalli_store. Not sure if this is how it should work, or if the store should handle it more gracefully, but I wanted to report it/write it down before I forgot about it.

Encoding::CompatibilityError: incompatible encoding regexp match (ASCII-8BIT regexp with UTF-8 string)

Using dalli 0.9.8 but it looks like it would still happen with latest.

Support for > 1 MB of data

I'd like to see a support for data values bigger than 1 MB, memcached can already be configured (using the "-I" option) to enable it. I propose the following alternative patches which add the support to dalli. In the first one is the value set by user, in the second we find out the value in runtime. They were tested with memcached-1.4.4.

Set by user:

--- lib/dalli/server.rb.orig        2010-12-30 17:15:42.000000000 +0100
+++ lib/dalli/server.rb     2010-12-30 17:27:01.000000000 +0100
@@ -17,7 +17,9 @@
       # times a socket operation may fail before considering the server dead
       :socket_max_failures => 2,
       # amount of time to sleep between retries when a failure occurs
-      :socket_failure_delay => 0.01
+      :socket_failure_delay => 0.01,
+      # maximal size of data value in bytes (= size of memcached slab page; default is 1 MB, could be overriden with "memcached -I <size>")
+      :value_max_bytes => 1024 * 1024
     }

     def initialize(attribs, options = {})
@@ -126,8 +128,6 @@
       Thread.current[:dalli_multi]
     end

-    ONE_MB = 1024 * 1024
-
     def get(key)
       req = [REQUEST, OPCODES[:get], key.bytesize, 0, 0, 0, key.bytesize, 0, 0, key].pack(FORMAT[:get])
       write(req)
@@ -255,7 +255,7 @@
         value = Zlib::Deflate.deflate(value)
         compressed = true
       end
-      raise Dalli::DalliError, "Value too large, memcached can only store 1MB of data per key" if value.bytesize > ONE_MB
+      raise Dalli::DalliError, "Value too large, memcached can only store #{@options[:value_max_bytes]} bytes of data per key" if value.bytesize > @options[:value_max_bytes]
       flags = 0
       flags |= FLAG_COMPRESSED if compressed
       flags |= FLAG_MARSHALLED if marshalled

Runtime check:

--- lib/dalli/server.rb.orig        2010-12-30 17:15:42.000000000 +0100
+++ lib/dalli/server.rb     2010-12-30 19:29:46.000000000 +0100
@@ -126,8 +126,6 @@
       Thread.current[:dalli_multi]
     end

-    ONE_MB = 1024 * 1024
-
     def get(key)
       req = [REQUEST, OPCODES[:get], key.bytesize, 0, 0, 0, key.bytesize, 0, 0, key].pack(FORMAT[:get])
       write(req)
@@ -255,7 +253,7 @@
         value = Zlib::Deflate.deflate(value)
         compressed = true
       end
-      raise Dalli::DalliError, "Value too large, memcached can only store 1MB of data per key" if value.bytesize > ONE_MB
+      raise Dalli::DalliError, "Value too large, memcached can only store #{@value_max_bytes} bytes of data per key" if value.bytesize > @value_max_bytes
       flags = 0
       flags |= FLAG_COMPRESSED if compressed
       flags |= FLAG_MARSHALLED if marshalled
@@ -366,6 +364,9 @@
         @version = version # trigger actual connect
         sasl_authentication if Dalli::Server.need_auth?
         up!
+        # maximal size of data value in bytes (= size of memcached slab page; default is 1 MB, could be overriden with "memcached -I <size>")
+        item_size_max = stats('settings')['item_size_max']
+        @value_max_bytes = item_size_max ? item_size_max.to_i : (1024 * 1024)
       rescue Dalli::DalliError # SASL auth failure
         raise
       rescue SystemCallError, Timeout::Error, EOFError

Fault tolerance memcache server

I'm trying to switch from memcache_client to dalli 0.10.1 in Rails 2.3.2. It seems Dalli is not fault tolerance as memcache_client at all.

In memcache_client, Rails.cache.read, Rails.cache.write, Rails.cache.fetch, and Rails.cache.read_multi just simply return nil so that I can query db instead. In dalli returns exception causes my rails service to return 500.

When the memcached server down or could not connect, it should just return nil instead of raising exception. This makes memcache server more fault tolerance.

Thanks,
Chamnap

Tip: Using SASL-authed Membase Buckets

The current build of Membase (1.6.0.1) has a strange issue that returns a "Response Code 130: Out of Memory" error instead of an "Authentication Failed" error when attempting to use a SASL-authed bucket.

In order to properly use a SASL-authed bucket using Dalli, set your MEMCACHE_USERNAME environment variable to the name of the Bucket, not your Memcache user name. Set MEMCACHE_PASSWORD to the Bucket's password.

For example, in Ruby:

serverip='localhost:11211'
ENV['MEMCACHE_USERNAME']='mybucket' #Name of a membase SASL-authed bucket
ENV['MEMCACHE_PASSWORD']='123456' #Password of above SASL-authed bucket
$cache = Dalli::Client.new(serverip)

Not exactly the most intuitive, but according to the Membase developers, they're fixing the error in an upcoming build:

http://forums.membase.org/thread/sasl-bucket-errors-error-130-out-memory-when-ive-got-plenty-memory#comment-1001816

ActiveSupport cache adapter's #read_multi works different in memcache-client and dalli

In memcache-client:

irb(main):001:0> require 'memcache'
=> true
irb(main):003:0> require 'active_support'
=> true
irb(main):004:0> cc = ActiveSupport::Cache.lookup_store :mem_cache_store, "localhost"
=> #, @options={}>
irb(main):005:0> cc.write("abc", 5, :raw => true)
=> true
irb(main):006:0> cc.write("cba", 5, :raw => true)
=> true
irb(main):007:0> cc.read_multi("abc", "cba")
=> {"abc"=>"5", "cba"=>"5"}

But in dalli:

irb(main):011:0> require 'dalli'
=> true
irb(main):012:0> dc = ActiveSupport::Cache.lookup_store :dalli_store, "localhost"
=> #, @options={}>
irb(main):013:0> dc.write("abc", 5, :raw => true)
=> true
irb(main):014:0> dc.write("cba", 10, :raw => true)
=> true
irb(main):015:0> dc.read_multi("abc", "cba")
Dalli::DalliError: Invalid marshalled data in memcached: 10
    from /var/lib/gems/1.8/gems/dalli-0.9.10/lib/dalli/client.rb:168:in `deserialize'
    from /var/lib/gems/1.8/gems/dalli-0.9.10/lib/dalli/client.rb:53:in `get_multi'
    from /var/lib/gems/1.8/gems/dalli-0.9.10/lib/dalli/server.rb:308:in `inject'
    from /var/lib/gems/1.8/gems/dalli-0.9.10/lib/dalli/client.rb:53:in `each'
    from /var/lib/gems/1.8/gems/dalli-0.9.10/lib/dalli/client.rb:53:in `inject'
    from /var/lib/gems/1.8/gems/dalli-0.9.10/lib/dalli/client.rb:53:in `get_multi'
    from /var/lib/gems/1.8/gems/dalli-0.9.10/lib/dalli/ring.rb:49:in `lock'
    from /var/lib/gems/1.8/gems/dalli-0.9.10/lib/dalli/client.rb:48:in `get_multi'
    from /var/lib/gems/1.8/gems/dalli-0.9.10/lib/active_support/cache/dalli_store.rb:56:in `read_multi'
    from (irb):15

Trying to run example cache config fails with `syntax error, unexpected tASSOC`

 config.cache_store = :dalli_store, 'server1', 'server2',
      :namespace => NAME_OF_RAILS_APP, :expires_in => 1.day, :compress => true, :compress_threshold => 64.kilobytes

(from example in README)

throws: syntax error, unexpected tASSOC
from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.1/lib/active_support/dependencies.rb:239:in block in require' from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.1/lib/active_support/dependencies.rb:225:inblock in load_dependency'
from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.1/lib/active_support/dependencies.rb:591:in new_constants_in' from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.1/lib/active_support/dependencies.rb:225:inload_dependency'
from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.1/lib/active_support/dependencies.rb:239:in require' from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/application/bootstrap.rb:11:inblock in module:Bootstrap'
from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/initializable.rb:25:in instance_exec' from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/initializable.rb:25:inrun'
from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/initializable.rb:50:in block in run_initializers' from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/initializable.rb:49:ineach'
from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/initializable.rb:49:in run_initializers' from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/application.rb:134:ininitialize!'
from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/application.rb:77:in `method_missing'

Missing dalli_store23.rb?

Is there a missing dalli_store23.rb in the gem? The readme says to use this to set up a cache store. I tried using dalli_store but I get "dalli_store.rb:46:in `initialize':ArgumentError: wrong # of arguments(1 for 0)" when using Rails 2.3.2

Passenger error

I included the code block mention in the read me at the bottom of my environement.rb file
if defined?(PhusionPassenger)
PhusionPassenger.on_event(:starting_worker_process) do |forked|
# Only works with DalliStore
Rails.cache.reset if forked
end
end

and now I see the following in nginx error log..

2010/09/16 22:21:20 [error] 7760#0: 1 upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "passenger://unix:/tmp/passenger.7714/master/helper_server.sock:", host: "localhost"
** Exception NoMethodError in application (undefined method reset' for nil:NilClass) (process 7771): from /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/active_support/cache/dalli_store23.rb:97:inreset'
from /home/myusername/Apps/myapp/config/environment.rb:116
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/events.rb:35:in call' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/events.rb:35:incall_event'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/events.rb:34:in each' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/events.rb:34:incall_event'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/railz/application_spawner.rb:440:in start_request_handler' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/railz/application_spawner.rb:381:inhandle_spawn_application'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/utils.rb:252:in safe_fork' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/railz/application_spawner.rb:377:inhandle_spawn_application'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server.rb:352:in __send__' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server.rb:352:inmain_loop'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server.rb:196:in start_synchronously' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server.rb:163:instart'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/railz/application_spawner.rb:222:in start' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/spawn_manager.rb:253:inspawn_rails_application'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server_collection.rb:126:in lookup_or_add' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/spawn_manager.rb:247:inspawn_rails_application'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server_collection.rb:80:in synchronize' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server_collection.rb:79:insynchronize'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/spawn_manager.rb:246:in spawn_rails_application' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/spawn_manager.rb:145:inspawn_application'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/spawn_manager.rb:278:in handle_spawn_application' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server.rb:352:insend'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server.rb:352:in main_loop' from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server.rb:196:instart_synchronously'
from /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.15/bin/passenger-spawn-server:61
[ pid=7717 file=ext/nginx/HelperServer.cpp:491 time=2010-09-16 22:21:21.900 ]:
Uncaught exception in PassengerServer client thread:
exception: Cannot read response from backend process: Connection reset by peer (104)
backtrace:
in 'void Client::forwardResponse(boost::shared_ptrPassenger::Application::Session&, FileDescriptor&)' (HelperServer.cpp:342)

Unexpected exception in Dalli: ArgumentError: undefined class/module

Hello!

Sometimes I get this error while reading a record from the cache:

Dalli::Server#connect 127.0.0.1:11211
Unexpected exception in Dalli: ArgumentError: undefined class/module ItemProp
This is a bug in Dalli, please enter an issue in Github if it does not already exist.
/usr/local/lib/ruby/gems/1.9/gems/dalli-0.11.2/lib/dalli/server.rb:267:in load' /usr/local/lib/ruby/gems/1.9/gems/dalli-0.11.2/lib/dalli/server.rb:267:indeserialize'
/usr/local/lib/ruby/gems/1.9/gems/dalli-0.11.2/lib/dalli/server.rb:310:in generic_response' /usr/local/lib/ruby/gems/1.9/gems/dalli-0.11.2/lib/dalli/server.rb:134:inget'
/usr/local/lib/ruby/gems/1.9/gems/dalli-0.11.2/lib/dalli/server.rb:39:in request' /usr/local/lib/ruby/gems/1.9/gems/dalli-0.11.2/lib/dalli/options.rb:14:inblock in request'
/usr/local/lib/ruby/1.9/monitor.rb:201:in mon_synchronize' /usr/local/lib/ruby/gems/1.9/gems/dalli-0.11.2/lib/dalli/options.rb:13:inrequest'
/usr/local/lib/ruby/gems/1.9/gems/dalli-0.11.2/lib/dalli/client.rb:222:in perform' /usr/local/lib/ruby/gems/1.9/gems/dalli-0.11.2/lib/dalli/client.rb:46:inget'
/usr/local/lib/ruby/gems/1.9/gems/dalli-0.11.2/lib/active_support/cache/dalli_store.rb:123:in read_entry' /usr/local/lib/ruby/gems/1.9/gems/activesupport-3.0.3/lib/active_support/cache/strategy/local_cache.rb:129:inread_entry'
/usr/local/lib/ruby/gems/1.9/gems/activesupport-3.0.3/lib/active_support/cache.rb:316:in block in read' /usr/local/lib/ruby/gems/1.9/gems/activesupport-3.0.3/lib/active_support/cache.rb:519:ininstrument'
/usr/local/lib/ruby/gems/1.9/gems/activesupport-3.0.3/lib/active_support/cache.rb:315:in read' (irb):1:inirb_binding'
/usr/local/lib/ruby/1.9/irb/workspace.rb:80:in eval' /usr/local/lib/ruby/1.9/irb/workspace.rb:80:inevaluate'
/usr/local/lib/ruby/1.9/irb/context.rb:254:in evaluate' /usr/local/lib/ruby/1.9/irb.rb:159:inblock (2 levels) in eval_input'
/usr/local/lib/ruby/1.9/irb.rb:273:in signal_status' /usr/local/lib/ruby/1.9/irb.rb:156:inblock in eval_input'
/usr/local/lib/ruby/1.9/irb/ruby-lex.rb:243:in block (2 levels) in each_top_level_statement' /usr/local/lib/ruby/1.9/irb/ruby-lex.rb:229:inloop'
/usr/local/lib/ruby/1.9/irb/ruby-lex.rb:229:in block in each_top_level_statement' /usr/local/lib/ruby/1.9/irb/ruby-lex.rb:228:incatch'
/usr/local/lib/ruby/1.9/irb/ruby-lex.rb:228:in each_top_level_statement' /usr/local/lib/ruby/1.9/irb.rb:155:ineval_input'
/usr/local/lib/ruby/1.9/irb.rb:70:in block in start' /usr/local/lib/ruby/1.9/irb.rb:69:incatch'
/usr/local/lib/ruby/1.9/irb.rb:69:in start' /usr/local/lib/ruby/gems/1.9/gems/railties-3.0.3/lib/rails/commands/console.rb:44:instart'
/usr/local/lib/ruby/gems/1.9/gems/railties-3.0.3/lib/rails/commands/console.rb:8:in start' /usr/local/lib/ruby/gems/1.9/gems/railties-3.0.3/lib/rails/commands.rb:23:in<top (required)>'
script/rails:6:in require' script/rails:6:in

'
127.0.0.1:11211 is down
127.0.0.1:11211 is down: ArgumentError undefined class/module ItemProp
retrying request with new server
down_retry_delay not reached for 127.0.0.1:11211 (0.999 seconds left)

$ rails c
Loading development environment (Rails 3.0.3)
irb(main):001:0> ItemProp
=> ItemProp(id: integer, translation_id: integer, is_key_prop: boolean, is_sale_prop: boolean, is_color_prop: boolean, is_enum_prop: boolean, is_input_prop: boolean, is_item_prop: boolean, is_allow_alias: boolean, must: boolean, multi: boolean, ancestry: string, status: string, created_at: datetime, updated_at: datetime, category_id: integer, sort_order: integer, pid: integer)

irb(main):002:0> Rails.cache.write('50005469:1862450:3249833', ItemProp.first, :namespace => 'app_props')
=> true

irb(main):003:0> Rails.cache.read('50005469:1862450:3249833', :namespace => 'app_props')
=> #<ItemProp id: 1627208, translation_id: 521, is_key_prop: true, is_sale_prop: false, is_color_prop: false, is_enum_prop: true, is_input_prop: true, is_item_prop: false, is_allow_alias: false, must: true, multi: false, ancestry: nil, status: "normal", created_at: "2010-11-20 09:38:16", updated_at: "2010-11-20 09:38:16", category_id: 1201, sort_order: 0, pid: 20000>
^C

$ rails c
Loading development environment (Rails 3.0.3)
irb(main):001:0> Rails.cache.read('50005469:1862450:3249833', :namespace => 'app_props')
=> nil
(this error)

Usable for sessions

This doesn't seem to be usable as a session store because of the lack of a DalliStore in ActionDispatch::Sessions. Is there some way that this can be added or configured to work with sessions as well?

Cache miss on every fetch, even though key is the same

This issue in more detail @ http://stackoverflow.com/questions/4539633/memcached-miss-on-every-fetch-on-rails-with-dalli-gem

Issue with increment

Rails.cache.write "num", 0
Rails.cache.read "num" #returns 0
Rails.cache.increment('num', 1)
Cache incrementing: num (1)
NameError: undefined local variable or method e' for #<ActiveSupport::Cache::DalliStore:0x2388fe0> from /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/active_support/cache/dalli_store23.rb:72:inincrement'
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/cache/strategy/local_cache.rb:71:in `increment'
from (irb):11

Do I need to supply the raw option here (I am using Rails. 2.3.5)?

If I do that

Rails.cache.write "mycount", 0, :raw => true
Rails.cache.read "mycount'

Rails.cache.read "my"
Cache read: my
ArgumentError: marshal data too short
from /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/client.rb:154:in load' from /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/client.rb:154:indeserialize'
from /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/client.rb:29:in get' from /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/active_support/cache/dalli_store23.rb:106:inread'
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/cache/strategy/local_cache.rb:39:in `read'
from (irb):12

May be I am not doing it right?

gems/dalli-0.11.1/lib/dalli/socket.rb:36: undefined method `wait_readable=' for Kgio:Module

When unicorn was added to Gemfile along with dalli, the following error occurs when starting rails 3 server:

/Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/dalli-0.11.1/lib/dalli/socket.rb:36: undefined method wait_readable=' for Kgio:Module (NoMethodError) from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/dalli-0.11.1/lib/dalli.rb:4:inrequire'
from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/dalli-0.11.1/lib/dalli.rb:4
from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/bundler-1.0.2/lib/bundler/runtime.rb:64:in require' from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/bundler-1.0.2/lib/bundler/runtime.rb:64:inrequire'
from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/bundler-1.0.2/lib/bundler/runtime.rb:62:in each' from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/bundler-1.0.2/lib/bundler/runtime.rb:62:inrequire'
from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/bundler-1.0.2/lib/bundler/runtime.rb:51:in each' from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/bundler-1.0.2/lib/bundler/runtime.rb:51:inrequire'
from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/bundler-1.0.2/lib/bundler.rb:112:in require' from /Users/slice/dev/external_services/config/application.rb:8 from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/railties-3.0.0/lib/rails/commands.rb:28:inrequire'
from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/railties-3.0.0/lib/rails/commands.rb:28
from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/railties-3.0.0/lib/rails/commands.rb:27:in tap' from /Users/slice/.rvm/gems/ruby-1.8.7-p174@external_services/gems/railties-3.0.0/lib/rails/commands.rb:27 from script/rails:6:inrequire'
from script/rails:6

NotImplementedError: ActiveSupport::Cache::DalliStore does not support delete_matched

I'm getting this on Heroku when I try to update a record.

I'm calling ActionController::Base.new.expire_fragment(/regex/) in a model.

Any ideas on where I can start looking for how to solve this?

It works fine in development w/ caching turned on etc.

AR object is always frozen

Hi!

Sorry if I missed something but I have a problem with loading AR object from the cache. It is always frozen:

irb> Rails.cache
=> #<ActiveSupport::Cache::DalliStore:0x295ea8c0 @options={:namespace=>"demo", :compress=>true, :compress_threshold=>65536}, @DaTa=#<Dalli::Client:0x295ea780 @servers=["127.0.0.1:11211"], @options={}, @Ring=#<Dalli::Ring:0x2a2f635c @servers=[#<Dalli::Server:0x2a2f7b58 @hostname="127.0.0.1", @PORT=11211, @weight=1, @down_at=nil, @sock=#<Socket:fd 5>, @Version="1.4.5", @lock=#<Monitor:0x2a2f630c @mon_owner=nil, @mon_count=0, @mon_mutex=#Mutex:0x2a2f62e4>>], @continuum=nil, @failover=true>>, @thread_local_key=:active_support_cache_dalli_store_local_cache_347034720, @Middleware=ActiveSupport::Cache::Strategy::LocalCache>

irb> c = Category.first
=> #<Category id: 0, sort_order: nil, translation_id: nil, ancestry: nil, status: nil, url_suffix: nil, created_at: "2010-11-02 11:17:46", updated_at: "2010-11-02 11:17:46">

irb> Rails.cache.write('test', c)
=> true

irb> c1 = Rails.cache.read('test')
=> #<Category id: 0, sort_order: nil, translation_id: nil, ancestry: nil, status: nil, url_suffix: nil, created_at: "2010-11-02 11:17:46", updated_at: "2010-11-02 11:17:46">

irb> c1.frozen?
=> true

irb> c1.sort_order = '1'
RuntimeError: can't modify frozen hash
from /usr/local/lib/ruby/gems/1.9/gems/activerecord-3.0.1/lib/active_record/attribute_methods/write.rb:24:in []=' from /usr/local/lib/ruby/gems/1.9/gems/activerecord-3.0.1/lib/active_record/attribute_methods/write.rb:24:inwrite_attribute'
from /usr/local/lib/ruby/gems/1.9/gems/activerecord-3.0.1/lib/active_record/attribute_methods/dirty.rb:61:in write_attribute' from /usr/local/lib/ruby/gems/1.9/gems/activerecord-3.0.1/lib/active_record/attribute_methods/write.rb:13:insort_order='
from (irb):21

$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [i386-freebsd7]

$ rails -v
Rails 3.0.1

Dalli 0.9.10 && 0.10.0 fail to recover sessions on Heroku with Rails 2.3.9

This may be a heroku problem, but thought I should start here to see if something has change Heroku may not know.

Currently I can get sessions running on Heroku using 2.3.9 and Dalli 0.9.9, but when I try to use Dalli 0.9.10 or Dalli 0.10.0, Rails fails to recover my session data. To be clear, there is no error thrown. When I add data to session using the newer gems, rails does not seem to be able to recover that data. I cannot give a better description because the newer gems work just fine on my machine (OSX).

I tried using both of the following setup in my production.rb file on Heroku without success using Dalli 0.9.10 && 0.10.0:

--------- this setup works on Heroku using Dalli 0.9.9 but not in 0.9.10 && 0.10.0 ---------

require 'action_controller/session/dalli_store'
SESSION_CACHE = Dalli::Client.new(:namespace => 'my_session' )
config.action_controller.session = { :cache => SESSION_CACHE, :expire_after => 1.minute}

Thanks

Josh

connection refused error

I keep getting the following error in my production log..

DalliError (localhost:11211 is currently down: Connection refused - connect(2)): localhost:11211 is currently down: Connection refused - connect(2)
[DEBUG 16-09-2010 12:19:24] Cached fragment hit: views/category_nav (2.2ms)
[DEBUG 16-09-2010 12:19:24] Category Load (0.8ms) SELECT * FROM categories ORDER BY name ASC
[DEBUG 16-09-2010 12:19:24] Category Columns (1.0ms) SHOW FIELDS FROM categories
[ERROR 16-09-2010 12:19:24] DalliError (localhost:11211 is currently down: Connection refused - connect(2)): localhost:11211 is currently down: Connection refused - connect(2)
[DEBUG 16-09-2010 12:19:24] Cached fragment miss: views/category_nav (1.7ms)
[DEBUG 16-09-2010 12:19:24] Rendered shared/_cat_nav_list (19.3ms)
[ERROR 16-09-2010 12:19:24] DalliError (localhost:11211 is currently down: Connection refused - connect(2)): localhost:11211 is currently down: Connection refused - connect(2)
[DEBUG 16-09-2010 12:19:24] Cached fragment hit: views/city_nav (1.7ms)
[DEBUG 16-09-2010 12:19:24] User Load (0.6ms) SELECT distinct city FROM users
[ERROR 16-09-2010 12:19:24] DalliError (localhost:11211 is currently down: Connection refused - connect(2)): localhost:11211 is currently down: Connection refused - connect(2)
[DEBUG 16-09-2010 12:19:24] Cached fragment miss: views/city_nav (1.4ms)

Here is what I have in my production.rb

require 'active_support/cache/dalli_store23'
config.cache_store = :dalli_store
CACHE = Dalli::Client.new('127.0.0.1:11211')

here is the output of ps -aef | grep memcached

nobody 1081 1 0 12:15 ? 00:00:00 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1

Seems like memcached is running at 127.0.0.1 and that's where dalli is configured as well.