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