<font size=2 face="sans-serif">Hello Matej<br>
<br>
No worries about the delay, my customer has not responded so you are ahead
of schedule. You are correct, the purpose of this PR is to trigger the
"dirty" state in liberty's session storage. Let me try and describe
the flow again and hopefully it will be clearer: <br>
<br>
<br>
A1) The application is started for the first time. A conversation map is
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 map
in State A</font>
<br><font size=2 face="sans-serif">A3) The server is told to shut down.<br>
A4) Liberty sees the map is dirty and saves map State A to persistent storage.
</font>
<br>
<br><font size=2 face="sans-serif">B1) The server starts again. <br>
B2) Weld retrieves the conversation map (State A) from persistent storage.
Since it already has a map it does not put anything into session storage.
Thus the map is clean. </font>
<br><font size=2 face="sans-serif">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 persistent
storage. </font>
<br>
<br><font size=2 face="sans-serif">C1) The server starts again. <br>
C2) Weld retrieves the conversation map (State A). This is the wrong state.
<br>
<br>
<br>
My PR changes B2 so that Weld will set the same map back into session storage.
Then in B4 liberty will see the map is dirty and save State B to storage,
ensuring the correct state is retrieved at C2. </font>
<br>
<br><font size=2 face="sans-serif">We do have alternative solutions, for
example you can configure Liberty to store everything regardless of whether
it is dirty or not. However this has performance implications and so my
customer does not want to use that option. <br>
<br>
Regards<br>
Benjamin<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Matej Novotny <manovotn@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Benjamin Confino <BENJAMIC@uk.ibm.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">weld-dev@lists.jboss.org,
Allan Zhang <zhang@ca.ibm.com>, Shinji Ohtsuka <EB92769@jp.ibm.com>,
Emily Jiang <EMIJIANG@uk.ibm.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">05/05/2020 12:17</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[EXTERNAL] Re:
[weld-dev] Propagation of org.jboss.weld.context.ConversationContext.conversations
through session failover</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>I finally found some time to look into this, it took
longer than I anticipated, sorry for that.<br>
<br>
Firstly, I am not quite following the flow of the reproducer you described.<br>
Weld creates the conversation map and stores in into the session on creation.
We then retrieve this map from session whenever needed and store additional
things into it.<br>
All the while we use the same map (the same reference, or object if you
will)....so Liberty should see the same state in it, right? Or am I missing
something obvious?<br>
<br>
I am not familiar with how Liberty deals with server shutdown and how it
stores session attributes, but i would expect that if you just grab the
existing map from there, it will be up to date.<br>
The PRs you sent seem superfluous to me - you are overriding the attribute
with exactly the same thing. probably just to trigger "dirty"
state in 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>,
"Shinji 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 org.jboss.weld.context.ConversationContext.conversations
through session<br>
> failover<br>
> <br>
> Thank you for the heads up. When it's time to think about delivery
I'll 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>,
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 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 9)<br>
> and the CI there is going bonkers yet as I am in the middle of changing<br>
> it.<br>
> If you want to file a PR against Weld 3, you can use 3.1 branch for
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 session<br>
> failover<br>
> > <br>
> > Hello weld<br>
> > <br>
> > I had a customer report that they were getting conversation not
found<br>
> > exceptions when restarting their server and visiting a url with
a ?cid=1<br>
> > suffix.<br>
> > <br>
> > After investigation I believe the issue is that weld was acquiring
it's<br>
> > ConversationContext.conversations from the session database via<br>
> > com.ibm.ws.session.store.db.DatabaseSession.getMultiRowAppData().
Once<br>
> weld<br>
> > had retrieved the conversations map it would then decide that
since the<br>
> map<br>
> > was already in the session attributes there was no need to put
it back<br>
> into<br>
> > the attributes.<br>
> > <br>
> > This means that Liberty did not realise the conversations map
had been<br>
> > updated, and did not store it's updated state into the database
when the<br>
> > server shut down again.<br>
> > <br>
> > I have submitted a pair of pull requests that asks weld to mark
the<br>
> > conversation map as dirty upon access - this behaviour is gated
behind<br>
> > ConfigurationKey.RESET_HTTP_SESSION_ATTR_ON_BEAN_ACCESS - I have
tested<br>
> it<br>
> > locally and it works. The next step is to prepare a test fix
for the<br>
> > customer to verify. However I wanted to send you this quick note
to 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 number<br>
> > 741598.<br>
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6<br>
> 3AU<br>
> > <br>
> > _______________________________________________<br>
> > weld-dev mailing list<br>
> > weld-dev@lists.jboss.org<br>
> > <br>
> </font></tt><a href="https://lists.jboss.org/mailman/listinfo/weld-dev"><tt><font size=2>https://lists.jboss.org/mailman/listinfo/weld-dev</font></tt></a><tt><font size=2><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></tt>
<br>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>