[
https://issues.apache.org/jira/browse/SLING-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757700#action_12757700
]
Ian Boston commented on SLING-1116:
-----------------------------------
A data point for you on respository clustering of cookies.
Sakai 2 (the version not based on Sling) uses a database table to store custom
session cookies, and has been in production for reasonably large clusters for
about 4 years (16 node clusters) the result is not entirely happy.
Here are some of the issues.
1. "Ghost busting" where a server goes away from the cluster a reasonably
complex background thread performs ghost session busting. This generates both
database contention and network traffic.
2. Cookies have to have affinity to app servers unless sub ms propagation of
sessions can be guaranteed. With a single Oracle/MySQL DB back end we found
that we could not guarantee no race conditions without affinity. AFAIK, the
current open source cluster for Jackrabbit does not have sub ms propagation of
events between Cluster nodes.
3. There are a number of good quality cluster wide replication frameworks
available [A][B][C] that do a good job here, to start with HttpSession is not a
problem if its not abused, ie only very small amounts of recreatable data
should be stored to keep true to REST and session usage should be actively
policed. Abandoning HttpSession makes it harder for deployers to configure
cluster sync.
4. Concurrency: In a very highly loaded system anything that causes concurrency
issues will be a nightmare. We have already proved [D] that a high number of
concurrent writes to even a deeply hierachical area of the content tree carries
the risk of non mergable concurrent modifications (about 1%) which need to be
handled. Server persisted storage, with a last access time are likely to create
just this type of issue.
All of this is based on the DB persistence managers or direct JDBC avalable in
Jackrabbit and may not be true of other custom proprietary persistance managers
IMVHO, I would not make the same mistakes as were made in Sakai2 and invent a
new mechanism of cluster wide cookie management. Those mistakes ( and not
policing session usage) were one of the driving reasons for abandoning our
current code base and adopting Sling.
A. Standard container session replication (Jetty & Tomcat)
B. Terracotta and others
C. Cluster wide caches (EhCache, Memcache etc)
BTW, I have a bundle for EhCache which we use.
> FORM Based Authentication
> -------------------------
>
> Key: SLING-1116
> URL: https://issues.apache.org/jira/browse/SLING-1116
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Eric Norman
> Attachments: org.apache.sling.formauth.zip
>
>
> This is a new bundle that provides an implementation of forms based
> authentication for sling.
> There are two servlets:
> 1. LoginServlet - bound to /session/login
> 2. LogoutServlet - bound to /session/logout
> The FormAuthenticationHandler will use http basic auth credentials if they
> are on the request. If there is no basic auth header, it will use attempt to
> use cached credentials stored on the server side by the LoginServlet.
> The login form html is generated by a set of scripts
> 1. login.html.esp - full login page (includes login_body.html.esp for the
> form markup)
> 2. login_body.html.esp - just the login form, which may be useful for
> drawing the login form for an ajax context
> 3. loginError.html.esp - full login-error page
> 4. loginError_body.html.esp - just the login-error form, for login error in
> ajax context
> The above scripts are included as bundle-resources @
> /libs/sling/servlet/default
> The bundle also has a couple of test scripts to show some examples of usage:
> 1. loginTest.html.esp - shows who is logged in and links to login or logout
> 2. loginTest2.html.esp - shows how a script can check permissions and show a
> login page if the anonymous user doesn't have permission to see the page,
> Some examples of usage are:
> 1. http://host:port/path/to/node.login.html - show the login page and then
> goto http://host:port/path/to/node after authenticated
> 2. http://host:port/path/to/node.login.html?s=.edit.html - show the login
> page and then goto http://host:port/path/to/node.edit.html after
> authenticated
> 3. http://host:port/session/logout - invalidate the session and switch back
> to anonymous user
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
