[cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl
Martin Kouba
mkouba at redhat.com
Tue Oct 13 03:40:39 EDT 2015
Dne 13.10.2015 v 09:24 Mark Struberg napsal(a):
> I think the best way to cluster servers of different versions is to use pairing. Of course the tupels must be of the same making.
> That way you can ‚fade out‘ old server versions by simply stopping ’new’ traffic to the old servers on the load balancer without loosing 24/7 uptime.
>
> FTR: I’m -1 on specifying every internal data structures needed for replication. That would put a huge burden on us (OWB and Weld) and would limit our possibilities in improving our software.
I have the same opinion. It would be too limiting.
>
> LieGrue,
> staub
>
>
>> Am 13.10.2015 um 08:44 schrieb Martin Kouba <mkouba at redhat.com>:
>>
>> Dne 12.10.2015 v 23:56 Emily Jiang napsal(a):
>>> 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.
>>
>> Well, not exactly. Weld stores a contextual reference (subclass), a creational context and some info about the contextual (a bean, its id, etc.). You always need these to destroy a contextual instance properly.
>>
>> And it's not compatible between weld 1.1 and 2.0+. First of all in weld 1.1 javassist is used but in 2+ it was replaced by jboss-classfilewriter. Also there are some optimizations in the contextual info part.
>>
>>>
>>> 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
>>> <mailto: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 <mailto: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
>>> <mailto: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
>>> <mailto: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>
>>> <mailto:ejiang at apache.org <mailto:ejiang at apache.org>>
>>> > >>
>>> > >>
>>> > >> _______________________________________________
>>> > >> cdi-dev mailing list
>>> > >> cdi-dev at lists.jboss.org <mailto: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 <mailto: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 <mailto: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 <mailto:ejiang at apache.org>
>>>
>>>
>>>
>>>
>>> --
>>> 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
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
More information about the cdi-dev
mailing list