<html><body><p><font size="2">I thought this was an old bug that resolved already </font><a href="https://issues.redhat.com/browse/WELD-1130"><font size="2">https://issues.redhat.com/browse/WELD-1130</font></a><br><br><font size="2">Similarly I</font><font size="2">t was documented under know issue of </font><a href="https://issues.jboss.org/browse/JBPAPP6-1326" target="_blank"><u><font size="2" color="#0066CC">JBPAPP6-1326</font></u></a><font size="2" color="#252525"> - CDI beans with SET replication trigger are not replicating</font><font size="2"> </font><a href="https://access.redhat.com/documentation/en-us/jboss_enterprise_application_platform/6/html/release_notes_6.0.1/ar01s06" target="_blank"><u><font size="2" color="#0000FF">https://access.redhat.com/documentation/en-us/jboss_enterprise_application_platform/6/html/release_notes_6.0.1/ar01s06</font></u></a><br><font size="2" face="Arial">@Benjamin</font><font size="2"> </font><font size="2">Can the customer use </font><font size="2">SET_AND_NON_PRIMITIVE_GET </font><font size="2">setting?</font><font size="2"><br></font><br><font size="2">Thanks,<br>Allan Zhang</font><br><br><img width="16" height="16" src="cid:1__=8FBB0FF5DFCA82668f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Matej Novotny ---2020-05-12 09:10:57 AM---@Allan I read part 7.7.2 of the spec and I see no indicatio"><font size="2" color="#424282">Matej Novotny ---2020-05-12 09:10:57 AM---@Allan I read part 7.7.2 of the spec and I see no indications of such requirement there.</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Matej Novotny <manovotn@redhat.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Benjamin Confino <BENJAMIC@uk.ibm.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Shinji Ohtsuka <EB92769@jp.ibm.com>, Emily Jiang <EMIJIANG@uk.ibm.com>, weld-dev@lists.jboss.org, Allan Zhang <zhang@ca.ibm.com></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">2020-05-12 09:10 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[EXTERNAL] Re: [weld-dev] Propagation of org.jboss.weld.context.ConversationContext.conversations through session failover</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font size="2" face="Arial">@Allan<br>I read part 7.7.2 of the spec and I see no indications of such requirement there.<br>FYI, you are probably not subscribed to weld-dev list and your emails are not getting through (but I am getting them as I am in the CC) - </font><font size="2" face="Arial"><a href="https://lists.jboss.org/pipermail/weld-dev/2020-May/date.html">https://lists.jboss.org/pipermail/weld-dev/2020-May/date.html</a></font><font size="2" face="Arial"> <br><br>@Benjamin<br>> I'm investigating what can be done on our end, but since it is a<br>> grey area shouldn't weld err on the side of following Oracle's advice? Or<br>> at least include a setting to switch to following the advice?<br><br>As for Weld, the conversation map is not the only thing we store in session.<br>For instance, whole session context is stored there (every single bean). Even conversation context might be stored there and maybe something else but from the top of my head, these are quite prominent.<br>And we also do not call setAttribute() every single time a bean changes or is accessed. That would be massive perf overhead.<br>What I mean is that the issue you are seeing is a tip of an iceberg - it looks easy to fix for this one scenario/case, but it wouldn't be a complete change as multiple other things function the same way and it would require bigger code changes that I don't think are worth it.<br>What you are asking for is, simply said, an unsupported replication mode.<br><br>Unless you can change the way Liberty treats mutable attributes in session, your customer should probably swap to a mode where all attributes are stored/replicated on shutdown.<br><br>Matej<br><br>----- Original Message -----<br>> From: "Benjamin Confino" <BENJAMIC@uk.ibm.com><br>> To: "Matej Novotny" <manovotn@redhat.com><br>> Cc: "Shinji Ohtsuka" <EB92769@jp.ibm.com>, "Emily Jiang" <EMIJIANG@uk.ibm.com>, weld-dev@lists.jboss.org, "Allan<br>> Zhang" <zhang@ca.ibm.com><br>> Sent: Monday, May 11, 2020 11:02:04 PM<br>> Subject: RE: [weld-dev] Propagation of org.jboss.weld.context.ConversationContext.conversations through session<br>> failover<br>> <br>> Hello<br>> <br>> I spoke to Allan and he agrees with you that it is a grey area in the<br>> spec. I'm investigating what can be done on our end, but since it is a<br>> grey area shouldn't weld err on the side of following Oracle's advice? Or<br>> at least include a setting to switch to following the advice? Especially<br>> since it would be technically simple to do so; as the map is only modified<br>> in one class and Allan says it would be a good performance improvement.<br>> <br>> Regards<br>> Benjamin<br>> <br>> <br>> <br>> From: Matej Novotny <manovotn@redhat.com><br>> To: Benjamin Confino <BENJAMIC@uk.ibm.com><br>> Cc: Allan Zhang <zhang@ca.ibm.com>, Shinji Ohtsuka<br>> <EB92769@jp.ibm.com>, Emily Jiang <EMIJIANG@uk.ibm.com>,<br>> weld-dev@lists.jboss.org<br>> Date: 11/05/2020 09:33<br>> Subject: [EXTERNAL] Re: [weld-dev] Propagation of<br>> org.jboss.weld.context.ConversationContext.conversations through session<br>> failover<br>> <br>> <br>> <br>> The document you linked is not a specification itself and as such is not<br>> binding. Do you have an actual specification bits that prove this?<br>> <br>> I went looking into servlet specification[1] and asked someone from WFLY<br>> who has more expertise in this field to also take a look.<br>> None of us found anything stating that you are required to call<br>> setAttribute() every time you change mutable attribute.<br>> In fact there is very little about attributes (or "replication triggers"<br>> for attributes) and you could say this is grey area.<br>> <br>> To me it still makes way more sense to distinguish between<br>> mutable/immutable attributes and for mutable ones you should set "dirty"<br>> state even on read, not just write.<br>> <br>> Matej<br>> _____________________________________________________________________________________<br>> [1]<br>> </font><font size="2" face="Arial"><a href="https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf">https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf</a></font><font size="2" face="Arial"><br>> <br>> <br>> ----- Original Message -----<br>> > From: "Benjamin Confino" <BENJAMIC@uk.ibm.com><br>> > To: "Allan Zhang" <zhang@ca.ibm.com><br>> > Cc: "Matej Novotny" <manovotn@redhat.com>, "Shinji Ohtsuka"<br>> <EB92769@jp.ibm.com>, "Emily Jiang"<br>> > <EMIJIANG@uk.ibm.com>, weld-dev@lists.jboss.org<br>> > Sent: Thursday, May 7, 2020 12:41:01 PM<br>> > Subject: RE: [weld-dev] Propagation of<br>> org.jboss.weld.context.ConversationContext.conversations through session<br>> > failover<br>> > <br>> > Hello<br>> > <br>> > Based on Allan Zhang's comments I have closed my pull requests and<br>> opened<br>> > this one<br>> </font><font size="2" face="Arial"><a href="https://github.com/weld/core/pull/1990">https://github.com/weld/core/pull/1990</a></font><font size="2" face="Arial"><br>> which is a better match<br>> > for the recommendations in the sessionmanagement spec. I still have not<br>> > heard back from my customer so I will compile an updated test fix and<br>> > chase them up. If they approve, or if they do not reply soon I will<br>> create<br>> > pull requests for the other branches.<br>> > <br>> > Regards<br>> > Benjamin<br>> > <br>> > <br>> > <br>> > From: Allan Zhang/Toronto/IBM<br>> > To: Matej Novotny <manovotn@redhat.com><br>> > Cc: Benjamin Confino <BENJAMIC@uk.ibm.com>, Shinji Ohtsuka<br>> > <EB92769@jp.ibm.com>, Emily Jiang <EMIJIANG@uk.ibm.com>,<br>> > weld-dev@lists.jboss.org<br>> > Date: 06/05/2020 17:42<br>> > Subject: Re: [EXTERNAL] Re: [weld-dev] Propagation of<br>> > org.jboss.weld.context.ConversationContext.conversations through session<br>> > failover<br>> > <br>> > <br>> > <br>> > >Shouldn't Liberty consider (at least after restart) any access to a<br>> > collection-based session property as an action marking that property<br>> > "dirty"?<br>> > <br>> > Liberty already has write option of ALL_SESSION_ATTRIBUTES to mark the<br>> > property "dirty" but customer wont use it for performance reasons.<br>> > <br>> > The PR fix is following the JEE spec where property "dirty" require<br>> > setAttribute() call.<br>> > <br>> </font><font size="2" face="Arial"><a href="https://docs.oracle.com/cd/E13924_01/coh.340/e13819/sessionmanagement.htm">https://docs.oracle.com/cd/E13924_01/coh.340/e13819/sessionmanagement.htm</a></font><font size="2" face="Arial"><br>> <br>> > <br>> > As a general rule, all session attributes should be treated as immutable<br>> > objects if possible. This ensures that developers are consciously aware<br>> > when they change attributes. With mutable objects, modifying attributes<br>> > often requires two steps: modifying the state of the attribute object,<br>> and<br>> > then manually updating the session with the modified attribute object by<br>> > calling javax.servlet.http.HttpSession.setAttribute(). This means that<br>> > your application should always call setAttribute() if the attribute<br>> value<br>> > has been changed, otherwise, the modified attribute value will not<br>> > replicate to the backup server.<br>> > <br>> > Thanks<br>> > Allan Zhang<br>> > <br>> > <br>> > <br>> > <br>> > From: Matej Novotny <manovotn@redhat.com><br>> > To: Benjamin Confino <BENJAMIC@uk.ibm.com><br>> > Cc: Shinji Ohtsuka <EB92769@jp.ibm.com>, Emily Jiang<br>> > <EMIJIANG@uk.ibm.com>, weld-dev@lists.jboss.org, Allan Zhang<br>> > <zhang@ca.ibm.com><br>> > Date: 2020-05-06 07:52 AM<br>> > Subject: [EXTERNAL] Re: [weld-dev] Propagation of<br>> > org.jboss.weld.context.ConversationContext.conversations through session<br>> > failover<br>> > <br>> > <br>> > <br>> > Hi,<br>> > <br>> > thanks for explanation, I understand the flow now.<br>> > <br>> > However, your suggested PR still looks like a workaround more than a fix<br>> > to me.<br>> > <br>> > I doubt Weld is the only case where this will emerge. You can easily<br>> store<br>> > any collection in session and expect it to behave like we do.<br>> > So in the very least, anything of type java.util.Collection that is<br>> stored<br>> > in session is susceptible to this behaviour.<br>> > Shouldn't Liberty consider (at least after restart) any access to a<br>> > collection-based session property as an action marking that property<br>> > "dirty"?<br>> > <br>> > Regards<br>> > Matej<br>> > <br>> > ----- Original Message -----<br>> > > From: "Benjamin Confino" <BENJAMIC@uk.ibm.com><br>> > > To: "Matej Novotny" <manovotn@redhat.com><br>> > > Cc: "Shinji Ohtsuka" <EB92769@jp.ibm.com>, "Emily Jiang"<br>> > <EMIJIANG@uk.ibm.com>, weld-dev@lists.jboss.org, "Allan<br>> > > Zhang" <zhang@ca.ibm.com><br>> > > Sent: Tuesday, May 5, 2020 3:59:30 PM<br>> > > Subject: RE: [weld-dev] Propagation of<br>> > org.jboss.weld.context.ConversationContext.conversations through session<br>> > > failover<br>> > > <br>> > > Hello Matej<br>> > > <br>> > > No worries about the delay, my customer has not responded so you are<br>> > ahead<br>> > > of schedule. You are correct, the purpose of this PR is to trigger the<br>> > > "dirty" state in liberty's session storage. Let me try and describe<br>> the<br>> > > flow again and hopefully it will be clearer:<br>> > > <br>> > > <br>> > > A1) The application is started for the first time. A conversation map<br>> is<br>> > > created and stored into the session context. This marks it as dirty.<br>> > > A2) The application puts stuff into the map. Lets say this leaves the<br>> > map<br>> > > in State A<br>> > > A3) The server is told to shut down.<br>> > > A4) Liberty sees the map is dirty and saves map State A to persistent<br>> > > storage.<br>> > > <br>> > > B1) The server starts again.<br>> > > B2) Weld retrieves the conversation map (State A) from persistent<br>> > storage.<br>> > > Since it already has a map it does not put anything into session<br>> > storage.<br>> > > Thus the map is clean.<br>> > > B3) The application does more stuff, moving the map to (State B).<br>> > > B3) The server is told to shut down.<br>> > > B4) Liberty sees the map is clean, it doesn't transfer anything to<br>> > > persistent storage.<br>> > > <br>> > > C1) The server starts again.<br>> > > C2) Weld retrieves the conversation map (State A). This is the wrong<br>> > > state.<br>> > > <br>> > > <br>> > > My PR changes B2 so that Weld will set the same map back into session<br>> > > storage. Then in B4 liberty will see the map is dirty and save State B<br>> > to<br>> > > storage, ensuring the correct state is retrieved at C2.<br>> > > <br>> > > We do have alternative solutions, for example you can configure<br>> Liberty<br>> > to<br>> > > store everything regardless of whether it is dirty or not. However<br>> this<br>> > > has performance implications and so my customer does not want to use<br>> > that<br>> > > option.<br>> > > <br>> > > Regards<br>> > > Benjamin<br>> > > <br>> > > <br>> > > <br>> > > <br>> > > From: Matej Novotny <manovotn@redhat.com><br>> > > To: Benjamin Confino <BENJAMIC@uk.ibm.com><br>> > > Cc: weld-dev@lists.jboss.org, Allan Zhang <zhang@ca.ibm.com>,<br>> Shinji<br>> > > Ohtsuka <EB92769@jp.ibm.com>, Emily Jiang <EMIJIANG@uk.ibm.com><br>> > > Date: 05/05/2020 12:17<br>> > > Subject: [EXTERNAL] Re: [weld-dev] Propagation of<br>> > > org.jboss.weld.context.ConversationContext.conversations through<br>> session<br>> > > failover<br>> > > <br>> > > <br>> > > <br>> > > I finally found some time to look into this, it took longer than I<br>> > > anticipated, sorry for that.<br>> > > <br>> > > Firstly, I am not quite following the flow of the reproducer you<br>> > > described.<br>> > > Weld creates the conversation map and stores in into the session on<br>> > > creation. We then retrieve this map from session whenever needed and<br>> > store<br>> > > additional things into it.<br>> > > All the while we use the same map (the same reference, or object if<br>> you<br>> > > will)....so Liberty should see the same state in it, right? Or am I<br>> > > missing something obvious?<br>> > > <br>> > > I am not familiar with how Liberty deals with server shutdown and how<br>> it<br>> > > stores session attributes, but i would expect that if you just grab<br>> the<br>> > > existing map from there, it will be up to date.<br>> > > The PRs you sent seem superfluous to me - you are overriding the<br>> > attribute<br>> > > with exactly the same thing. probably just to trigger "dirty" state in<br>> > > your session storage?<br>> > > <br>> > > Regards<br>> > > Matej<br>> > > <br>> > > ----- Original Message -----<br>> > > > From: "Benjamin Confino" <BENJAMIC@uk.ibm.com><br>> > > > To: "Matej Novotny" <manovotn@redhat.com><br>> > > > Cc: weld-dev@lists.jboss.org, "Allan Zhang" <zhang@ca.ibm.com>,<br>> > "Shinji<br>> > > Ohtsuka" <EB92769@jp.ibm.com>, "Emily Jiang"<br>> > > > <EMIJIANG@uk.ibm.com><br>> > > > Sent: Wednesday, April 29, 2020 11:56:43 AM<br>> > > > Subject: RE: [weld-dev] Propagation of<br>> > > org.jboss.weld.context.ConversationContext.conversations through<br>> session<br>> > > > failover<br>> > > > <br>> > > > Thank you for the heads up. When it's time to think about delivery<br>> > I'll<br>> > > be<br>> > > > sure to create a PR against 3.1 and I presume you'd like me to leave<br>> > > > master alone for now?<br>> > > > <br>> > > > Regards<br>> > > > Benjamin<br>> > > > <br>> > > > <br>> > > > <br>> > > > From: Matej Novotny <manovotn@redhat.com><br>> > > > To: Benjamin Confino <BENJAMIC@uk.ibm.com><br>> > > > Cc: weld-dev@lists.jboss.org, Allan Zhang <zhang@ca.ibm.com>,<br>> > Shinji<br>> > > > Ohtsuka <EB92769@jp.ibm.com>, Emily Jiang <EMIJIANG@uk.ibm.com><br>> > > > Date: 29/04/2020 09:51<br>> > > > Subject: [EXTERNAL] Re: [weld-dev] Propagation of<br>> > > > org.jboss.weld.context.ConversationContext.conversations through<br>> > session<br>> > > > failover<br>> > > > <br>> > > > <br>> > > > <br>> > > > Hi,<br>> > > > <br>> > > > I'll take a look later today.<br>> > > > Note that master branch is no longer Weld 3.x, it is 4.x (Jakarta EE<br>> > 9)<br>> > > > and the CI there is going bonkers yet as I am in the middle of<br>> > changing<br>> > > > it.<br>> > > > If you want to file a PR against Weld 3, you can use 3.1 branch for<br>> > > that.<br>> > > > <br>> > > > Regards<br>> > > > Matej<br>> > > > <br>> > > > ----- Original Message -----<br>> > > > > From: "Benjamin Confino" <BENJAMIC@uk.ibm.com><br>> > > > > To: weld-dev@lists.jboss.org<br>> > > > > Cc: "Allan Zhang" <zhang@ca.ibm.com>, "Shinji Ohtsuka"<br>> > > > <EB92769@jp.ibm.com>, "Emily Jiang" <EMIJIANG@uk.ibm.com><br>> > > > > Sent: Tuesday, April 28, 2020 2:31:44 PM<br>> > > > > Subject: [weld-dev] Propagation of<br>> > > > org.jboss.weld.context.ConversationContext.conversations through<br>> > session<br>> > > > failover<br>> > > > > <br>> > > > > Hello weld<br>> > > > > <br>> > > > > I had a customer report that they were getting conversation not<br>> > found<br>> > > > > exceptions when restarting their server and visiting a url with a<br>> > > ?cid=1<br>> > > > > suffix.<br>> > > > > <br>> > > > > After investigation I believe the issue is that weld was acquiring<br>> > > it's<br>> > > > > ConversationContext.conversations from the session database via<br>> > > > > com.ibm.ws.session.store.db.DatabaseSession.getMultiRowAppData().<br>> > Once<br>> > > > weld<br>> > > > > had retrieved the conversations map it would then decide that<br>> since<br>> > > the<br>> > > > map<br>> > > > > was already in the session attributes there was no need to put it<br>> > back<br>> > > > into<br>> > > > > the attributes.<br>> > > > > <br>> > > > > This means that Liberty did not realise the conversations map had<br>> > been<br>> > > > > updated, and did not store it's updated state into the database<br>> when<br>> > > the<br>> > > > > server shut down again.<br>> > > > > <br>> > > > > I have submitted a pair of pull requests that asks weld to mark<br>> the<br>> > > > > conversation map as dirty upon access - this behaviour is gated<br>> > behind<br>> > > > > ConfigurationKey.RESET_HTTP_SESSION_ATTR_ON_BEAN_ACCESS - I have<br>> > > tested<br>> > > > it<br>> > > > > locally and it works. The next step is to prepare a test fix for<br>> the<br>> > > > > customer to verify. However I wanted to send you this quick note<br>> to<br>> > > keep<br>> > > > you<br>> > > > > in the loop.<br>> > > > > <br>> > > > > Regards<br>> > > > > Benjamin<br>> > > > > Unless stated otherwise above:<br>> > > > > IBM United Kingdom Limited - Registered in England and Wales with<br>> > > number<br>> > > > > 741598.<br>> > > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire<br>> > PO6<br>> > > > 3AU<br>> > > > > <br>> > > > > _______________________________________________<br>> > > > > weld-dev mailing list<br>> > > > > weld-dev@lists.jboss.org<br>> > > > > <br>> > > > <br>> > > <br>> > <br>> </font><font size="2" face="Arial"><a href="https://lists.jboss.org/mailman/listinfo/weld-dev">https://lists.jboss.org/mailman/listinfo/weld-dev</a></font><font size="2" face="Arial"><br>> <br>> > <br>> > > <br>> > > > <br>> > > > <br>> > > > <br>> > > > <br>> > > > <br>> > > > Unless stated otherwise above:<br>> > > > IBM United Kingdom Limited - Registered in England and Wales with<br>> > number<br>> > > > 741598.<br>> > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire<br>> PO6<br>> > > 3AU<br>> > > > <br>> > > <br>> > > <br>> > > <br>> > > <br>> > > Unless stated otherwise above:<br>> > > IBM United Kingdom Limited - Registered in England and Wales with<br>> number<br>> > > 741598.<br>> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6<br>> > 3AU<br>> > > <br>> > <br>> > <br>> > <br>> > <br>> > <br>> > Unless stated otherwise above:<br>> > IBM United Kingdom Limited - Registered in England and Wales with number<br>> > 741598.<br>> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6<br>> 3AU<br>> > <br>> <br>> <br>> <br>> <br>> Unless stated otherwise above:<br>> IBM United Kingdom Limited - Registered in England and Wales with number<br>> 741598.<br>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU<br>> <br><br></font><br><br><BR>
</body></html>