[
https://issues.apache.org/jira/browse/OWB-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237009#comment-13237009
]
Mark Struberg commented on OWB-646:
-----------------------------------
Ok, I think the whole FailOverBag stuff is currently in a bad state. Because it
doesn't have a well defined lifecycle and is just too complex for what it does.
There are 2 problematic areas
a.) what you might face: The WebContextsService stores the currently used
SessionContext in a ThreadLocal to speed up things. But this ThreadLocal
doesn't get set in FailOverBagWrapper#sessionDidActivate as far as I've seen.
b.) sessionDidActivate() and sessionCreated() are not 100% clearly defined in
the Servlet spec. I'll try to ping the EG folks but from just reading the spec
I didn't get wise... The actual question is: on a session re-activation we will
of course get sessionDidActivate() being invoked. But do we also get
sessionCreated()? And in that case do we get it _before_ or _after_
sessionDidActivate()?
c.) should sessionWillActivate remove the current SessionContext? Remember: we
are holding the SessionContext(s) in memory and _not_ in the Session. This is
because the Session is x30 times slower than a simple ConcurrentHashMap
directly under our control. But if we don't clean up the SessionContext
properly, we might end up with wrong contextual instances...
d.) The current approach is only supporting memcachd backed sessions (no
session is held on the server at all). But this is only one of many possible
solutions! Another one is full session-replication to all other nodes. In this
case the session remains on the server and will in addition gets pushed to all
other nodes.
And there is also the clustering pattern I use in our app (currently with a
self-made hack) : We use sticky-session + after the request serialize the
Session up to a memcached. And only if the sticky cluster node goes down and
the user gets directed to another cluster node, this will detect the missing
session and try to restore it from the memcached. This heavily reduces the cost
to propagate the sessions after each request (scales linear with each added
node and doesn't create square traffic anymore), and also increases the
availability: for loosing a session completely you'd need to kill the
sticky-node plus the memcached (which can be clustered as well) at the same
time! And still then all things will work fine, you'd only get a new session
and will be redirected to another cluster node...
> Failover does not work (again)
> ------------------------------
>
> Key: OWB-646
> URL: https://issues.apache.org/jira/browse/OWB-646
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Context and Scopes
> Affects Versions: 1.1.3
> Environment: Tomcat 7.0.22, OWB 1.1.3, memcached-session-manager 1.6.1
> Should be unrelated: MyFaces 2.1.6, CODI 1.0.3, ExtVal 2.0.5, Hibernate
> 3.6.9, BVAL 0.3
> Reporter: Thomas Andraschko
> Assignee: Mark Struberg
> Labels: Cluster, Failover, Replication, Tomcat
> Fix For: 1.2.0
>
>
> Martin (from msm) and I created an test app for this issue last year:
> https://github.com/magro/msm-sample-webapp/tree/openwebbeans and this was
> fixed within OWB-523.
> However, if i upgrade the Tomcat to 7.0.22 or newer, the bean replication
> does not work again.
> As you can see in this test app, the normal failover works (right input
> field) but the bean failover (left input field) does not work.
> I tested several Tomcat version and 7.0.21 or older works without problems,
> so the problem occured with Tomat 7.0.22.
> I don't know exactly if the problem is related to the OWB failover mechanism
> or Tomcat :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
