[weld-dev] Propagation of org.jboss.weld.context.ConversationContext.conversations through session failover

Tue May 5 09:59:30 EDT 2020

Hello Matej

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: 

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.
A2) The application puts stuff into the map. Lets say this leaves the map 
in State A
A3) The server is told to shut down.
A4) Liberty sees the map is dirty and saves map State A to persistent 
storage. 

B1) The server starts again. 
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. 
B3) The application does more stuff, moving the map to (State B). 
B3) The server is told to shut down.
B4) Liberty sees the map is clean, it doesn't transfer anything to 
persistent storage. 

C1) The server starts again. 
C2) Weld retrieves the conversation map (State A). This is the wrong 
state. 

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. 

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. 

Regards
Benjamin

From:   Matej Novotny <manovotn at redhat.com>
To:     Benjamin Confino <BENJAMIC at uk.ibm.com>
Cc:     weld-dev at lists.jboss.org, Allan Zhang <zhang at ca.ibm.com>, Shinji 
Ohtsuka <EB92769 at jp.ibm.com>, Emily Jiang <EMIJIANG at uk.ibm.com>
Date:   05/05/2020 12:17
Subject:        [EXTERNAL] Re: [weld-dev] Propagation of 
org.jboss.weld.context.ConversationContext.conversations through session 
failover

I finally found some time to look into this, it took longer than I 
anticipated, sorry for that.

Firstly, I am not quite following the flow of the reproducer you 
described.
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.
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?

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.
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?

Regards
Matej

----- Original Message -----
> From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
> To: "Matej Novotny" <manovotn at redhat.com>
> Cc: weld-dev at lists.jboss.org, "Allan Zhang" <zhang at ca.ibm.com>, "Shinji 
Ohtsuka" <EB92769 at jp.ibm.com>, "Emily Jiang"
> <EMIJIANG at uk.ibm.com>
> Sent: Wednesday, April 29, 2020 11:56:43 AM
> Subject: RE: [weld-dev] Propagation of 
org.jboss.weld.context.ConversationContext.conversations through session
> failover
> 
> Thank you for the heads up. When it's time to think about delivery I'll 
be
> sure to create a PR against 3.1 and I presume you'd like me to leave
> master alone for now?
> 
> Regards
> Benjamin
> 
> 
> 
> From:   Matej Novotny <manovotn at redhat.com>
> To:     Benjamin Confino <BENJAMIC at uk.ibm.com>
> Cc:     weld-dev at lists.jboss.org, Allan Zhang <zhang at ca.ibm.com>, Shinji
> Ohtsuka <EB92769 at jp.ibm.com>, Emily Jiang <EMIJIANG at uk.ibm.com>
> Date:   29/04/2020 09:51
> Subject:        [EXTERNAL] Re: [weld-dev] Propagation of
> org.jboss.weld.context.ConversationContext.conversations through session
> failover
> 
> 
> 
> Hi,
> 
> I'll take a look later today.
> Note that master branch is no longer Weld 3.x, it is 4.x (Jakarta EE 9)
> and the CI there is going bonkers yet as I am in the middle of changing
> it.
> If you want to file a PR against Weld 3, you can use 3.1 branch for 
that.
> 
> Regards
> Matej
> 
> ----- Original Message -----
> > From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
> > To: weld-dev at lists.jboss.org
> > Cc: "Allan Zhang" <zhang at ca.ibm.com>, "Shinji Ohtsuka"
> <EB92769 at jp.ibm.com>, "Emily Jiang" <EMIJIANG at uk.ibm.com>
> > Sent: Tuesday, April 28, 2020 2:31:44 PM
> > Subject: [weld-dev] Propagation of
> org.jboss.weld.context.ConversationContext.conversations through session
> failover
> > 
> > Hello weld
> > 
> > I had a customer report that they were getting conversation not found
> > exceptions when restarting their server and visiting a url with a 
?cid=1
> > suffix.
> > 
> > After investigation I believe the issue is that weld was acquiring 
it's
> > ConversationContext.conversations from the session database via
> > com.ibm.ws.session.store.db.DatabaseSession.getMultiRowAppData(). Once
> weld
> > had retrieved the conversations map it would then decide that since 
the
> map
> > was already in the session attributes there was no need to put it back
> into
> > the attributes.
> > 
> > This means that Liberty did not realise the conversations map had been
> > updated, and did not store it's updated state into the database when 
the
> > server shut down again.
> > 
> > I have submitted a pair of pull requests that asks weld to mark the
> > conversation map as dirty upon access - this behaviour is gated behind
> > ConfigurationKey.RESET_HTTP_SESSION_ATTR_ON_BEAN_ACCESS - I have 
tested
> it
> > locally and it works. The next step is to prepare a test fix for the
> > customer to verify. However I wanted to send you this quick note to 
keep
> you
> > in the loop.
> > 
> > Regards
> > Benjamin
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with 
number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> > 
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev at lists.jboss.org
> > 
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=WVR6Rz8X_vITi7c26XiQc9JlPkPasM6Px9gWE5r-pTg&s=qyzWuJ4v2pIKB7CZ39-u649jw6ouFAc8zecTq1XY1-k&e=

> 
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20200505/a4e574f0/attachment.html 