[JBoss JIRA] (WFLY-6540) Batch thread pool keepAlive setting seems to be ignored
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-6540?page=com.atlassian.jira.plugin.... ]
Martin Kouba updated WFLY-6540:
-------------------------------
Description:
Maybe I'm missing something but although the default _keepAlive_ is set to 30 seconds, the threads seem to run indefinitely - see also steps to reproduce.
Snippet from the default config file:
{code}
<thread-pool name="batch">
<max-threads count="10"/>
<keepalive-time time="30" unit="seconds"/>
</thread-pool>
{code}
Anyway, the {{UnboundedQueueThreadPoolService}}, or the underlying {{JBossThreadPoolExecutor}} respectively, used by the Batch subsystem is using the same {{corePoolSize}} and {{maximumPoolSize}} and it seems the core threads are not allowed to time out, i.e. {{org.jboss.threads.JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} is not used.
Moreover, a {{JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} invocation would probably result in an infinite loop:
{code}
public void setAllowCoreThreadTimeout(final boolean allow) {
setAllowCoreThreadTimeout(allow);
}
{code}
should be replaced with:
{code}
public void setAllowCoreThreadTimeout(final boolean allow) {
allowCoreThreadTimeOut(allow);
}
{code}
Given that {{JBossThreadPoolExecutor}} is used by more subsystems this issue may affect other subsystems as well.
was:
Maybe I'm missing something but although the default _keepAlive_ is set to 30 seconds, the threads seem to run indefinitely - see also steps to reproduce.
Snippet from the default config file:
{code}
<thread-pool name="batch">
<max-threads count="10"/>
<keepalive-time time="30" unit="seconds"/>
</thread-pool>
{code}
Anyway, the {{UnboundedQueueThreadPoolService}}, or the underlying {{JBossThreadPoolExecutor}} respectively, used by the Batch subsystem is using the same {{corePoolSize}} and {{maximumPoolSize}} and it seems the core threads are not allowed to time out, i.e. {{org.jboss.threads.JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} is not used.
Moreover, a {{JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} invocation would probably result in infinite loop:
{code}
public void setAllowCoreThreadTimeout(final boolean allow) {
setAllowCoreThreadTimeout(allow);
}
{code}
should be replaced with:
{code}
public void setAllowCoreThreadTimeout(final boolean allow) {
allowCoreThreadTimeOut(allow);
}
{code}
Given that {{JBossThreadPoolExecutor}} is used by more subsystems this issue may affect other subsystems as well.
> Batch thread pool keepAlive setting seems to be ignored
> -------------------------------------------------------
>
> Key: WFLY-6540
> URL: https://issues.jboss.org/browse/WFLY-6540
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 10.0.0.Final
> Reporter: Martin Kouba
> Assignee: James Perkins
>
> Maybe I'm missing something but although the default _keepAlive_ is set to 30 seconds, the threads seem to run indefinitely - see also steps to reproduce.
> Snippet from the default config file:
> {code}
> <thread-pool name="batch">
> <max-threads count="10"/>
> <keepalive-time time="30" unit="seconds"/>
> </thread-pool>
> {code}
> Anyway, the {{UnboundedQueueThreadPoolService}}, or the underlying {{JBossThreadPoolExecutor}} respectively, used by the Batch subsystem is using the same {{corePoolSize}} and {{maximumPoolSize}} and it seems the core threads are not allowed to time out, i.e. {{org.jboss.threads.JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} is not used.
> Moreover, a {{JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} invocation would probably result in an infinite loop:
> {code}
> public void setAllowCoreThreadTimeout(final boolean allow) {
> setAllowCoreThreadTimeout(allow);
> }
> {code}
> should be replaced with:
> {code}
> public void setAllowCoreThreadTimeout(final boolean allow) {
> allowCoreThreadTimeOut(allow);
> }
> {code}
> Given that {{JBossThreadPoolExecutor}} is used by more subsystems this issue may affect other subsystems as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1495) server instances cannot find keytab during domain startup
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1495?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1495:
----------------------------------------
Assignee: (was: Brian Stansberry)
> server instances cannot find keytab during domain startup
> ---------------------------------------------------------
>
> Key: WFCORE-1495
> URL: https://issues.jboss.org/browse/WFCORE-1495
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Derek Horton
>
> In domain mode, the server instances cannot find the keytab if the ApplicationRealm is configured to use kerberos as the server-identity:
> {code}
> <security-realm name="ApplicationRealm">
> <server-identities>
> <kerberos>
> <keytab principal="remote/imahost.imadomain.net@VM29" path="/path/to/keytab"/>
> </kerberos>
> </server-identities>
> <authentication>
> <kerberos remove-realm="true"/>
> </authentication>
> <authorization>
> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
> </authorization>
> </security-realm>
> {code}
> This results in the following error and the server instances fail to start:
> [Server:server-one] 15:10:35,360 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("validate-authentication") failed - address: ([
> [Server:server-one] ("core-service" => "management"),
> [Server:server-one] ("security-realm" => "ApplicationRealm")
> [Server:server-one] ]) - failure description: "WFLYDM0094: Kerberos is enabled for authentication on security realm 'ApplicationRealm' but no Keytab has been added to the server-identity."
> [Server:server-one] 15:10:35,376 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1495) server instances cannot find keytab during domain startup
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1495?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-4274 to WFCORE-1495:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1495 (was: JBEAP-4274)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
Security
(was: Domain Management)
(was: Security)
Target Release: (was: 7.backlog.GA)
> server instances cannot find keytab during domain startup
> ---------------------------------------------------------
>
> Key: WFCORE-1495
> URL: https://issues.jboss.org/browse/WFCORE-1495
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Derek Horton
> Assignee: Brian Stansberry
>
> In domain mode, the server instances cannot find the keytab if the ApplicationRealm is configured to use kerberos as the server-identity:
> {code}
> <security-realm name="ApplicationRealm">
> <server-identities>
> <kerberos>
> <keytab principal="remote/imahost.imadomain.net@VM29" path="/path/to/keytab"/>
> </kerberos>
> </server-identities>
> <authentication>
> <kerberos remove-realm="true"/>
> </authentication>
> <authorization>
> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
> </authorization>
> </security-realm>
> {code}
> This results in the following error and the server instances fail to start:
> [Server:server-one] 15:10:35,360 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("validate-authentication") failed - address: ([
> [Server:server-one] ("core-service" => "management"),
> [Server:server-one] ("security-realm" => "ApplicationRealm")
> [Server:server-one] ]) - failure description: "WFLYDM0094: Kerberos is enabled for authentication on security realm 'ApplicationRealm' but no Keytab has been added to the server-identity."
> [Server:server-one] 15:10:35,376 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1418) Reloading host-controller via http-api puts the HC into unresponsive state
by Roy Willemse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1418?page=com.atlassian.jira.plugi... ]
Roy Willemse commented on WFCORE-1418:
--------------------------------------
I've seen similar behaviour when reloading Wildfly 10.0.0.Final when running inside a Docker container.
- Reload via JBoss-CLI works fine
- Problem could not be reproduced running locally (on OS X) or CentOS 7 running on VSphere
{code}
docker run -it java # I also tried centos:7 with OpenJDK 8
# Inside the container:
WILDFLY_VERSION=10.0.0.Final
curl http://download.jboss.org/wildfly/$WILDFLY_VERSION/wildfly-$WILDFLY_VERSI... | tar -C ~ -zx
cd ~/wildfly-$WILDFLY_VERSION
bin/add-user.sh admin admin --silent
bin/standalone.sh &
curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"reload","name":"","json.pretty":1}' -u admin:admin
{code}
After 5 minutes Wildfly logs an ERROR and starts normally:
{code}
19:21:50,837 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
19:21:50,847 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
19:21:50,857 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2
19:21:50,874 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTP listener default suspending
19:21:50,875 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 172.17.0.2:8080
19:21:50,877 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.3.15.Final stopping
# After 5 minutes:
19:26:50,529 ERROR [org.jboss.as.controller.management-operation] (management task-10) WFLYCTL0349: Timeout after [300] seconds waiting for service container stability while finalizing an operation. Process must be restarted. Step that first updated the service container was 'reload' at address '[]'
19:26:50,555 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default]
19:26:50,568 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) stopped in 300062ms
19:26:50,573 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) starting
{code}
> Reloading host-controller via http-api puts the HC into unresponsive state
> --------------------------------------------------------------------------
>
> Key: WFCORE-1418
> URL: https://issues.jboss.org/browse/WFCORE-1418
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Priority: Blocker
> Fix For: 2.1.0.Final
>
>
> Reloading host-controller via http-api puts the HC into unresponsive state.
> *reproduce*
> \- create an administrative user admin:asdasd@2
> \- start a domain
> \- reload a server via http api
> {noformat}
> curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"reload","name":"", "address":{"host" : "master"},"json.pretty":1}' -u admin:asdasd@2
> {noformat}
> *actual*
> Default server instances are stopped, HC is left in unresponsive state.
> Keeping the domain alive, following message will appear in 5 minutes, domain will become responsive again after that.
> {noformat}
> [Host Controller] 04:47:23,966 ERROR [org.jboss.as.controller.management-operation] (management task-7) WFLYCTL0349: Timeout after [300] seconds waiting for service container stability while finalizing an operation. Process must be restarted. Step that first updated the service container was 'reload' at address '[("host" => "master")]'
> {noformat}
> *expected*
> Domain is reloaded
> *additional info*
> The issue was introduced by fix for JBEAP-2751 - https://github.com/jbossas/wildfly-core-eap/commit/4986773a51fbf43ad911ae...
> thread dump of unresponsive HC
> http://pastebin.test.redhat.com/348732
> I am unable to reproduce locally, but issue can be easily reproduced on slower servers in MWQE lab. SSLMasterSlave*WayTestCase using reload via http-api cousing failures in domain modules of wf-core testsuite (e.g. [eap-7x-as-testsuite-test-core-rhel|https://url.corp.redhat.com/9f1f544] )
> Regression against 7.0.0.ER4. I was able to reproduce with the latest wildfly-core bits as well (1be598e)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1418) Reloading host-controller via http-api puts the HC into unresponsive state
by Roy Willemse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1418?page=com.atlassian.jira.plugi... ]
Roy Willemse edited comment on WFCORE-1418 at 4/20/16 5:13 PM:
---------------------------------------------------------------
I've seen similar behaviour when reloading Wildfly 10.0.0.Final when running inside a Docker container.
- Reload via JBoss-CLI works fine
- Problem could not be reproduced running locally (on OS X) or CentOS 7 running on VSphere
{code}
docker run -it java # I also tried centos:7 with OpenJDK 8
# Inside the container:
WILDFLY_VERSION=10.0.0.Final
curl http://download.jboss.org/wildfly/$WILDFLY_VERSION/wildfly-$WILDFLY_VERSI... | tar -C ~ -zx
cd ~/wildfly-$WILDFLY_VERSION
bin/add-user.sh admin admin --silent
bin/standalone.sh &
sleep 10
curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"reload","name":"","json.pretty":1}' -u admin:admin
{code}
After 5 minutes Wildfly logs an ERROR and starts normally:
{code}
19:21:50,837 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
19:21:50,847 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
19:21:50,857 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2
19:21:50,874 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTP listener default suspending
19:21:50,875 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 172.17.0.2:8080
19:21:50,877 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.3.15.Final stopping
# After 5 minutes:
19:26:50,529 ERROR [org.jboss.as.controller.management-operation] (management task-10) WFLYCTL0349: Timeout after [300] seconds waiting for service container stability while finalizing an operation. Process must be restarted. Step that first updated the service container was 'reload' at address '[]'
19:26:50,555 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default]
19:26:50,568 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) stopped in 300062ms
19:26:50,573 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) starting
{code}
was (Author: roy.willemse):
I've seen similar behaviour when reloading Wildfly 10.0.0.Final when running inside a Docker container.
- Reload via JBoss-CLI works fine
- Problem could not be reproduced running locally (on OS X) or CentOS 7 running on VSphere
{code}
docker run -it java # I also tried centos:7 with OpenJDK 8
# Inside the container:
WILDFLY_VERSION=10.0.0.Final
curl http://download.jboss.org/wildfly/$WILDFLY_VERSION/wildfly-$WILDFLY_VERSI... | tar -C ~ -zx
cd ~/wildfly-$WILDFLY_VERSION
bin/add-user.sh admin admin --silent
bin/standalone.sh &
curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"reload","name":"","json.pretty":1}' -u admin:admin
{code}
After 5 minutes Wildfly logs an ERROR and starts normally:
{code}
19:21:50,837 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
19:21:50,847 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0019: Host default-host stopping
19:21:50,857 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0019: Stopped Driver service with driver-name = h2
19:21:50,874 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0008: Undertow HTTP listener default suspending
19:21:50,875 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 172.17.0.2:8080
19:21:50,877 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0004: Undertow 1.3.15.Final stopping
# After 5 minutes:
19:26:50,529 ERROR [org.jboss.as.controller.management-operation] (management task-10) WFLYCTL0349: Timeout after [300] seconds waiting for service container stability while finalizing an operation. Process must be restarted. Step that first updated the service container was 'reload' at address '[]'
19:26:50,555 INFO [org.jboss.as.mail.extension] (MSC service thread 1-1) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default]
19:26:50,568 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) stopped in 300062ms
19:26:50,573 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) starting
{code}
> Reloading host-controller via http-api puts the HC into unresponsive state
> --------------------------------------------------------------------------
>
> Key: WFCORE-1418
> URL: https://issues.jboss.org/browse/WFCORE-1418
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Priority: Blocker
> Fix For: 2.1.0.Final
>
>
> Reloading host-controller via http-api puts the HC into unresponsive state.
> *reproduce*
> \- create an administrative user admin:asdasd@2
> \- start a domain
> \- reload a server via http api
> {noformat}
> curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"reload","name":"", "address":{"host" : "master"},"json.pretty":1}' -u admin:asdasd@2
> {noformat}
> *actual*
> Default server instances are stopped, HC is left in unresponsive state.
> Keeping the domain alive, following message will appear in 5 minutes, domain will become responsive again after that.
> {noformat}
> [Host Controller] 04:47:23,966 ERROR [org.jboss.as.controller.management-operation] (management task-7) WFLYCTL0349: Timeout after [300] seconds waiting for service container stability while finalizing an operation. Process must be restarted. Step that first updated the service container was 'reload' at address '[("host" => "master")]'
> {noformat}
> *expected*
> Domain is reloaded
> *additional info*
> The issue was introduced by fix for JBEAP-2751 - https://github.com/jbossas/wildfly-core-eap/commit/4986773a51fbf43ad911ae...
> thread dump of unresponsive HC
> http://pastebin.test.redhat.com/348732
> I am unable to reproduce locally, but issue can be easily reproduced on slower servers in MWQE lab. SSLMasterSlave*WayTestCase using reload via http-api cousing failures in domain modules of wf-core testsuite (e.g. [eap-7x-as-testsuite-test-core-rhel|https://url.corp.redhat.com/9f1f544] )
> Regression against 7.0.0.ER4. I was able to reproduce with the latest wildfly-core bits as well (1be598e)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1494) Investigate consequences of changes in JDK9 on JBoss Logging
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1494?page=com.atlassian.jira.plugi... ]
Richard Opalka moved WFLY-6359 to WFCORE-1494:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1494 (was: WFLY-6359)
Component/s: Logging
(was: Logging)
Affects Version/s: 2.1.0.Final
(was: 10.0.0.Final)
Fix Version/s: 3.0.0.Alpha1
(was: 10.1.0.Final)
> Investigate consequences of changes in JDK9 on JBoss Logging
> ------------------------------------------------------------
>
> Key: WFCORE-1494
> URL: https://issues.jboss.org/browse/WFCORE-1494
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Affects Versions: 2.1.0.Final
> Reporter: Richard Opalka
> Assignee: James Perkins
> Fix For: 3.0.0.Alpha1
>
>
> When running:
> $[wildfly-core/logging]>mvn test -Dtest=**/Log4jAppenderTestCase
> on JDK9 the test is failing.
> {noformat}
> levelTest(org.jboss.as.logging.logmanager.Log4jAppenderTestCase) Time elapsed: 0.006 sec <<< ERROR!
> java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
> at org.jboss.as.logging.logmanager.Log4jAppenderTestCase.<init>(Log4jAppenderTestCase.java:49)
> formatTest(org.jboss.as.logging.logmanager.Log4jAppenderTestCase) Time elapsed: 0.001 sec <<< ERROR!
> java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
> at org.jboss.as.logging.logmanager.Log4jAppenderTestCase.<init>(Log4jAppenderTestCase.java:49)
> {noformat}
> After short debugging I identified the difference between JDK8 and JKD9 that is causing the test to fail. In JDK8 the relevant piece of code was:
> {code}
> // java.util.logging.Logger
> private static Logger demandLogger(String name, String resourceBundleName, Class<?> caller) {
> LogManager manager = LogManager.getLogManager();
> SecurityManager sm = System.getSecurityManager();
> if (sm != null && !SystemLoggerHelper.disableCallerCheck) {
> if (caller.getClassLoader() == null) {
> return manager.demandSystemLogger(name, resourceBundleName);
> }
> }
> return manager.demandLogger(name, resourceBundleName, caller);
> // ends up calling new Logger(name, resourceBundleName, caller)
> // iff the logger doesn't exist already
> }
> {code}
> in JDK9 the Security Manager check part disappeared:
> {code}
> // java.util.logging.Logger
> private static Logger demandLogger(String name, String resourceBundleName, Class<?> caller) {
> LogManager manager = LogManager.getLogManager();
> if (!SystemLoggerHelper.disableCallerCheck) {
> if (caller.getClassLoader() == null) {
> return manager.demandSystemLogger(name, resourceBundleName, caller);
> }
> }
> return manager.demandLogger(name, resourceBundleName, caller);
> // ends up calling new Logger(name, resourceBundleName, caller)
> // iff the logger doesn't exist already
> }
> {code}
> This change causes the platform java.util.logging.Logger is returned instead of expected one
> org.jboss.logmanager.Logger.
> It is possible to workaround this problem by setting sun.util.logging.disableCallerCheck JVM property, like:
> $[wildfly-core/logging]>mvn test -Dtest=**/Log4jAppenderTestCase -Dsun.util.logging.disableCallerCheck=true
> Please investigate, whether this is regression that should be addressed by Oracle and if there are not other potential problems affecting proper logging functionality on JDK9.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1493) org.jboss.as.host.controller.Main.getHostSystemProperties() doesn't propagate -Djdk.launcher.addexports.%d=%s value properly
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1493?page=com.atlassian.jira.plugi... ]
Richard Opalka updated WFCORE-1493:
-----------------------------------
Description:
JDK9 provides -XaddExports launch option to workaround potential migration problems to modularized JDK.
{color:red}When modularized JDK forks new process all -XaddExports values are translated into
-Djdk.launcher.addexports.%d=%s JVM options.{color}
But method org.jboss.as.host.controller.Main.getHostSystemProperties()
has problems with its values.
The format of -XaddExports (and thus for -Djdk.launcher.addexports.%d=%s too) is:
{noformat}
-XaddExports:<source-module>/<package>=<target-module>(,<target-module>)*{noformat}
See http://openjdk.java.net/jeps/261 for more information.
was:
JDK9 provides -XaddExports launch option to workaround potential migration problems to modularized JDK.
*When modularized JDK forks new process all -XaddExports values are translated into
-Djdk.launcher.addexports.%d=%s JVM options.*
But method org.jboss.as.host.controller.Main.getHostSystemProperties()
has problems with its values.
The format of -XaddExports (and thus for -Djdk.launcher.addexports.%d=%s too):
{noformat}
-XaddExports:<source-module>/<package>=<target-module>(,<target-module>)*{noformat}
See http://openjdk.java.net/jeps/261 for more information.
> org.jboss.as.host.controller.Main.getHostSystemProperties() doesn't propagate -Djdk.launcher.addexports.%d=%s value properly
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1493
> URL: https://issues.jboss.org/browse/WFCORE-1493
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Fix For: 3.0.0.Alpha1
>
>
> JDK9 provides -XaddExports launch option to workaround potential migration problems to modularized JDK.
> {color:red}When modularized JDK forks new process all -XaddExports values are translated into
> -Djdk.launcher.addexports.%d=%s JVM options.{color}
> But method org.jboss.as.host.controller.Main.getHostSystemProperties()
> has problems with its values.
> The format of -XaddExports (and thus for -Djdk.launcher.addexports.%d=%s too) is:
> {noformat}
> -XaddExports:<source-module>/<package>=<target-module>(,<target-module>)*{noformat}
> See http://openjdk.java.net/jeps/261 for more information.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years