You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2018/09/14 06:59:00 UTC

[jira] [Created] (FELIX-5928) Improve session handling

Carsten Ziegeler created FELIX-5928:
---------------------------------------

             Summary: Improve session handling
                 Key: FELIX-5928
                 URL: https://issues.apache.org/jira/browse/FELIX-5928
             Project: Felix
          Issue Type: Improvement
          Components: HTTP Service
            Reporter: Carsten Ziegeler
            Assignee: Carsten Ziegeler
             Fix For: http.jetty-4.0.6, http.base-4.0.4, http.bridge-4.0.4


The current session handling can be problematic. The http implementation manages a set of http contexts, one for the http service and one or more for the http whiteboard contexts. All these contexts run within the single servlet context provided by the container (app server or jetty). 
Therefore as the container is managing the sessions, the sessions for the various http contexts are embedded within the container session and managed through a session wrapper by the http implementation.
The current implementation assumes that there are potentially web components outside of OSGi participating and therefore uses the same session id for all inner sessions and never invalidates the container session.

We should improve this behaviour by:

a) provide a configuration whether the http implementation should invalidate the session if it thinks it is not used anymore (this has been the case in previous versions). We should enable it by default. Sharing the session with web components outside of OSGi is rather the exception.

b) The session wrapper uses the same session id for all internally managed sessions; this is another source of problem. The session ids used to be different in a previous version and we should get back to it.

So with the defaults set as above, we're back to the old behaviour and all internal sessions have different ids. With this even if you have additional components like a cache using the session id, these caches will get invalidated correctly (through session events) and not be reused.

If someone changes the default setting, then still we have different session ids, so it can't happen that data from an old session (through a cache or something like that) reappears in a new session.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)