petergoldstein / dalli Goto Github PK
View Code? Open in Web Editor NEWHigh performance memcached client for Ruby
License: MIT License
High performance memcached client for Ruby
License: MIT License
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
Can anyone help with hits "problem"
Thanks
MobiLutz
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!
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
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.
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.
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
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?
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:in
block 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:in
load_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:in
block 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:in
run'
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:in
each'
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:in
initialize!'
from /home/plukevdh/.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/application.rb:77:in `method_missing'
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:in
require'
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:in
require'
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:in
require'
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:in
require'
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:in
require'
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:in
require'
from script/rails:6
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:
This issue in more detail @ http://stackoverflow.com/questions/4539633/memcached-miss-on-every-fetch-on-rails-with-dalli-gem
We depend on namespacing to expire keys during deployment. Do you have any plans on implementing this feature?
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
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
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.
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:in
deserialize'
/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:in
get'
/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:in
block 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:in
request'
/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:in
get'
/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:in
read_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:in
instrument'
/usr/local/lib/ruby/gems/1.9/gems/activesupport-3.0.3/lib/active_support/cache.rb:315:in read' (irb):1:in
irb_binding'
/usr/local/lib/ruby/1.9/irb/workspace.rb:80:in eval' /usr/local/lib/ruby/1.9/irb/workspace.rb:80:in
evaluate'
/usr/local/lib/ruby/1.9/irb/context.rb:254:in evaluate' /usr/local/lib/ruby/1.9/irb.rb:159:in
block (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:in
block 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:in
loop'
/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:in
catch'
/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:in
eval_input'
/usr/local/lib/ruby/1.9/irb.rb:70:in block in start' /usr/local/lib/ruby/1.9/irb.rb:69:in
catch'
/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:in
start'
/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
$ 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)
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?..
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
Hey Mike,
I faced 2 issues:
ESCAPE_KEY_CHARS
in lib/active_support/cache/dalli_store23.rb
gives an "invalid multibyte escape" error in Ruby 1.9.2ESCAPE_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
For Rails 3 I think you should use Rails.cache.clear rather than Rails.cache.reset for Phusion memcached tweak
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.
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.
Just the basics..the read me isn't clear in terms how to initialize, get, set, fetch etc.
Thanks, this looks very promising!
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
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?
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.
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?
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
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.
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.
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:in
require'
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:in
new_constants_in'
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:156:in `require'
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:in
write'
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:in
fetch'
from (irb):14
Does this library support namespacing your keys like the default Rails memcache library?
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:in
reset'
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:in
call_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:in
call_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:in
handle_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:in
handle_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:in
main_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:in
start'
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:in
spawn_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:in
spawn_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:in
synchronize'
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:in
spawn_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:in
send'
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:in
start_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)
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:in
increment'
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:in
deserialize'
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:in
read'
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?
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
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
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.
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
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:in
write_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:in
sort_order='
from (irb):21
$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [i386-freebsd7]
$ rails -v
Rails 3.0.1
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:in
connection'
/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:in
new'
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:in
initialize'
from /usr/local/ruby18/lib/ruby/gems/1.8/gems/dalli-0.9.7/lib/dalli/client.rb:144:in `new'
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:in
rescue 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:in
connection'
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:in
text_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:in
initialize'
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:in
block 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:in
ring'
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:in
set'
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:in
start'
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:in
require'
from script/rails:6:in `
Gem memcache-client is working fine.
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.
Can Dalli use existing memcached.yml file? If so, do you have any instructions for adding Dalli specific options?
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".
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
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:in
serialize'
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:in
request'
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:in
mon_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:in
perform'
183893312: /XXXXXXXXXX/vendor/bundle/ruby/1.9.1/gems/dalli-1.0.0/lib/dalli/client.rb:111:in set' 183893426- (eval):7:in
block 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:in
set_with_newrelic_trace'
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?
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:inpack' /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/server.rb:90:in
add'
/usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/server.rb:23:insend' /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/server.rb:23:in
request'
/usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/options.rb:40:inrequest' /usr/local/lib/ruby/1.8/monitor.rb:242:in
synchronize'
/usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/options.rb:39:inrequest' /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/client.rb:168:in
perform'
/usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/client.rb:70:inadd' /usr/local/lib/ruby/gems/1.8/gems/dalli-0.9.3/lib/dalli/client.rb:51:in
fetch'
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.