[ 
https://issues.apache.org/jira/browse/GEODE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528391#comment-17528391
 ] 

Jens Deppe commented on GEODE-10256:
------------------------------------

Hello [~masaki.yamakawa]! Thank you for this ticket and the analysis.

So the relevant code is here inĀ 
[SessionExpirationCacheListener|https://github.com/apache/geode/blob/a5bd36f9fa787d3a71c6e6efafed5a7b0fe52d2b/extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/callback/SessionExpirationCacheListener.java].
 The essence of what you're seeing is coming from the {{afterDestroy}} method 
and the if-else block there. So the first part of the {{if}} handles a destroy 
triggered by expiry on the client. The second part should handle an expiry from 
the server. However the caveat is that you need to set the system parameter, 
indicated in the comment there, 
({{{}gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK{}}}), on the server. That should 
then allow any listeners to fire even when receiving a destroy from the server. 
The comment does indicate that this is only relevant for {{PROXY}} (empty) 
regions but I think that may be incorrect. Please would you try this change and 
let us know the outcome.

> 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)

Reply via email to