[JBoss JIRA] (WFLY-6583) Session leak on SmartOS hosts
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6583?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6583:
------------------------------------
How exactly do you determine that a session was not destroyed?
For distributed web applications, there's no guarantee that the node that created a session will be the node that destroys the session.
> 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@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@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@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)
10 years
[JBoss JIRA] (WFLY-6583) Session leak on SmartOS hosts
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6583?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-6583:
-----------------------------------
What is/was the exact jvm used on systems that this occurs?
> 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@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@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@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)
10 years
[JBoss JIRA] (WFLY-6583) Session leak on SmartOS hosts
by Michael Noack (JIRA)
[ https://issues.jboss.org/browse/WFLY-6583?page=com.atlassian.jira.plugin.... ]
Michael Noack updated WFLY-6583:
--------------------------------
Description:
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 onclosed 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.
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).
was:
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. I've been keeping track of this issue for almost a year now and handled it by restarting the entire cluster at first.
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).
> 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@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@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@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 onclosed 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.
> 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)
10 years
[JBoss JIRA] (WFLY-6583) Session leak on SmartOS hosts
by Michael Noack (JIRA)
[ https://issues.jboss.org/browse/WFLY-6583?page=com.atlassian.jira.plugin.... ]
Michael Noack updated WFLY-6583:
--------------------------------
Description:
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.
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).
was:
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 onclosed 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.
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).
> 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@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@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@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.
> 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)
10 years
[JBoss JIRA] (WFLY-6583) Session leak on SmartOS hosts
by Michael Noack (JIRA)
[ https://issues.jboss.org/browse/WFLY-6583?page=com.atlassian.jira.plugin.... ]
Michael Noack updated WFLY-6583:
--------------------------------
Description:
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).
was:
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.
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).
> 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@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@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@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)
10 years
[JBoss JIRA] (WFCORE-1524) Scanner deployment failing at boot passes readiness/liveness checks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1524?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1524:
------------------------------------------
[~ehugonnet] Quick speculation:
I think this all relates to how we handle boot ops. The scanner generated deployment ops are inserted as steps into the overall boot op (the 2nd op, that does subsystems.)
That overall op does not fail because we have rollback-on-runtime-failure set to false.
But I suspect we are losing track of what is happening to the particular steps that are added by the scanner and therefore are not reporting things correctly.
> Scanner deployment failing at boot passes readiness/liveness checks
> -------------------------------------------------------------------
>
> Key: WFCORE-1524
> URL: https://issues.jboss.org/browse/WFCORE-1524
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Environment: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7/eap70-openshift:1.3-11
> Reporter: Marek Schmidt
> Assignee: ehsavoie Hugonnet
>
> During larger scale-ups (e.g. from 1 to 6 on nodes under load) deployments sometimes fail with "org.infinispan.util.concurrent.TimeoutException: Replication timeout for foo-1-xxxxx".
> That by itself is expected with the default timeouts, however, the problem is that such failed deployments pass the default EAP readiness and liveness checks, which results in HTTP 404 responses.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1524) Scanner deployment failing at boot passes readiness/liveness checks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1524?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1524:
------------------------------------------
>From an IRC chat with Rob Cernich:
{code}
[11:17am] rcernich: bstansberry: quick question, we're seeing the cli return deployment-info of failed for a deployment, but there's a .deployed file in the deployments directory (eap7)
[11:17am] bstansberry: rcernich: hi rob
[11:17am] bstansberry: rcernich: that doesn’t sound right
[11:17am] rcernich: bstansberry: infinispan fails to start (times out) and thus the deployment fails (sort of)
[11:18am] rcernich: bstansberry: the log includes "Deployed "ROOT.war" (runtime-name: "ROOT.war")
[11:19am] bstansberry: rcernich: this is all during boot, right?
[11:19am] rcernich: bstansberry: yes
[11:19am] rcernich: bstansberry: here's a link to our issue: https://issues.jboss.org/browse/CLOUD-615
[11:19am] rcernich: the log is attached
[11:20am] bstansberry: rcernich: ok, I *suspect* this is related to how failures are handled during boot
[11:21am] rcernich: bstansberry: the deployment seems to fail, as eap is returning 404's for the app url's
[11:22am] bstansberry: rcernich: right; the problem AIUI is there is no .failed file, right?
[11:22am] rcernich: bstansberry: correct (and you could say the entry in the log is misleading as well)
[11:23am] bstansberry: rcernich: I’m going to clone that JIRA into WFCORE
{code}
Note Rob's comment about the logging, which is valid in addition to the issue with the deployment marker file.
> Scanner deployment failing at boot passes readiness/liveness checks
> -------------------------------------------------------------------
>
> Key: WFCORE-1524
> URL: https://issues.jboss.org/browse/WFCORE-1524
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Environment: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7/eap70-openshift:1.3-11
> Reporter: Marek Schmidt
> Assignee: ehsavoie Hugonnet
>
> During larger scale-ups (e.g. from 1 to 6 on nodes under load) deployments sometimes fail with "org.infinispan.util.concurrent.TimeoutException: Replication timeout for foo-1-xxxxx".
> That by itself is expected with the default timeouts, however, the problem is that such failed deployments pass the default EAP readiness and liveness checks, which results in HTTP 404 responses.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1524) Scanner deployment failing at boot passes readiness/liveness checks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1524?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved CLOUD-647 to WFCORE-1524:
------------------------------------------------
Project: WildFly Core (was: Cloud Enablement)
Key: WFCORE-1524 (was: CLOUD-647)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Deployment Scanner
Domain Management
(was: EAP7)
Target Release: (was: 1.3.1.GA)
Fix Version/s: (was: 1.3.1.GA)
> Scanner deployment failing at boot passes readiness/liveness checks
> -------------------------------------------------------------------
>
> Key: WFCORE-1524
> URL: https://issues.jboss.org/browse/WFCORE-1524
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Environment: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7/eap70-openshift:1.3-11
> Reporter: Marek Schmidt
>
> During larger scale-ups (e.g. from 1 to 6 on nodes under load) deployments sometimes fail with "org.infinispan.util.concurrent.TimeoutException: Replication timeout for foo-1-xxxxx".
> That by itself is expected with the default timeouts, however, the problem is that such failed deployments pass the default EAP readiness and liveness checks, which results in HTTP 404 responses.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1524) Scanner deployment failing at boot passes readiness/liveness checks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1524?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1524:
----------------------------------------
Assignee: ehsavoie Hugonnet
> Scanner deployment failing at boot passes readiness/liveness checks
> -------------------------------------------------------------------
>
> Key: WFCORE-1524
> URL: https://issues.jboss.org/browse/WFCORE-1524
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Environment: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7/eap70-openshift:1.3-11
> Reporter: Marek Schmidt
> Assignee: ehsavoie Hugonnet
>
> During larger scale-ups (e.g. from 1 to 6 on nodes under load) deployments sometimes fail with "org.infinispan.util.concurrent.TimeoutException: Replication timeout for foo-1-xxxxx".
> That by itself is expected with the default timeouts, however, the problem is that such failed deployments pass the default EAP readiness and liveness checks, which results in HTTP 404 responses.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6583) Session leak on SmartOS hosts
by Michael Noack (JIRA)
Michael Noack created WFLY-6583:
-----------------------------------
Summary: 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: 10.0.0.Final, 9.0.0.Final, 8.2.0.Final
Environment: CentOS 7 or SmartOS instance using Joyents Infrastructure/Bare metal container.
[root@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@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@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. I've been keeping track of this issue for almost a year now and handled it by restarting the entire cluster at first.
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)
10 years