Ability to configure the default session time in trac.ini

[lists@…]

In my Trac (0.11.1) MySQL database there are 17 tables, and 2 of them are giving problems: session and session_attribute. The session table contained about 170k records and the session_attribute table had about 290k records. After running this particular Trac instance for about a year (since about oct 2007), first off the 0.11 trunk, later on the official release, MySQL started dying as soon as I tried to login. It basically locked up the whole MySQL server and only a restart would bring it back to life again for a short period of time, but as soon as I would login it would freeze again.

So I noticed those tables had a lot of records so I thought like screw it, im gonna empty those tables and et voila everything's running smooth again! So that was a big surprise and annoyance.. So I was thinking why does Trac allow those tables to become so big and why aren't those session records cleared after a while, garbage collecting them or something? Cause I don't see why all of those sessions should be stored forever since (I assume) every anonymous user on the site will add a session record to that table when they fill in the preferences info etc.

I asked around on the IRC channel and there I was told to set the default session time to a lower value because the current default is 90 days. It's currently only possible to change the default session timeout (which you should do if you have a lot of authenticated users) by editing the hardcoded default var called 'PURGE_AGE' in web/session.py. It seems to me that an important setting like that should be made available to the user so they can modify it in their trac.ini file.

[Jonas Borgström]

290k rows in a sql table is really not that much data. Especially since it is properly indexed. Instead I suspect the real cause of the slowdowns/freezes is mysql table/database corruption or something else wrong with mysql itself.

1. If possible, load a dump of the old database into a fresh database and see if this problem is still reproducible.
2. Verify that the session_attribute primary key index exists
3. Switch to the innodb mysql table engine if you didn't use that already

For comparison: The trac.edgewall.org server (PostgreSQL 8.1) currently has 600k+ rows in the session_attribute table without any noticeable slowdowns.

[lists@…]

Maybe I should've omitted the information about my tables cause it's not really relevant to this enhancement request, depending on the way you look at it. I'm asking if it's possible to add that setting in the trac.ini, cause it shouldn't be hardcoded in the code imo. Especially when Trac already provides a config file feature. As I wrote in the ticket, I emptied the tables and didn't back it up unfortunately.

[Jonas Borgström]

OK, I understand. But we will not add yet another config option until we understand why it's needed and can reproduce it.

So I'm going to close this as wontfix until we have a way to reproduce this and to make sure the number of session_attribute rows is really the culprit.

Please reopen this ticket if you have a way to reproduce it.

[anonymous]

I am having a similar problem in a relatively small trac instance, with sqlite3 backend.

We have an internal GSA (google search appliance) that indexes the trac instance every night. After a couple of months, the session_attribute grew to over a million records.

It will be very nice to have this PURGE_AGE externally configurable.