Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moving ahead for finalizing working Session Handlers #15

Merged
merged 35 commits into from
Jul 7, 2016

Conversation

pulkit4tech
Copy link
Owner

@pulkit4tech pulkit4tech commented Jun 24, 2016

Includes all recent changes i.e. -

  • Deleting Timers using Celluloid#Timers=> which deletes value from outer hash automatically after expiry
  • Updated Configuration logic and its usage
  • Updated patching way for Parser to solve failing pipelined request test in connection_spec

Kindly Review 😃 /cc: @kenichi @digitalextremist

@@ -5,6 +5,7 @@

module Reel
module Session
extend Celluloid
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

o_O does that... work? @digitalextremist

end
@options
end

# initializing session
def initialize_session
@bag = Store.new self
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with the include Celluloid in store.rb below, this will cause a new actor/thread per request

@kenichi
Copy link

kenichi commented Jun 25, 2016

if i understand correctly, what you are trying to do here is have timers that "expire" the data from the hash store. you're trying to use the after(sec) &block method of a celluloid actor. so, to get that, with access to @key as well, you tried adding include Celluloid to the Store class.

unfortunately, as noted above, this makes each instance of the Store class an actor with its own thread. that's way too heavy per request.

one solution might be to create a single instance of a StoreExpiry class (that includes Celluloid) and register expiration there...

but why use another thread, when there's perfectly good reactor sitting around in the form of the reel server?

see the PR i just opened to get access to the server from inside requests. celluloid#228

@pulkit4tech
Copy link
Owner Author

Yes that would be heavy creating thread per request. Will be calling after on server instance using request .. Thanks @kenichi 😃

@kenichi
Copy link

kenichi commented Jun 29, 2016

regarding HeaderError, i don't think that's a good idea anymore, but see the other comments on #18 and #17 and lemme know your thoughts re: still setting the cookie even if the session is empty.

@pulkit4tech
Copy link
Owner Author

Merging 😃

@pulkit4tech pulkit4tech merged commit 5fabff8 into gsoc16 Jul 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants