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