search

portagenetwork / roadmap

Developed by the the Alliance in collaboration with University of Alberta, DMP Assistant a data management planning tool, forking the DMP Roadmap codebase
MIT License
6 stars 1 forks source link

Fix `rake sessions:cleanup` #723

Open aaronskiba opened 2 months ago

aaronskiba commented 2 months ago

Please complete the following fields as applicable:

What version of the DMPRoadmap code are you running? (e.g. v2.2.0)

Expected behaviour:

aaronskiba commented 2 months ago

It looks like this rake task relies on gem 'activerecord-session_store', which was removed for release3.0.4+portage-3.0.0: https://github.com/portagenetwork/roadmap/compare/2.1.3+portage-1.0.19...3.0.4+portage-3.0.0#diff-d09ea66f8227784ff4393d88a19836f321c915ae10031d16c93d67e6283ab55fL190

aaronskiba commented 2 months ago

Release 3.0.4+portage-3.0.5 included the following change: Screenshot from 2024-04-16 13-27-56

config/initializers/session_store.rb is still using :cookie_store. Thus, rather than fixing this rake task, it may no longer be needed at all (Cookie is configured as Expires / Max Age: Session).

aaronskiba commented 2 months ago

I'm wondering if we should also have secure: true added to the session_store config? Or maybe the equivalent change should be made within the load balancer/proxy? Screenshot from 2024-04-17 14-04-51

nmacgreg commented 2 months ago

For context, "at one time" there was a database table named "sessions" that grew without bound, so we created this cron job to delete old entries and keep the database clean. I remember that this would grow to millions of rows over "a few weeks or months". This affected all our Rails applications. Aaron's suggestion of the release date implies March 2022 for the transition.

A little research, to start!

First, yes, I confirm there's a crontab entry driving this: 

[root@southampton ~]# crontab -l 
#Ansible: Clean sessions table, daily
5 4 * * * source /root/.bashrc && cd /var/www/sites/dmp && RAILS_ENV=staging bundle exec rake sessions:cleanup > /tmp/sessionCleanup 2>&1

...and we can see that crontab is created by Ansible, so if we plan to delete the crontab entry, I'll also need to adjust the Ansible task list to prevent it from begin recreated by a future playbook run.

I have examined the database: 

dmp_prod=# select * from sessions limit 5;
   id   |            session_id            |                             data                             |     created_at      |     updated_at      
--------+----------------------------------+--------------------------------------------------------------+---------------------+---------------------
 279577 | 0f3da6b542d231a21129d99308f55175 | BAh7CEkiC2xvY2FsZQY6BkVGSSIKZW5fQ0EGOwBUSSIQX2NzcmZfdG9rZW4G+| 2022-02-28 11:05:49 | 2022-02-28 11:05:49
        |                                  | OwBGSSIxSTQ2UG5QZVJ0L1BXei8rY01OcVd4Q0FaUmppakdWU0xNYzgyb0cr+|                     | 
        |                                  | R1FxZz0GOwBGSSIRcHJldmlvdXNfdXJsBjsARiIGLw==                +|                     | 
        |                                  |                                                              |                     | 
 279578 | afd8388c8faf8c700db67a87febb0d59 | BAh7CEkiC2xvY2FsZQY6BkVGSSIKZW5fQ0EGOwBUSSIQX2NzcmZfdG9rZW4G+| 2022-02-28 11:09:10 | 2022-02-28 11:09:10
        |                                  | OwBGSSIxT0tzVlRSa2VieHoxdGxSNXF5TVQxSi9VRkRYa1pHekwycmVDekNR+|                     | 
        |                                  | YXYrQT0GOwBGSSIRcHJldmlvdXNfdXJsBjsARiIGLw==                +|                     | 
        |                                  |                                                              |                     | 
dmp_prod=# select count(*) from sessions where created_at > '2022-03-31';
 count 
-------
     0
(1 row)

dmp_prod=# select count(*) from sessions where created_at > '2022-02-28';
 count 
-------
   973
(1 row)

Here's a graph demonstrating the growth rate of the database since Sept, 2024: image It's up-and-to-the-right, but linear and most importantly relatively slow, about 30Mb in 8 months, which to me seems consistent with the nature of the application.

I didn't find anything surprising here. I suggest these actions, for discussion: