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

Variable Cookie TTL based on master_ttl #100

Closed
wants to merge 4 commits into from

Conversation

evantahler
Copy link
Contributor

No description provided.

@evantahler evantahler changed the title try to read ActiveRecord::Base.connection_config['master_ttl'] Variable Cookie TTL based on master_ttl Dec 10, 2015
# determine how lone the cookie TTL should last
# this needs to be done huristically, as we cannot be sure which connection
# would have had the longest timeout from this middleware
def cookie_ttl
Copy link
Contributor

Choose a reason for hiding this comment

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

i don't see the new cookie_ttl setting here. did you mean for the second one to be that?
Should this use the Makara::ConfigParser or ather, this logic be there ? it provides a way to do the default.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As far as I can tell, we can't use the Makara::ConfigParser here. There may be many instances of Makara in play (ActiveRecord vs ActiveRabbit, so we won't know which connection to source). I also don't know how we would find the instance at the middleware level.

That's why I tried to hack it with ActiveRecord::Base...

@evantahler evantahler mentioned this pull request Dec 10, 2015
@dreyks
Copy link

dreyks commented Dec 11, 2015

As I can see it right now, this won't solve the whole problem.
Use-case of countering replication lag as I see it:

  • write to master occurred
  • stick to master to the end of this request (this works already)
  • all subsequent requests in the time-frame of master_ttl have to stick to master
  • after master_ttl seconds passed unstick back to slave groups if no action in this time-frame naturally required master

If you just increase the cookie TTL, leaving the other mechanics as they are right now, it will stick to master only for one request during this time-frame. As soon as the next request will start, a new Context will be generated, and the cookie will be overwritten with the new context (and this new context is not in cache, so the third request will go back to slaves even though the master_ttl still haven't passed)

@bleonard
Copy link
Contributor

I don't see anywhere where we delete that cookie. if it was there at the beginning of the middleware, it will write it at the end. If anything, i'd be worried that we'd keep writing it over and over forever at the moment. I don't believe Rack::Utils.set_cookie_header! will not write it if it's already there. So, I think we'd keep loading and writing the same context. Or am I missing something?

@dreyks
Copy link

dreyks commented Dec 17, 2015

It's either we are talking about different things or this really works not as you intended

This one fails

# spec/middleware_spec.rb
it 'should not overwrite existing cookie' do
  env['HTTP_COOKIE'] = '_mkra_ctxt=old_context--200; path=/; max-age=5; HttpOnly'

  status, headers, body = middleware.call(env)

  expect(headers['Set-Cookie']).to match('old_context')
end

@jeremy
Copy link
Contributor

jeremy commented Jul 5, 2017

(See #159 if you'd like to simply extend the cookie's max-age or drop it entirely.)

@bleonard
Copy link
Contributor

bleonard commented Mar 5, 2018

Should be replaced by this one: #194

@bleonard bleonard closed this Mar 5, 2018
@bleonard bleonard deleted the variable_cookie_ttl branch March 5, 2018 04:19
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.

4 participants