karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rico Neubauer (JIRA)" <j...@apache.org>
Subject [jira] [Created] (KARAF-5628) Corrupt gc.log due to unseparated VM settings
Date Mon, 19 Feb 2018 10:26:00 GMT
Rico Neubauer created KARAF-5628:
------------------------------------

             Summary: Corrupt gc.log due to unseparated VM settings
                 Key: KARAF-5628
                 URL: https://issues.apache.org/jira/browse/KARAF-5628
             Project: Karaf
          Issue Type: Bug
          Components: karaf-core
            Reporter: Rico Neubauer


The VM properties used for the start, stop, status and client scripts all use one common configuration
of the VM properties, like Xmx and GC settings.

This has one particular issue when activating the gc.log (-Xloggc:gc.log with Oracle-VM):
Invoking e.g. status while Karaf is running, uses the same settings, thus points to the same
file and corrupts it with NUL values (see here for details: [Stackoverflow|[https://stackoverflow.com/questions/8353401/garbage-collector-log-loggc-file-rotation-with-logrotate-does-not-work-properl]).]

 

I would like to request the possibility to configure the VM properties for starting the instance
independently from the maintenance scripts - due to the issue and also since e.g. running
status with lots of heap (if instance is configured to it) is unneeded.

 

Even making it broader, I think it would also make sense to be able to configure the settings
completely, since currently some things are hard-coded in the scripts, like the _-Xdum_p
and _-Xlp_ settings  for AIX, where I personally would like to configure it to _-Xdump:heap:events=gpf,opts=PHD_,
which is currently not possible using the configuration only. Also especially for AIX, there
is _LDR_CNTRL=MAXDATA=0xB0000000@DSA_, which might not be desired when running with heaps
larger than 3GB.

 

If you agree on a separation, I would make a proposal as PR. Please let me know.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message