[
https://issues.apache.org/jira/browse/GEODE-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866217#comment-16866217
]
Jacob S. Barrett commented on GEODE-6881:
-----------------------------------------
When a session expires servers side do all web servers (clients) get notified
and execute session expired callbacks?
> Revisit design for non-sticky sessions in client/server topology for Tomcat
> session module
> ------------------------------------------------------------------------------------------
>
> Key: GEODE-6881
> URL: https://issues.apache.org/jira/browse/GEODE-6881
> Project: Geode
> Issue Type: Improvement
> Components: http session
> Reporter: Ryan McMahon
> Priority: Major
>
> In order to use non-sticky sessions, a user must set enableLocalCache false
> and they should also set the (undocumented) flag
> gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK to true. The former flag sets the
> region type to PROXY on the client (no local caching) so that all operations
> must go to the server. This avoids dealing with asynchronous behavior
> resulting from local caching (event replication to local caches is performed
> through asynchronous client queues). It also causes the client to register
> interest in all keys so it gets notified of expiration/session invalidation
> events.
> The latter flag forces the server to add some additional "context" to the
> event which is forwarded to the client when an expiration/session
> invalidation occurs. That context is used to retrieve the actual session
> object and call session.expire(). This logic can easily be found by tracing
> usages of the flag in the code.
> It would be better if we could avoid setting this flag on the server, and
> instead indicate that we need this additional "context" when we register
> interest with the server. This may already be possible or it may require
> adding new API around interest registration to request the additional
> context. That way the customer does not need to remember to set this server
> flag. We might generally just want to be able to register interest in
> specific event types, such as EXPIRE_DESTROY in this case.
> If the above is not possible and we still need the second flag, we should at
> a minimum add it to the documentation so we ensure session.expire() is always
> called on the client. If this flag is not set, then session.expire() will
> not be called which may result in listeners not getting fired or resources
> not getting cleaned up.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
