This is for issue #7
So it would be nice if we had access to `State` because it would provide
us with `cookieExpires`, but nothing in the machinery of serversession
makes it available to backends for some reason. Also the tests seem to
indicate that the State may not be available at the time of setting up
storange engines (or may be a chicken-and-egg situation). The best
solution seemed to be to take the settings for absolute and idle timeout
that you're going to give to the state and share them.
Just as a reminder for the motivation on this: currently in
serversession's redis backend, you accumulate sessions
indefinitely. Even after they expire, they will stay in redis. The other
backends seem vulnerable to this too but its probably not nearly a big
deal in something like persistent because:
1. Storage is not as much of a premium in peristent's supported backend
compared to redis. They are primarily storing to disk.
2. Persistent's backends have good querying primitives so it is simple
to write jobs to delete old sessions.
Redis must fit all data in memory, so storage is at a premium and in
order to find old keys you'd have to issue the frowned-upon KEYS
command (or SCAN which isn't even suppored by hedis yet) and parse every
session.
This change uses redis' built in expiry mechanism and sets the
expiration every time a write operation is made to a session. Sessions
as they would naturally expire on the client side will now automatically
expire and free memory on the backend.
This is getting ridiculous. The test that used to fail on GHC 7.10 and
work on GHC 7.8, now failed on GHC 7.8 and worked on GHC 7.10.
It's better to have a predictable test suite with two less unit tests
than having an unpredictable one.
Currently PostgreSQL is dying on GHC 7.10 but not on GHC 7.8.
Hypothesis: The files left over from the acid-state local storage test
are consuming resources that PostgreSQL needs. These files are not
created on GHC 7.8, only on GHC 7.10.
Although it uses 580M on my GHC 7.10, it blew up the 1 GiB limit on Travis.
Travis currently allows usage of 3 GiB, and GHC tends to use 2x the the
maximum residency (even with the compacting option, WTF?).
The persistent test is failing and I have no idea why, as it's not
displaying any error message. This commit changes a few things with
PostgreSQL just to see if they make any difference.
Note that the persistent test suite passes with flying colors both
before and after this commit on my machine using PostgreSQL 9.4.2.
