7:31 a.m.
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
3:51 a.m.
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(a)uk.ibm.com>
To: weld-dev(a)lists.jboss.org
Cc: "Allan Zhang" <zhang(a)ca.ibm.com>, "Shinji Ohtsuka"
<EB92769(a)jp.ibm.com>, "Emily Jiang" <EMIJIANG(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
4:56 a.m.
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(a)redhat.com>
To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>
Cc: weld-dev(a)lists.jboss.org, Allan Zhang <zhang(a)ca.ibm.com>, Shinji
Ohtsuka <EB92769(a)jp.ibm.com>, Emily Jiang <EMIJIANG(a)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(a)uk.ibm.com>
To: weld-dev(a)lists.jboss.org
Cc: "Allan Zhang" <zhang(a)ca.ibm.com>, "Shinji Ohtsuka"
<EB92769(a)jp.ibm.com>, "Emily Jiang" <EMIJIANG(a)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(a)lists.jboss.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
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
5:17 a.m.
No, master will need to consume same fixes anyway, so it is better to have the PR up.
The only downside is that EE container based tests cannot be run there (there is no EE
container for Jakarta 9 yet).
Matej
----- Original Message -----
From: "Benjamin Confino" <BENJAMIC(a)uk.ibm.com>
To: "Matej Novotny" <manovotn(a)redhat.com>
Cc: weld-dev(a)lists.jboss.org, "Allan Zhang" <zhang(a)ca.ibm.com>,
"Shinji Ohtsuka" <EB92769(a)jp.ibm.com>, "Emily Jiang"
<EMIJIANG(a)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(a)redhat.com>
To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>
Cc: weld-dev(a)lists.jboss.org, Allan Zhang <zhang(a)ca.ibm.com>, Shinji
Ohtsuka <EB92769(a)jp.ibm.com>, Emily Jiang <EMIJIANG(a)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(a)uk.ibm.com>
> To: weld-dev(a)lists.jboss.org
> Cc: "Allan Zhang" <zhang(a)ca.ibm.com>, "Shinji Ohtsuka"
<EB92769(a)jp.ibm.com>, "Emily Jiang" <EMIJIANG(a)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(a)lists.jboss.org
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
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
6:17 a.m.
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(a)uk.ibm.com>
To: "Matej Novotny" <manovotn(a)redhat.com>
Cc: weld-dev(a)lists.jboss.org, "Allan Zhang" <zhang(a)ca.ibm.com>,
"Shinji Ohtsuka" <EB92769(a)jp.ibm.com>, "Emily Jiang"
<EMIJIANG(a)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(a)redhat.com>
To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>
Cc: weld-dev(a)lists.jboss.org, Allan Zhang <zhang(a)ca.ibm.com>, Shinji
Ohtsuka <EB92769(a)jp.ibm.com>, Emily Jiang <EMIJIANG(a)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(a)uk.ibm.com>
> To: weld-dev(a)lists.jboss.org
> Cc: "Allan Zhang" <zhang(a)ca.ibm.com>, "Shinji Ohtsuka"
<EB92769(a)jp.ibm.com>, "Emily Jiang" <EMIJIANG(a)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(a)lists.jboss.org
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
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
8:59 a.m.
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(a)redhat.com>
To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>
Cc: weld-dev(a)lists.jboss.org, Allan Zhang <zhang(a)ca.ibm.com>, Shinji
Ohtsuka <EB92769(a)jp.ibm.com>, Emily Jiang <EMIJIANG(a)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 -----
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
From: "Benjamin Confino" <BENJAMIC(a)uk.ibm.com>
To: "Matej Novotny" <manovotn(a)redhat.com>
Cc: weld-dev(a)lists.jboss.org, "Allan Zhang" <zhang(a)ca.ibm.com>,
"Shinji
Ohtsuka" <EB92769(a)jp.ibm.com>, "Emily Jiang"
<EMIJIANG(a)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(a)redhat.com>
To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>
Cc: weld-dev(a)lists.jboss.org, Allan Zhang <zhang(a)ca.ibm.com>, Shinji
Ohtsuka <EB92769(a)jp.ibm.com>, Emily Jiang <EMIJIANG(a)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(a)uk.ibm.com>
> To: weld-dev(a)lists.jboss.org
> Cc: "Allan Zhang" <zhang(a)ca.ibm.com>, "Shinji Ohtsuka"
<EB92769(a)jp.ibm.com>, "Emily Jiang" <EMIJIANG(a)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(a)lists.jboss.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
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
6:51 a.m.
Hi,
thanks for explanation, I understand the flow now.
However, your suggested PR still looks like a workaround more than a fix to me.
I doubt Weld is the only case where this will emerge. You can easily store any collection
in session and expect it to behave like we do.
So in the very least, anything of type java.util.Collection that is stored in session is
susceptible to this behaviour.
Shouldn't Liberty consider (at least after restart) any access to a collection-based
session property as an action marking that property "dirty"?
Regards
Matej
----- Original Message -----
From: "Benjamin Confino" <BENJAMIC(a)uk.ibm.com>
To: "Matej Novotny" <manovotn(a)redhat.com>
Cc: "Shinji Ohtsuka" <EB92769(a)jp.ibm.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>, weld-dev(a)lists.jboss.org, "Allan
Zhang" <zhang(a)ca.ibm.com>
Sent: Tuesday, May 5, 2020 3:59:30 PM
Subject: RE: [weld-dev] Propagation of
org.jboss.weld.context.ConversationContext.conversations through session
failover
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(a)redhat.com>
To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>
Cc: weld-dev(a)lists.jboss.org, Allan Zhang <zhang(a)ca.ibm.com>, Shinji
Ohtsuka <EB92769(a)jp.ibm.com>, Emily Jiang <EMIJIANG(a)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(a)uk.ibm.com>
> To: "Matej Novotny" <manovotn(a)redhat.com>
> Cc: weld-dev(a)lists.jboss.org, "Allan Zhang" <zhang(a)ca.ibm.com>,
"Shinji
Ohtsuka" <EB92769(a)jp.ibm.com>, "Emily Jiang"
> <EMIJIANG(a)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(a)redhat.com>
> To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>
> Cc: weld-dev(a)lists.jboss.org, Allan Zhang <zhang(a)ca.ibm.com>, Shinji
> Ohtsuka <EB92769(a)jp.ibm.com>, Emily Jiang <EMIJIANG(a)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(a)uk.ibm.com>
> > To: weld-dev(a)lists.jboss.org
> > Cc: "Allan Zhang" <zhang(a)ca.ibm.com>, "Shinji
Ohtsuka"
> <EB92769(a)jp.ibm.com>, "Emily Jiang" <EMIJIANG(a)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(a)lists.jboss.org
> >
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
>
>
>
>
>
> 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
1695
days inactive
1703
days old
6 comments
2 participants
participants (2)
-
Benjamin Confino -
Matej Novotny