[jira] [Updated] (GEODE-10256) HttpSessionListener is not working
[ https://issues.apache.org/jira/browse/GEODE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10256: Labels: pull-request-available (was: needsTriage pull-request-available) > HttpSessionListener is not working > -- > > Key: GEODE-10256 > URL: https://issues.apache.org/jira/browse/GEODE-10256 > Project: Geode > Issue Type: Bug > Components: expiration, http session >Affects Versions: 1.15.0 >Reporter: Masaki Yamakawa >Priority: Minor > Labels: pull-request-available > > I am using "HTTP Session Management Module for Tomcat". > When data managed in a session expires, I want to use HttpSessionListener to > handle the deletion of the associated data. > However, the sessionDestroyed method is not called when the session expires. > When session expiration is enabled, > org.apache.geode.modules.util.SessionCustomExpiry is set in all CacheServers > and Clients. > And when expiration occurs, ExpirationAction.DESTROY is executed. > DESTROY is executed on all CacheServers and clients at about the same time, > and the result of the deletion on the CacheServer is propagated to clients. > At that time, the operation type of the message sent from the CacheServer to > clients is DESTROY. > SessionExpirationCacheListener is set in the client, but > HttpSessionListener#sessionDestroyed will only be executed if > Operation.EXPIRE_DESTROY. > HttpSessionListener#sessionDestroyed is executed if the expiration process is > run first on the client side, but HttpSessionListener#sessionDestroyed is > executed if the CacheServer's DESTROY event is received first. > sessionDestroyed is not executed. > We should send the EXPIRE_DESTROY event from CacheServer, but I think this > has a big impact. > Therefore, I have introduced a Java system property that delays expiration > processing on the CacheServer. > By setting this, HttpSessionListener#sessionDestroyed will surely be executed > by delaying the server-side expiration processing rather than the client's > expiration processing. > Also, if this system property is not set, the behavior will be the same as > the current. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10256) HttpSessionListener is not working
[ https://issues.apache.org/jira/browse/GEODE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10256: Affects Version/s: 1.15.0 > HttpSessionListener is not working > -- > > Key: GEODE-10256 > URL: https://issues.apache.org/jira/browse/GEODE-10256 > Project: Geode > Issue Type: Bug > Components: expiration, http session >Affects Versions: 1.15.0 >Reporter: Masaki Yamakawa >Priority: Minor > Labels: needsTriage, pull-request-available > > I am using "HTTP Session Management Module for Tomcat". > When data managed in a session expires, I want to use HttpSessionListener to > handle the deletion of the associated data. > However, the sessionDestroyed method is not called when the session expires. > When session expiration is enabled, > org.apache.geode.modules.util.SessionCustomExpiry is set in all CacheServers > and Clients. > And when expiration occurs, ExpirationAction.DESTROY is executed. > DESTROY is executed on all CacheServers and clients at about the same time, > and the result of the deletion on the CacheServer is propagated to clients. > At that time, the operation type of the message sent from the CacheServer to > clients is DESTROY. > SessionExpirationCacheListener is set in the client, but > HttpSessionListener#sessionDestroyed will only be executed if > Operation.EXPIRE_DESTROY. > HttpSessionListener#sessionDestroyed is executed if the expiration process is > run first on the client side, but HttpSessionListener#sessionDestroyed is > executed if the CacheServer's DESTROY event is received first. > sessionDestroyed is not executed. > We should send the EXPIRE_DESTROY event from CacheServer, but I think this > has a big impact. > Therefore, I have introduced a Java system property that delays expiration > processing on the CacheServer. > By setting this, HttpSessionListener#sessionDestroyed will surely be executed > by delaying the server-side expiration processing rather than the client's > expiration processing. > Also, if this system property is not set, the behavior will be the same as > the current. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10256) HttpSessionListener is not working
[ https://issues.apache.org/jira/browse/GEODE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10256: --- Labels: needsTriage pull-request-available (was: needsTriage) > HttpSessionListener is not working > -- > > Key: GEODE-10256 > URL: https://issues.apache.org/jira/browse/GEODE-10256 > Project: Geode > Issue Type: Bug > Components: expiration, http session >Reporter: Masaki Yamakawa >Priority: Minor > Labels: needsTriage, pull-request-available > > I am using "HTTP Session Management Module for Tomcat". > When data managed in a session expires, I want to use HttpSessionListener to > handle the deletion of the associated data. > However, the sessionDestroyed method is not called when the session expires. > When session expiration is enabled, > org.apache.geode.modules.util.SessionCustomExpiry is set in all CacheServers > and Clients. > And when expiration occurs, ExpirationAction.DESTROY is executed. > DESTROY is executed on all CacheServers and clients at about the same time, > and the result of the deletion on the CacheServer is propagated to clients. > At that time, the operation type of the message sent from the CacheServer to > clients is DESTROY. > SessionExpirationCacheListener is set in the client, but > HttpSessionListener#sessionDestroyed will only be executed if > Operation.EXPIRE_DESTROY. > HttpSessionListener#sessionDestroyed is executed if the expiration process is > run first on the client side, but HttpSessionListener#sessionDestroyed is > executed if the CacheServer's DESTROY event is received first. > sessionDestroyed is not executed. > We should send the EXPIRE_DESTROY event from CacheServer, but I think this > has a big impact. > Therefore, I have introduced a Java system property that delays expiration > processing on the CacheServer. > By setting this, HttpSessionListener#sessionDestroyed will surely be executed > by delaying the server-side expiration processing rather than the client's > expiration processing. > Also, if this system property is not set, the behavior will be the same as > the current. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10256) HttpSessionListener is not working
[ https://issues.apache.org/jira/browse/GEODE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10256: -- Labels: needsTriage (was: ) > HttpSessionListener is not working > -- > > Key: GEODE-10256 > URL: https://issues.apache.org/jira/browse/GEODE-10256 > Project: Geode > Issue Type: Bug > Components: expiration, http session >Reporter: Masaki Yamakawa >Priority: Major > Labels: needsTriage > > I am using "HTTP Session Management Module for Tomcat". > When data managed in a session expires, I want to use HttpSessionListener to > handle the deletion of the associated data. > However, the sessionDestroyed method is not called when the session expires. > When session expiration is enabled, > org.apache.geode.modules.util.SessionCustomExpiry is set in all CacheServers > and Clients. > And when expiration occurs, ExpirationAction.DESTROY is executed. > DESTROY is executed on all CacheServers and clients at about the same time, > and the result of the deletion on the CacheServer is propagated to clients. > At that time, the operation type of the message sent from the CacheServer to > clients is DESTROY. > SessionExpirationCacheListener is set in the client, but > HttpSessionListener#sessionDestroyed will only be executed if > Operation.EXPIRE_DESTROY. > HttpSessionListener#sessionDestroyed is executed if the expiration process is > run first on the client side, but HttpSessionListener#sessionDestroyed is > executed if the CacheServer's DESTROY event is received first. > sessionDestroyed is not executed. > We should send the EXPIRE_DESTROY event from CacheServer, but I think this > has a big impact. > Therefore, I have introduced a Java system property that delays expiration > processing on the CacheServer. > By setting this, HttpSessionListener#sessionDestroyed will surely be executed > by delaying the server-side expiration processing rather than the client's > expiration processing. > Also, if this system property is not set, the behavior will be the same as > the current. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10256) HttpSessionListener is not working
[ https://issues.apache.org/jira/browse/GEODE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masaki Yamakawa updated GEODE-10256: Priority: Minor (was: Major) > HttpSessionListener is not working > -- > > Key: GEODE-10256 > URL: https://issues.apache.org/jira/browse/GEODE-10256 > Project: Geode > Issue Type: Bug > Components: expiration, http session >Reporter: Masaki Yamakawa >Priority: Minor > Labels: needsTriage > > I am using "HTTP Session Management Module for Tomcat". > When data managed in a session expires, I want to use HttpSessionListener to > handle the deletion of the associated data. > However, the sessionDestroyed method is not called when the session expires. > When session expiration is enabled, > org.apache.geode.modules.util.SessionCustomExpiry is set in all CacheServers > and Clients. > And when expiration occurs, ExpirationAction.DESTROY is executed. > DESTROY is executed on all CacheServers and clients at about the same time, > and the result of the deletion on the CacheServer is propagated to clients. > At that time, the operation type of the message sent from the CacheServer to > clients is DESTROY. > SessionExpirationCacheListener is set in the client, but > HttpSessionListener#sessionDestroyed will only be executed if > Operation.EXPIRE_DESTROY. > HttpSessionListener#sessionDestroyed is executed if the expiration process is > run first on the client side, but HttpSessionListener#sessionDestroyed is > executed if the CacheServer's DESTROY event is received first. > sessionDestroyed is not executed. > We should send the EXPIRE_DESTROY event from CacheServer, but I think this > has a big impact. > Therefore, I have introduced a Java system property that delays expiration > processing on the CacheServer. > By setting this, HttpSessionListener#sessionDestroyed will surely be executed > by delaying the server-side expiration processing rather than the client's > expiration processing. > Also, if this system property is not set, the behavior will be the same as > the current. -- This message was sent by Atlassian Jira (v8.20.7#820007)
