July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12200) Upgrade jboss-ejb-client from 4.0.18 to 4.0.20

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-12200?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-12200: --------------------------------- Fix Version/s: 17.0.1.Final > Upgrade jboss-ejb-client from 4.0.18 to 4.0.20 > ---------------------------------------------- > > Key: WFLY-12200 > URL: https://issues.jboss.org/browse/WFLY-12200 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Affects Versions: 17.0.0.Final > Reporter: Teresa Miyar Gil > Assignee: Cheng Fang > Priority: Major > Fix For: 17.0.1.Final, 18.0.0.Beta1 > > > compare between 4.0.18.Final and the next version (4.0.20.Final): > https://github.com/wildfly/jboss-ejb-client/compare/4.0.18.Final...4.0.20... > Any particular fixes are you expecting? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12266) Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created.

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12266?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12266: -------------------------------- Description: As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with second precision (since session timeouts only have second precision). However, we assume that a given distributed session is "new" if its last access duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is not unlikely that users will encounter this problem. Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. was: As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with second precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is not unlikely that users will encounter this problem. Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. > Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12266 > URL: https://issues.jboss.org/browse/WFLY-12266 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 17.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with second precision (since session timeouts only have second precision). However, we assume that a given distributed session is "new" if its last access duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is not unlikely that users will encounter this problem. > Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12266) Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created.

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12266?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12266: -------------------------------- Description: As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with second precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is not unlikely that users will encounter this problem. Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. was: As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with seconds precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is likely that users will encounter this problem. Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. > Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12266 > URL: https://issues.jboss.org/browse/WFLY-12266 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 17.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with second precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is not unlikely that users will encounter this problem. > Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12266) Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created.

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12266?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12266: -------------------------------- Description: As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with seconds precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is likely that users will encounter this problem. Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. was:As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with seconds precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is likely that users will encounter this problem. > Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12266 > URL: https://issues.jboss.org/browse/WFLY-12266 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 17.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with seconds precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is likely that users will encounter this problem. > Essentially, the existing code assumes that Duration.ofSeconds(0) != Duration.ZERO. Unfortunately, this is false. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12266) Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created.

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12266?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12266: -------------------------------- Priority: Critical (was: Blocker) > Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12266 > URL: https://issues.jboss.org/browse/WFLY-12266 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 17.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with seconds precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is likely that users will encounter this problem. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12266) Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created.

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12266: ----------------------------------- Summary: Distributed session changes fail to replicate if subsequent request arrives < 1 second after session was created. Key: WFLY-12266 URL: https://issues.jboss.org/browse/WFLY-12266 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 17.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro As a marshalling optimization, the last access duration of a session (i.e. the duration of time since the session was created) is stored with seconds precision. However, we assume that a given distributed session is "new" if it's duration is 0. When the backing cache is transactional, we don't perform any mutations when a new session is closed. Thus if a request arrives < 1 second after a session was created, any changes will not be replicated. Given the prevalence of redirects after a session is created, it is likely that users will encounter this problem. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12265) Out of specification: Singleton EJB is allowed to implement SessionBean interface.

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12265?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-12265: ------------------------------ Fix Version/s: 18.0.0.Beta1 > Out of specification: Singleton EJB is allowed to implement SessionBean interface. > ---------------------------------------------------------------------------------- > > Key: WFLY-12265 > URL: https://issues.jboss.org/browse/WFLY-12265 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 16.0.0.Final, 17.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Fix For: 18.0.0.Beta1 > > Attachments: SingletonBean.java > > > Singleton EJB is allowed to implement SessionBean interface and the EJB 3.2 spec says in section 4.9.2 Session Bean Class: > "The class may implement, directly or indirectly, the javax.ejb.SessionBean interface. Except for singleton session beans." > EAP should throw an exception or log a warning that it is not valid by the spec. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12265) Out of specification: Singleton EJB is allowed to implement SessionBean interface.

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12265?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-12265: ------------------------------ Summary: Out of specification: Singleton EJB is allowed to implement SessionBean interface. (was: [GSS](7.2.z) Out of specification: Singleton EJB is allowed to implement SessionBean interface.) > Out of specification: Singleton EJB is allowed to implement SessionBean interface. > ---------------------------------------------------------------------------------- > > Key: WFLY-12265 > URL: https://issues.jboss.org/browse/WFLY-12265 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 16.0.0.Final, 17.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: SingletonBean.java > > > Singleton EJB is allowed to implement SessionBean interface and the EJB 3.2 spec says in section 4.9.2 Session Bean Class: > "The class may implement, directly or indirectly, the javax.ejb.SessionBean interface. Except for singleton session beans." > EAP should throw an exception or log a warning that it is not valid by the spec. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12265) [GSS](7.2.z) Out of specification: Singleton EJB is allowed to implement SessionBean interface.

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12265?page=com.atlassian.jira.plugin... ] Cheng Fang moved JBEAP-17130 to WFLY-12265: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-12265 (was: JBEAP-17130) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Affects Version/s: 17.0.0.Final (was: 7.2.1.GA) > [GSS](7.2.z) Out of specification: Singleton EJB is allowed to implement SessionBean interface. > ----------------------------------------------------------------------------------------------- > > Key: WFLY-12265 > URL: https://issues.jboss.org/browse/WFLY-12265 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 17.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: SingletonBean.java > > > Singleton EJB is allowed to implement SessionBean interface and the EJB 3.2 spec says in section 4.9.2 Session Bean Class: > "The class may implement, directly or indirectly, the javax.ejb.SessionBean interface. Except for singleton session beans." > EAP should throw an exception or log a warning that it is not valid by the spec. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12265) [GSS](7.2.z) Out of specification: Singleton EJB is allowed to implement SessionBean interface.

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12265?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-12265: ------------------------------ Affects Version/s: 16.0.0.Final > [GSS](7.2.z) Out of specification: Singleton EJB is allowed to implement SessionBean interface. > ----------------------------------------------------------------------------------------------- > > Key: WFLY-12265 > URL: https://issues.jboss.org/browse/WFLY-12265 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 16.0.0.Final, 17.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: SingletonBean.java > > > Singleton EJB is allowed to implement SessionBean interface and the EJB 3.2 spec says in section 4.9.2 Session Bean Class: > "The class may implement, directly or indirectly, the javax.ejb.SessionBean interface. Except for singleton session beans." > EAP should throw an exception or log a warning that it is not valid by the spec. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2019