This removes the warnings produced by the invalid callout in the boot
reference. It also provides an example of how to customize the redis
connection and links to the "Connection to Redis" section of the
Spring Boot reference.
Issue #108
The callouts in the websocket guide need to be after the sample otherwise
the following warning is omitted:
asciidoctor: WARNING: guides/websocket.adoc: line 36: no callouts refer to list item 1
asciidoctor: WARNING: guides/websocket.adoc: line 38: no callouts refer to list item 2
asciidoctor: WARNING: websocket.adoc: line 36: no callouts refer to list item 1
asciidoctor: WARNING: websocket.adoc: line 38: no callouts refer to list item 2
This issue resolves the WARNING logs created due to the callout being
placed in the wrong location.
Issue #99
Simply move content around so that we first show what needs to be
done and then explain what is done internally. Arguably this is an
easier way to digest since the former is required knowledge while
the latter is optional.
The Problem:
The background task that cleans up sessions can incorrectly remove a
session due to a race condition.
Assume an existing session with the id "1" exists and will expire at
1420656360000. This means our redis store has the following:
spring:session:expirations:1420656360000 -> [1]
spring:session:session:1 -> <session>
Consider the following sequence:
* Thread 1 requests Session 1 and determines it should be forcibly deleted
up at 1420656420000
* Thread 2 requests Session 2 and determines it should be forcibly deleted
one minute later at 1420656480000
* Thread 2 removes Session 1 from 1420656360000, so it will no longer be
forcibly deleted at that time
spring:session:expirations:1420656360000 -> []
spring:session:session:1 -> <session>
* Thread 2 adds Session 1 to 1420656480000
spring:session:expirations:1420656360000 -> []
spring:session:session:1 -> <session>
spring:session:expirations:1420656480000 -> [1]
* Thread 1 removes Session 1 (which was already removed) from 1420656360000 (the original expiration)
spring:session:expirations:1420656360000 -> []
spring:session:session:1 -> <session>
spring:session:expirations:1420656480000 -> [1]
* Thread 1 adds Session 1 to 1420656420000
spring:session:expirations:1420656360000 -> []
spring:session:session:1 -> <session>
spring:session:expirations:1420656480000 -> [1]
spring:session:expirations:1420656420000 -> [1]
Now the session is mapped to be forcibly deleted in two locations.
However, at most it will be cleaned up in one location. This means that the
session will be forcibly deleted even if the session is continued to be
used.
Fixing the Issue:
Instead of deleting the session, we should have the background task access
the key which will only forcibly delete the key if it is expired. This mean
s that a session could at earliest be deleted when the value in the
datastore indicates.
This still means that a session can be deleted too soon since the
incorrect TTL may be set on a key. However, at worst this is the the
longest HTTP request length. Short of using distributed locking there
isn't a good answer to get exact consistency.
Fixes gh-93
