I have a vexing problem where a request is completed and customer information is stored in session (to be deleted on successful checkout). After the request completes, any subsequent action throws a Internal Server Error 500. This is the stack trace: http://pastie.org/317365 Could I be storing too much information in session? It''s merely an address... Debugging sessions problems is poo. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 18 Nov 2008, at 00:21, Nik B wrote:> > I have a vexing problem where a request is completed and customer > information is stored in session (to be deleted on successful > checkout). After the request completes, any subsequent action throws a > Internal Server Error 500. >You''re storing soap objects in your session ? I''m guessing wildly but I''d guess that what''s in the session references a class that was unloaded between the two requests, so the unmarshaling code fails horribly (if turning config.cache_classes on makes the problem go away then that would be a strong indication that something of that nature is the problem). One way around this would be to only store primitive types like arrays and hashes in the session. Fred> This is the stack trace: > > http://pastie.org/317365 > > Could I be storing too much information in session? It''s merely an > address... > > Debugging sessions problems is poo. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I didn''t think I was storing soap objects... here is the object that
is the last think I store and retrieve from the session:
--- !ruby/object:ShippingAddress
address: 123 MAIN ST
attributes:
customer_address_id:
preview:
user_id:
label:
attributes_cache: {}
city: ANYTOWN
country: US
first_name: Firstname
last_name: Lastname
new_record: true
phone_number: 555-555-5555
residential: true
state: NC
zip: 55555-5555
On Nov 17, 7:27 pm, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> You''re storing soap objects in your session ? I''m
guessing wildly but
> I''d guess that what''s in the session references a class
that was
> unloaded between the two requests, so the unmarshaling code fails
> horribly (if turning config.cache_classes on makes the problem go away
> then that would be a strong indication that something of that nature
> is the problem). One way around this would be to only store primitive
> types like arrays and hashes in the session.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
On 18 Nov 2008, at 14:38, Nik B wrote:> > I didn''t think I was storing soap objects... here is the object that > is the last think I store and retrieve from the session: >Well the backtrace certain showed the soap serialization stuff getting called. if you''re storing an activerecord objects you''ll save yourself trouble by just storing its attributes (or just its id if its already saved). Fred> --- !ruby/object:ShippingAddress > address: 123 MAIN ST > attributes: > customer_address_id: > preview: > user_id: > label: > attributes_cache: {} > > city: ANYTOWN > country: US > first_name: Firstname > last_name: Lastname > new_record: true > phone_number: 555-555-5555 > residential: true > state: NC > zip: 55555-5555 > > On Nov 17, 7:27 pm, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: >> You''re storing soap objects in your session ? I''m guessing wildly but >> I''d guess that what''s in the session references a class that was >> unloaded between the two requests, so the unmarshaling code fails >> horribly (if turning config.cache_classes on makes the problem go >> away >> then that would be a strong indication that something of that nature >> is the problem). One way around this would be to only store primitive >> types like arrays and hashes in the session. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
That''s the issue with (perhaps poor) design - it''s a temporary object never stored on the server. It''s attributes are defined merely with attr_accessor''s. At the end of the checkout process the virtual attributes are stored on Authorize.NET, and the actual record attributes are just an id and a customer_address_id which is used to retrieve it on Authorize. Seems like perhaps it has something to do with the attributes_cache... but I can''t find much information on how the attributes cache works. On Nov 18, 9:49 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 18 Nov 2008, at 14:38, Nik B wrote: > > > > > I didn''t think I was storing soap objects... here is the object that > > is the last think I store and retrieve from the session: > > Well the backtrace certain showed the soap serialization stuff getting > called. if you''re storing an activerecord objects you''ll save yourself > trouble by just storing its attributes (or just its id if its already > saved). > > Fred > > > --- !ruby/object:ShippingAddress > > address: 123 MAIN ST > > attributes: > > customer_address_id: > > preview: > > user_id: > > label: > > attributes_cache: {} > > > city: ANYTOWN > > country: US > > first_name: Firstname > > last_name: Lastname > > new_record: true > > phone_number: 555-555-5555 > > residential: true > > state: NC > > zip: 55555-5555 > > > On Nov 17, 7:27 pm, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > wrote: > >> You''re storing soap objects in your session ? I''m guessing wildly but > >> I''d guess that what''s in the session references a class that was > >> unloaded between the two requests, so the unmarshaling code fails > >> horribly (if turning config.cache_classes on makes the problem go > >> away > >> then that would be a strong indication that something of that nature > >> is the problem). One way around this would be to only store primitive > >> types like arrays and hashes in the session.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Nov 18, 2:55 pm, Nik B <nikbau...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> That''s the issue with (perhaps poor) design - it''s a temporary object > never stored on the server. It''s attributes are defined merely with > attr_accessor''s. At the end of the checkout process the virtual > attributes are stored on Authorize.NET, and the actual record > attributes are just an id and a customer_address_id which is used to > retrieve it on Authorize. >in that case I''d store a hash of those attributes in the session> Seems like perhaps it has something to do with the attributes_cache... > but I can''t find much information on how the attributes cache works. >Unlikely. attributes_cache is just to do with caching attributes that are expensive to create (mostly datetimes) Fred> On Nov 18, 9:49 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > > > On 18 Nov 2008, at 14:38, Nik B wrote: > > > > I didn''t think I was storing soap objects... here is the object that > > > is the last think I store and retrieve from the session: > > > Well the backtrace certain showed the soap serialization stuff getting > > called. if you''re storing an activerecord objects you''ll save yourself > > trouble by just storing its attributes (or just its id if its already > > saved). > > > Fred > > > > --- !ruby/object:ShippingAddress > > > address: 123 MAIN ST > > > attributes: > > > customer_address_id: > > > preview: > > > user_id: > > > label: > > > attributes_cache: {} > > > > city: ANYTOWN > > > country: US > > > first_name: Firstname > > > last_name: Lastname > > > new_record: true > > > phone_number: 555-555-5555 > > > residential: true > > > state: NC > > > zip: 55555-5555 > > > > On Nov 17, 7:27 pm, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > wrote: > > >> You''re storing soap objects in your session ? I''m guessing wildly but > > >> I''d guess that what''s in the session references a class that was > > >> unloaded between the two requests, so the unmarshaling code fails > > >> horribly (if turning config.cache_classes on makes the problem go > > >> away > > >> then that would be a strong indication that something of that nature > > >> is the problem). One way around this would be to only store primitive > > >> types like arrays and hashes in the session.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---