commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manuel Dominguez Sarmiento (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DAEMON-333) Stop abusing System.gc() on Commons Daemon jsvc shutdown
Date Wed, 03 Jun 2015 16:15:39 GMT

     [ https://issues.apache.org/jira/browse/DAEMON-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Manuel Dominguez Sarmiento updated DAEMON-333:
----------------------------------------------
    Description: 
The shutdown sequence invokes System.gc() several times. I'm not sure why this would be necessary,
especially considering that System.gc() is only a hint and the JVM will not necessarily do
anything when this method is invoked. Especially if -XX:+DisableExplicitGC is used, which
is fairly common practice in production environments.

In our case, we use rather huge heaps (over 100 GB) so shutdown can take forever, depending
on how much uncollected garbage there is in the JVM heap. We've always used -XX:+DisableExplicitGC
so this was never apparent, however we decided to stop using -XX:+DisableExplicitGC after
careful code review showed none of our apps or supporting libraries are using System.gc()
and sometimes we want to trigger GC manually from monitoring tools (Jconsole, VisualVM, etc.)
- but we found the hard way that Commons Daemon / jsvc is using System.gc() on shutdown, preventing
the speedy shutdown we were used to.

Re-introducing XX:+DisableExplicitGC fixes the problem, and shutdown is back to normal, takes
less than 8 seconds on our hardware.

  was:
The shutdown sequence invokes System.gc() several times. I'm not sure why this would be necessary,
especially considering that System.gc() is only a hint and the JVM will not necessarily do
anything when this method is invoked. Especially if -XX:+DisableExplicitGC is used, which
is fairly common practice in production environments.

In our case, we use rather huge heaps (over 100 GB) so shutdown can take forever, depending
on how much uncollected garbage there is in the JVM heap. We've always used -XX:+DisableExplicitGC
so this was never apparent, however we decided to stop using -XX:+DisableExplicitGC after
careful code review showed none of our apps or supporting libraries are using System.gc()
and sometimes we want to trigger GC manually from monitoring tools (Jconsole, VisualVM, etc.)
- but we found the hard way that Commons Daemon / jsvc is using System.gc() on shutdown, preventing
the speedy shutdown we were used to.


> Stop abusing System.gc() on Commons Daemon jsvc shutdown
> --------------------------------------------------------
>
>                 Key: DAEMON-333
>                 URL: https://issues.apache.org/jira/browse/DAEMON-333
>             Project: Commons Daemon
>          Issue Type: Bug
>          Components: Jsvc
>    Affects Versions: 1.0.15
>            Reporter: Manuel Dominguez Sarmiento
>
> The shutdown sequence invokes System.gc() several times. I'm not sure why this would
be necessary, especially considering that System.gc() is only a hint and the JVM will not
necessarily do anything when this method is invoked. Especially if -XX:+DisableExplicitGC
is used, which is fairly common practice in production environments.
> In our case, we use rather huge heaps (over 100 GB) so shutdown can take forever, depending
on how much uncollected garbage there is in the JVM heap. We've always used -XX:+DisableExplicitGC
so this was never apparent, however we decided to stop using -XX:+DisableExplicitGC after
careful code review showed none of our apps or supporting libraries are using System.gc()
and sometimes we want to trigger GC manually from monitoring tools (Jconsole, VisualVM, etc.)
- but we found the hard way that Commons Daemon / jsvc is using System.gc() on shutdown, preventing
the speedy shutdown we were used to.
> Re-introducing XX:+DisableExplicitGC fixes the problem, and shutdown is back to normal,
takes less than 8 seconds on our hardware.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message