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/16 13:49:00 UTC

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

     [ https://issues.apache.org/jira/browse/FELIX-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler resolved FELIX-5928.
-------------------------------------
    Resolution: Fixed

implemented session handling as outlined above and provide two additional configuration switches

> 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
>            Priority: Major
>             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)