[jboss-jira] [JBoss JIRA] (WFLY-6583) Session leak on SmartOS hosts

[Paul Ferraro (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201122#comment-13201122 ] 

Paul Ferraro edited comment on WFLY-6583 at 5/4/16 12:26 PM:
-------------------------------------------------------------

The active-sessions metric uses the SessionManager.getActiveSessions() method - which, for a distributed session manager, will return the identifiers of the sessions residing in memory (excluding passivated sessions) of the target node.  If the SessionManager is backed by a distributed cache (as is the case with the default configuration), this will include sessions owned by the target node, as well as sessions for which the target node is a backup.  For a cluster size of 3, where each node has just created N sessions, the value for active-sessions would return, on average, 2*N (i.e. N local sessions plus N/2 sessions for each remote node).  Likewise, if the SessionManager is backed by a replicated cache, the active-sessions metric would return 3*N (i.e. N local sessions, plus N sessions for each remote node).  You can see why I am cautious about drawing premature conclusions from this mechanism of measuring the number of sessions.


was (Author: pferraro):
The active-sessions metric uses the SessionManager.getActiveSessions() method - which for a distributed session manager will return the identifiers of the sessions residing in memory (excluding passivated sessions) on the node.  If the SessionManager is backed by a distributed cache (as is the case with the default configuration), this will include sessions owned by the target node, as well as sessions for which the target node is a backup.  For a cluster size of 3, where each node has just created N sessions, the value for active-sessions would return, on average, 2*N (i.e. N local sessions plus N/2 sessions for each remote node).  Likewise, if the SessionManager is backed by a replicated cache, the active-sessions metric would return 3*N (i.e. N local sessions, plus N sessions for each remote node).  You can see why I am cautious about drawing premature conclusions from this mechanism of measuring the number of sessions.

> Session leak on SmartOS hosts
> -----------------------------
>
>                 Key: WFLY-6583
>                 URL: https://issues.jboss.org/browse/WFLY-6583
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.2.0.Final, 9.0.0.Final, 10.0.0.Final
>         Environment: CentOS 7 or SmartOS instance using Joyents Infrastructure/Bare metal container.
> [root at 979638eb-b45c-45b3-9fdb-d7f48276e4ef /]# java -version
> java version "1.8.0_77"
> Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> [root at 979638eb-b45c-45b3-9fdb-d7f48276e4ef /]# uname -a
> Linux 979638eb-b45c-45b3-9fdb-d7f48276e4ef 3.10.0 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux
> [root at 979638eb-b45c-45b3-9fdb-d7f48276e4ef /]# cat /etc/issue
> \S
> Kernel \r on an \m
>            Reporter: Michael Noack
>            Assignee: Paul Ferraro
>            Priority: Minor
>
> When running Wildfly 8.2.0-Final, 9.0.0-Final or 10.0.0-Final in domain mode using the full-ha profile some sessions never get closed when running on SmartOS or a BrandZ kernel on SmartOS. The amount of unclosed sessions rises slowly. With 1 session per second and server created, roughly 30-50 sessions are left unclosed on each server. I've been keeping track of this issue for almost a year now and handled it by restarting the entire cluster at first. It took me a while to connect the dots here.
> When registering a HttpSessionListener and logging any sessionCreated(HttpSessionEvent se) and sessionDestroyed(HttpSessionEvent se) one can cleary see some sessions never generate the sessionDestroyed event.
> The problem disappears when running the very same setup on a KVM instance of CentOS 6 or 7 (regardless whether the KVM host is SmartOS or Linux).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)