[JBoss JIRA] (WFLY-5608) Unable to configure https using CLI with attribute enabled-cipher-suites
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5608?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-5608:
------------------------------------
Assignee: Stuart Douglas (was: Darran Lofthouse)
> Unable to configure https using CLI with attribute enabled-cipher-suites
> ------------------------------------------------------------------------
>
> Key: WFLY-5608
> URL: https://issues.jboss.org/browse/WFLY-5608
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Martin Choma
> Assignee: Stuart Douglas
>
> User is unable to configure https using enabled-cipher-suites attribute
> {code}
> [standalone@localhost:9990 /] /core-service=management/security-realm=FIPSRealm:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /core-service=management/security-realm=FIPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="NSS FIPS 140-2 Certificate DB")
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=FIPSRealm, enabled-cipher-suites="DHE", enabled-protocols="TLSv1")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Caused by: java.lang.NullPointerException"}},
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> {code}
> 14:52:20,753 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:120)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 14:52:20,753 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("https-listener" => "https")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Caused by: java.lang.NullPointerException"}}
> {code}
> This works OK. It means reload is used between commands
> {code}
> /core-service=management/security-realm=FIPSRealm:add
> /core-service=management/security-realm=FIPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="NSS FIPS 140-2 Certificate DB")
> reload
> /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=FIPSRealm, enabled-cipher-suites="DHE", enabled-protocols="TLSv1")
> {code}
> Also same commands without enabled-cipher-suites works OK
> {code}
> /core-service=management/security-realm=FIPSRealm:add
> /core-service=management/security-realm=FIPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="NSS FIPS 140-2 Certificate DB")
> /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=FIPSRealm, enabled-protocols="TLSv1")
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFCORE-1092) ConfigurationChangeResourceRemoveHandler makes its changes in the constructor not in execute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1092?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1092:
-------------------------------------
Description:
ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter.
A reload won't cause it to get called again either, as ConfigurationChangeResourceDefinition is only constructed when the
was:
ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter.
> ConfigurationChangeResourceRemoveHandler makes its changes in the constructor not in execute
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-1092
> URL: https://issues.jboss.org/browse/WFCORE-1092
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.Final
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha1
>
>
> ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter.
> A reload won't cause it to get called again either, as ConfigurationChangeResourceDefinition is only constructed when the
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFCORE-1092) ConfigurationChangeResourceRemoveHandler makes its changes in the constructor not in execute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1092?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1092:
-------------------------------------
Description:
ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter.
A reload won't cause it to get called again either, as ConfigurationChangeResourceDefinition is only constructed when the static INSTANCE member is initialized.
was:
ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter.
A reload won't cause it to get called again either, as ConfigurationChangeResourceDefinition is only constructed when the
> ConfigurationChangeResourceRemoveHandler makes its changes in the constructor not in execute
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-1092
> URL: https://issues.jboss.org/browse/WFCORE-1092
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.Final
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha1
>
>
> ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter.
> A reload won't cause it to get called again either, as ConfigurationChangeResourceDefinition is only constructed when the static INSTANCE member is initialized.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1093?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1093:
-------------------------------------------------
Aaron Ogburn <aogburn(a)redhat.com> changed the Status of [bug 1277699|https://bugzilla.redhat.com/show_bug.cgi?id=1277699] from ASSIGNED to POST
> TempFileProviderService threads consume high CPU
> ------------------------------------------------
>
> Key: WFCORE-1093
> URL: https://issues.jboss.org/browse/WFCORE-1093
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Aaron Ogburn
> Assignee: Jason Greene
>
> TempFileProviderService threads consume high CPU as they poll their non empty task queue. This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.
> While the executor queue is not empty, the executor does not allow the pool to go below 1 thread. So the one remaining work thread keeps looping over its poll call with a 0 timeout. Options to protect JBoss from this are:
> 1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
> 2) Or set the Executor core pool size to >0. The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls. The side effect of this change is that the thread pool wouldn't ever drop back down to 0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1093?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated WFCORE-1093:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1277699
Bugzilla Update: Perform
> TempFileProviderService threads consume high CPU
> ------------------------------------------------
>
> Key: WFCORE-1093
> URL: https://issues.jboss.org/browse/WFCORE-1093
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Aaron Ogburn
> Assignee: Jason Greene
>
> TempFileProviderService threads consume high CPU as they poll their non empty task queue. This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.
> While the executor queue is not empty, the executor does not allow the pool to go below 1 thread. So the one remaining work thread keeps looping over its poll call with a 0 timeout. Options to protect JBoss from this are:
> 1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
> 2) Or set the Executor core pool size to >0. The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls. The side effect of this change is that the thread pool wouldn't ever drop back down to 0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU
by Aaron Ogburn (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1093?page=com.atlassian.jira.plugi... ]
Aaron Ogburn updated WFCORE-1093:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1215
> TempFileProviderService threads consume high CPU
> ------------------------------------------------
>
> Key: WFCORE-1093
> URL: https://issues.jboss.org/browse/WFCORE-1093
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Aaron Ogburn
> Assignee: Jason Greene
>
> TempFileProviderService threads consume high CPU as they poll their non empty task queue. This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.
> While the executor queue is not empty, the executor does not allow the pool to go below 1 thread. So the one remaining work thread keeps looping over its poll call with a 0 timeout. Options to protect JBoss from this are:
> 1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
> 2) Or set the Executor core pool size to >0. The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls. The side effect of this change is that the thread pool wouldn't ever drop back down to 0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU
by Aaron Ogburn (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1093?page=com.atlassian.jira.plugi... ]
Aaron Ogburn commented on WFCORE-1093:
--------------------------------------
PR using a keepalive time to avoid the issue:
https://github.com/wildfly/wildfly-core/pull/1215
> TempFileProviderService threads consume high CPU
> ------------------------------------------------
>
> Key: WFCORE-1093
> URL: https://issues.jboss.org/browse/WFCORE-1093
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Aaron Ogburn
> Assignee: Jason Greene
>
> TempFileProviderService threads consume high CPU as they poll their non empty task queue. This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.
> While the executor queue is not empty, the executor does not allow the pool to go below 1 thread. So the one remaining work thread keeps looping over its poll call with a 0 timeout. Options to protect JBoss from this are:
> 1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
> 2) Or set the Executor core pool size to >0. The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls. The side effect of this change is that the thread pool wouldn't ever drop back down to 0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU
by Aaron Ogburn (JIRA)
Aaron Ogburn created WFCORE-1093:
------------------------------------
Summary: TempFileProviderService threads consume high CPU
Key: WFCORE-1093
URL: https://issues.jboss.org/browse/WFCORE-1093
Project: WildFly Core
Issue Type: Bug
Components: Server
Reporter: Aaron Ogburn
Assignee: Jason Greene
TempFileProviderService threads consume high CPU as they poll their non empty task queue. This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.
While the executor queue is not empty, the executor does not allow the pool to go below 1 thread. So the one remaining work thread keeps looping over its poll call with a 0 timeout. Options to protect JBoss from this are:
1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
2) Or set the Executor core pool size to >0. The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls. The side effect of this change is that the thread pool wouldn't ever drop back down to 0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (WFCORE-1092) ConfigurationChangeResourceRemoveHandler makes its changes in the constructor not in execute
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1092:
----------------------------------------
Summary: ConfigurationChangeResourceRemoveHandler makes its changes in the constructor not in execute
Key: WFCORE-1092
URL: https://issues.jboss.org/browse/WFCORE-1092
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.0.Final
Reporter: Brian Stansberry
Assignee: ehsavoie Hugonnet
Fix For: 3.0.0.Alpha1
ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (JBEE-159) PropertyNotFoundException when the property is a JDK8 defender method
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/JBEE-159?page=com.atlassian.jira.plugin.s... ]
Rich DiCroce commented on JBEE-159:
-----------------------------------
Still a problem on WildFly 10.0.0.CR2 (EL API 1.0.5.Final)
> PropertyNotFoundException when the property is a JDK8 defender method
> ---------------------------------------------------------------------
>
> Key: JBEE-159
> URL: https://issues.jboss.org/browse/JBEE-159
> Project: JBoss JavaEE Spec APIs
> Issue Type: Enhancement
> Components: jboss-el-api
> Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final
> Reporter: Rich DiCroce
> Assignee: Scott Marlow
> Priority: Minor
> Labels: java8
>
> I have a class that implements an interface that uses Java 8's new defender methods feature. Some getters on the interface have default implementations, and the concrete classes don't override them.
> If I try to refer to one of these getters as a property like so:
> {code:xml}
> value="#{cc.filter.filter.valueChoices}"
> {code}
> Then I get this exception:
> {noformat}
> Caused by: javax.el.PropertyNotFoundException: The class 'com.lapis.jsf.framework.dao.search.DefaultEntityFilter' does not have the property 'valueChoices'.
> at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:731) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> at javax.el.BeanELResolver.getValue(BeanELResolver.java:351) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final]
> at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:140) [javax.el-3.0.0.jar:]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:204) [javax.el-3.0.0.jar:]
> at com.sun.el.parser.AstEmpty.getValue(AstEmpty.java:66) [javax.el-3.0.0.jar:]
> at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-3.0.0.jar:]
> at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at com.sun.faces.facelets.el.ContextualCompositeValueExpression.getValue(ContextualCompositeValueExpression.java:158) [jsf-impl-2.2.6-jbossorg-4.jar:]
> at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.2.6-jbossorg-4.jar:]
> ... 68 more
> {noformat}
> Two workarounds exist. One: you can override the default method in a concrete class and have it just call the default super method. Two: you can call the getter using a method expression instead of a value expression.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months