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.
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(a)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(a)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(a)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(a)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(a)apache.org <mailto:ejiang@apache.org>
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev(a)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(a)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(a)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(a)apache.org