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(a)yahoo.de <mailto:struberg@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 <mailto:emijiang6@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 <mailto:struberg@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 <mailto:mkouba@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> <mailto:ejiang@apache.org <mailto:ejiang@apache.org>> > >> > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:ejiang@apache.org> -- 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.

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.

LieGrue, staub > Am 13.10.2015 um 08:44 schrieb Martin Kouba <mkouba(a)redhat.com&gt;: > > 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(a)yahoo.de >> <mailto:struberg@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 <mailto:emijiang6@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 >> <mailto:struberg@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 >> <mailto:mkouba@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> >> <mailto:ejiang@apache.org <mailto:ejiang@apache.org>> >> > >> >> > >> >> > >> _______________________________________________ >> > >> cdi-dev mailing list >> > >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:ejiang@apache.org> >> >> >> >> >> -- >> 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