[cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl

Mon Oct 12 17:56:02 EDT 2015

Thank you Mark for the useful information! I forgot to cc cdi-dev:(. Yes, I
meant the session failover in a cluster containing multiple servers.
>From what you described, it seems the session failover can only occur among
the servers containing the same level of OWB. It is going to be very tricky
to get OWB 1.0/1.1 to failover to OWB 1.2 servers. The
serialization/deserialization is very different.

I believe in Weld, the Weld generated subclass is stored in the session.
Martin K, please correct me if I am wrong.

To move forward, can we work out a plan to support failover among different
CDI levels of the same kind in the future CDI releases as the current
failover support is a real limitation?

On Mon, Oct 12, 2015 at 9:29 AM, Mark Struberg <struberg at yahoo.de> wrote:

> Deliberately private? Or did you simply forget to cc cdi-dev? Feel free to
> forward my answers to the list.
>
>
> > The EJB spec does not say anything about failover.
>
> Yes it says nothing about session failover or session replication. It is
> pretty vocal about remoting however. And this is technologically very close
> to clustering on many servers (Server talking to another Server).
> We probably have to explicitly distinguish a simple Session failover to a
> functional clustering aka scale up (mostly @Remote).
>
> Guess you are just refering to the former, right?
> For EJBs you can also only have @Stateful beans affected by session
> replication. And only if you store them in the Session (which gets
> replicated) of course. Or since EE6 if they are annotated with a CDI Scope
> annotation which ends up in the http session along the line
> (@SessionScoped, @ConversationScoped, various custom scopes, e.g.
> DeltaSpike @WindowScoped or @ViewAccessScoped). Or an @Dependent @Stateful
> which gets injected in a bean which ends up in the HttpSession.
> Any other EJBs which might get moved to another cluster node as a whole?
>
> Re OWB 1.1 and 1.2 compat. I fear it’s not easy. The ‚Contextual Instance‘
> stored in OWB-1.1 is _always_ without any interceptors or decorators. It
> doesn’t even contain any javassist dependencies. BUT if you inject any
> other NormalScoped bean into it _THEN_ you will have the ‚proxy shale‘ for
> those. And they of course contain javassist classes.
>
> In OWB-1.0 and 1.1 we also had a single ‚unified‘ proxy stack which
> contained NormalScoping, Interceptor logic and Decorator logic.
> In OWB-1.2 and up we did split this and now have 3 different proxies:
> NormalScoping proxies aka the ‚Contextual References‘. They are _not_ part
> of the Contextual Instance. Then we have Interceptor/Decoratpr Proxies
> (both in a single proxy class) and for abstract Decorators we also generate
> a simple proxy which just implements the missing methods. The later 2
> proxies are part of the ‚Contextual Instance‘ and thus get stored in the
> ContextualInstanceBag/SessionContext in the HttpSession.
> And of course you have the same impact of injected NormalScoped beans into
> a e.g. @SessionScoped bean as with OWB-1.1.
>
>
> I guess that wou will get hit with similar constellations in Weld as well.
>
>
> LieGrue,
> strub
>
>
>
>
> > Am 11.10.2015 um 22:28 schrieb Emily Jiang <emijiang6 at googlemail.com>:
> >
> > The EJB spec does not say anything about failover. Some EJB
> implementations can support failover between different server levels. I am
> talking about failover among the same kind. I don't believe OWB can support
> failover between cdi 1.0 and cdi 1.2, neither does Weld can do.
> >
> > On Fri, Oct 9, 2015 at 12:53 PM, Mark Struberg <struberg at yahoo.de>
> wrote:
> > Wonder the same. I’m 100% sure that it is NOT portable for NIV. Wheras
> for EJB2 style EJBs it _might_ working due to RMI/IIOP (Though don’t
> remember whether this was only specified for remoting or also for
> clustering. Nor do I remember if the spec said anything about clustering at
> all).
> >
> > I guess there often is ‚additional‘ wrapper stuff handed over in
> addition to the normal beans for EJB3 style EJBs. I know for sure that we
> do exactly that in OpenEJB. We have additional wrappers e.g. for
> transported Exceptions when doing remoting. We hand over the ’string
> representation’ and the original Exception stack data separately. In case
> we cannot de-serialize the Exception on the other side. Think about sending
> some OptimisticLockException (or even some internal Hibernate Exception)
> over to an EJB client which doesn’t have any Hibernate jars and not even
> the jaa-spec jar on it’s classpath… Similar additional information might be
> stored in any EJB proxy. Or think about Extended Persistence Contexts. How
> should that ever work to be serialized between e.g. WildFly and Glassfish?
> How would you replicate over some Hibernate Exception if the other node is
> running Glassfish with EclipseLink? :)
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 09.10.2015 um 12:54 schrieb Martin Kouba <mkouba at redhat.com>:
> > >
> > > I wonder whether this behavior is defined somewhere, i.e. if all EJB
> > > implementations must support "failover" between minor versions (e.g.
> EJB
> > > 3.0 and 3.2), in other words the passivation mechanism may not change.
> > > This would mean that an EJB app might be deployed to a "cluster" of
> > > mixed Java EE 6 and Java EE 7 app servers - seems to me like an
> > > extremely risky experiment.
> > >
> > > Martin
> > >
> > > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a):
> > >> I am investigating the HttpSession failover for SessionScoped or
> > >> ConversationScoped beans. I think it is not easy to failover from the
> > >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw
> bean
> > >> was serialised and the proxies are different between cdi 1.0 and cdi
> > >> 1.2. Has anyone have any thoughts on this? If not possible, this is a
> > >> big limitation for CDI as EJB container has no such limitation.
> > >>
> > >> --
> > >> Thanks
> > >> Emily
> > >> =================
> > >> Emily Jiang
> > >> ejiang at apache.org <mailto:ejiang at apache.org>
> > >>
> > >>
> > >> _______________________________________________
> > >> cdi-dev mailing list
> > >> cdi-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >>
> > >> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> > >>
> > >
> > > --
> > > Martin Kouba
> > > Software Engineer
> > > Red Hat, Czech Republic
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > > Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> >
> >
> > --
> > Thanks
> > Emily
> > =================
> > Emily Jiang
> > ejiang at apache.org
>
>

-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151012/cc351657/attachment-0001.html 