Singleton Class Error. Singleton cant be dumped

[Siddharth Ravichandran]

Hi,

This is actually my first question on this list.

Im using Ruby on Rails and im adding an array of users into a session object. The problem is when I add it to the session I get the following error

Status: 500 Internal Server Error singleton can't be dumped

The problem is my user class called Expert is not a singleton class. The following is a snippet of my controller code.

def search 
..
if @experts.empty?

  @experts = expert_word_search(@search_params)

  @page_results = paginate_array(@experts.uniq)

end
session[:search_results] = @page_results

session[:complete_search_results] = @experts

..
end

I realize that storing the page_results in session is a bad design choice but my question is why does it throw a "singleton can't be dumped error". Since my expert class is not a singleton class and the method expert_word_search belongs to a module which handles the search logic. Im also only including my module. I also tried to find if im unintentionally creating any singletons objects using the singleton_methods method but im not.

Could somebody please explain this to me

The stacktrace

 Status: 500 Internal Server Error
  singleton can't be dumped
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/session_store.rb:67:in `dump'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/session_store.rb:67:in `marshal'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/session_store.rb:123:in `marshal_data!'
    /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/callbacks.rb:178:in `send'
    /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/callbacks.rb:178:in `evaluate_method'
    /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/callbacks.rb:166:in `call'
    /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/callbacks.rb:93:in `run'
    /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/callbacks.rb:92:in `each'
    /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/callbacks.rb:92:in `send'
    /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/callbacks.rb:92:in `run'
    /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.4/lib/active_support/callbacks.rb:276:in `run_callbacks'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/callbacks.rb:344:in `callback'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/callbacks.rb:249:in `create_or_update'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/base.rb:2538:in `save_without_validation'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/validations.rb:1078:in `save_without_dirty'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/dirty.rb:79:in `save_without_transactions'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/transactions.rb:229:in `send'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/transactions.rb:229:in `with_transaction_returning_status'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/connection_adapters/abstract/database_statements.rb:136:in `transaction'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/transactions.rb:182:in `transaction'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/transactions.rb:228:in `with_transaction_returning_status'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/transactions.rb:196:in `save'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/transactions.rb:208:in `rollback_active_record_state!'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/transactions.rb:196:in `save'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/session_store.rb:300:in `set_session'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/base.rb:1448:in `silence'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/session_store.rb:297:in `set_session'
    /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/session/abstract_store.rb:132:in `call'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/query_cache.rb:29:in `call'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/connection_adapters/abstract/query_cache.rb:34:in `cache'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/query_cache.rb:9:in `cache'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/query_cache.rb:28:in `call'
    /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/connection_adapters/abstract/connection_pool.rb:361:in `call'
    /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/failsafe.rb:26:in `call'
    /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/lock.rb:11:in `call'
    /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/lock.rb:11:in `synchronize'
    /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/lock.rb:11:in `call'
    /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/dispatcher.rb:114:in `call'
    /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/reloader.rb:34:in `run'
    /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/dispatcher.rb:108:in `call'
    /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/rails/rack/static.rb:31:in `call'
    /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/urlmap.rb:46:in `call'
    /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/urlmap.rb:40:in `each'
    /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/urlmap.rb:40:in `call'
    /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/rails/rack/log_tailer.rb:17:in `call'
    /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/content_length.rb:13:in `call'
    /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/chunked.rb:15:in `call'
    /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/handler/mongrel.rb:61:in `process'
    /home/siddharth/.gem/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:159:in `process_client'
    /home/siddharth/.gem/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:158:in `each'
    /home/siddharth/.gem/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:158:in `process_client'
    /home/siddharth/.gem/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `run'
    /home/siddharth/.gem/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `initialize'
    /home/siddharth/.gem/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `new'
    /home/siddharth/.gem/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:285:in `run'
    /home/siddharth/.gem/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:268:in `initialize'
    /home/siddharth/.gem/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:268:in `new'
    /home/siddharth/.gem/ruby/1.8/gems/mongrel-1.1.5/lib/mongrel.rb:268:in `run'
    /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/handler/mongrel.rb:34:in `run'
    /usr/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/commands/server.rb:111
    /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    script/server:3

[Swanand Pagnis]

I guess this is the 'cookie overflow' error. Each cookie can contain only 4kb of data. My guess is @post_results when serialized by Marshall Dump is bigger than 4kb. Try putting only post IDs in some other form rather than an ActiveRecord Collection (in JSON format for eg). This might help solve the problem.

--
You received this message because you are subscribed to the Google Groups "BANGALORE RUG-Ruby Users Group" group.
To post to this group, send an email to bangal...@googlegroups.com.
To unsubscribe from this group, send email to bangalorerug...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bangalorerug?hl=en-GB.

[Siddharth Ravichandran]

Hi Swanand,

Thanks for the reply . But im actually using ActiveRecord Session Store. Could that still be the problem?

[Swanand Pagnis]

I see, I think I spoke a little too soon then. ActiveRecord Session has a much higher limit ( says API docs ), but it could still be the problem. Let me try to reproduce it and think about it.

[Siddharth Ravichandran]

Thanks man. It totally works.

What i dont understand is the reason for the error. the minute i change the format to JSON it works. But I dont understand where the singleton class is getting created.

[C. K. Ponnappa]

Cool, but why are you storing an array of users in your session? That
sounds like it could be problematic further down the line.

Cheers,
Sidu.
http://blog.sidu.in
http://twitter.com/ponnappa

Siddharth Ravichandran wrote:
> Thanks man. It totally works.
>
> What i dont understand is the reason for the error. the minute i
> change the format to JSON it works. But I dont understand where the
> singleton class is getting created.
>
>
>
> On Mon, Mar 29, 2010 at 12:38 PM, Siddharth Ravichandran
> <sid.ravi...@gmail.com <mailto:sid.ravi...@gmail.com>> wrote:
>
> Hi Swanand,
>
> Thanks for the reply . But im actually using ActiveRecord Session
> Store. Could that still be the problem?
>
> On Mon, Mar 29, 2010 at 12:35 PM, Swanand Pagnis
> <swanand...@gmail.com <mailto:swanand...@gmail.com>> wrote:
>
> I guess this is the 'cookie overflow' error. Each cookie can
> contain only 4kb of data. My guess is @post_results when
> serialized by Marshall Dump is bigger than 4kb. Try putting
> only post IDs in some other form rather than an ActiveRecord
> Collection (in JSON format for eg). This might help solve the
> problem.
>
> On Mon, Mar 29, 2010 at 4:48 PM, Siddharth Ravichandran
> <sid.ravi...@gmail.com

> <mailto:sid.ravi...@gmail.com>> wrote:
>
> Hi,
>
> This is actually my first question on this list.
>
> Im using Ruby on Rails and im adding an array of users
> into a session object. The problem is when I add it to the
> session I get the following error
>
> |Status: 500 Internal Server Error singleton can't be dumped|
>
> The problem is my user class called Expert is not a
> singleton class. The following is a snippet of my
> controller code.
>
>

> *|def search

> ..
> if @experts.empty?
>
> @experts = expert_word_search(@search_params)
>
> @page_results = paginate_array(@experts.uniq)
>
> end
> session[:search_results] = @page_results
>
> session[:complete_search_results] = @experts
>
> ..
> end

> |*

> <mailto:bangal...@googlegroups.com>.

> To unsubscribe from this group, send email to
> bangalorerug...@googlegroups.com

> <mailto:bangalorerug%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/bangalorerug?hl=en-GB.
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "BANGALORE RUG-Ruby Users Group" group.
> To post to this group, send an email to
> bangal...@googlegroups.com

> <mailto:bangal...@googlegroups.com>.

> To unsubscribe from this group, send email to
> bangalorerug...@googlegroups.com

> <mailto:bangalorerug%2Bunsu...@googlegroups.com>.

[Siddharth Ravichandran]

I just moved that around now. The reason was to actually save some of the search results so that I dont have to query it repeatedly. I 've just moved it to memcache now. However i still haven't been able to figure out the root cause of the problem.

Though I dont have any IO operations on that  class for the objects contained within the array of users (experts) i found the WillPaginate::Collection does contain lot of singleton methods. Another thing I feel could be some meta-programming that could be make it a singleton class.

So the problem for me now has been to push it into cache. Clone seems to be of no help suprisingly and i read that tweaking the Marshal.load Marshall.dump could be a way out.

I'd appreciate any help.

Siddharth.

[C. K. Ponnappa]

What kind of search is this? Directly driven by a user (as in are you
trying to cache search results)?

Next question is - what segment of the app stack are you trying to
optimise? Put another way, what exactly is preventing you from *not*
caching anything and just repeating the search each time; why is the
search not fast enough to be used as is? (sorry, that's a lot of
questions I'm throwing at you)

The reason I even brought it up is (and please forgive me if you've come
across this already) that generally you try to put as little as possible
in your session. It's that anti-pattern which I've heard called many
things, but is best described by 'Session as Database'.

> <mailto:sid.ravi...@gmail.com

> <mailto:sid.ravi...@gmail.com>>> wrote:
>
> Hi Swanand,
>
> Thanks for the reply . But im actually using ActiveRecord
> Session
> Store. Could that still be the problem?
>
> On Mon, Mar 29, 2010 at 12:35 PM, Swanand Pagnis
> <swanand...@gmail.com <mailto:swanand...@gmail.com>

> <mailto:swanand...@gmail.com

> <mailto:swanand...@gmail.com>>> wrote:
>
> I guess this is the 'cookie overflow' error. Each
> cookie can
> contain only 4kb of data. My guess is @post_results when
> serialized by Marshall Dump is bigger than 4kb. Try putting
> only post IDs in some other form rather than an
> ActiveRecord
> Collection (in JSON format for eg). This might help
> solve the
> problem.
>
> On Mon, Mar 29, 2010 at 4:48 PM, Siddharth Ravichandran
> <sid.ravi...@gmail.com
> <mailto:sid.ravi...@gmail.com>

> <mailto:sid.ravi...@gmail.com

> <mailto:bangal...@googlegroups.com

> <mailto:bangal...@googlegroups.com>>.
>
> To unsubscribe from this group, send email to
> bangalorerug...@googlegroups.com
> <mailto:bangalorerug%2Bunsu...@googlegroups.com>

> <mailto:bangalorerug%2Bunsu...@googlegroups.com
> <mailto:bangalorerug%252Buns...@googlegroups.com>>.

>
> For more options, visit this group at
> http://groups.google.com/group/bangalorerug?hl=en-GB.
>
>
> -- You received this message because you are
> subscribed to the
> Google Groups "BANGALORE RUG-Ruby Users Group" group.
> To post to this group, send an email to
> bangal...@googlegroups.com
> <mailto:bangal...@googlegroups.com>

> <mailto:bangal...@googlegroups.com

> <mailto:bangal...@googlegroups.com>>.
>
> To unsubscribe from this group, send email to
> bangalorerug...@googlegroups.com
> <mailto:bangalorerug%2Bunsu...@googlegroups.com>

> <mailto:bangalorerug%2Bunsu...@googlegroups.com
> <mailto:bangalorerug%252Buns...@googlegroups.com>>.

[Siddharth Ravichandran]

What kind of search is this? Directly driven by a user (as in are you trying to cache search results)?

The search data actually comes from a sister server that sends in crawled information as JSON (uncompressed) based on a user query. The problem lies in the delay over establishing connection and fetching the results and then optimising the search results on our end.

Put another way, what exactly is preventing you from *not* caching anything and just repeating the search each time; why is the search not fast enough to be used as is?

The reason querying repeatedly seems troublesome is that it take approximately 5 - 8 seconds for the data fetch + optimization to happen.
I am not completely sure where the bottleneck is as both my servers are  EC2 instances.

I completely understand that storing such info in the session is a bad idea.

Siddharth