[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender
by Bela Ban (JIRA)
Optimization: make threads return immediately if NAKACK has another active thread for the same sender
-----------------------------------------------------------------------------------------------------
Key: JGRP-457
URL: http://jira.jboss.com/jira/browse/JGRP-457
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Minor
Fix For: 2.5
In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up.
If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock.
The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5 days, 5 hours
[JBoss JIRA] (WFLY-8004) Elytron subsystem attributes with a default value should not be configured as required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8004?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-8004:
-----------------------------------
Summary: Elytron subsystem attributes with a default value should not be configured as required (was: should not be configured as required)
> Elytron subsystem attributes with a default value should not be configured as required
> --------------------------------------------------------------------------------------
>
> Key: WFLY-8004
> URL: https://issues.jboss.org/browse/WFLY-8004
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> A number of elytron subsystem attributes are configured as being required even though they have a default value (which implies not requiring a user-provided setting).
> Once WFCORE-2249 is fixed which results in proper validation of complex object attributes, this bug results in the server failing to boot:
> {code}
> 2017-01-31 12:28:04,055 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 13) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mechanism-provider-filtering-sasl-server-factory" => "elytron")
> ]) - failure description: "WFLYCTL0155: 'version-comparison' may not be null"
> {code}
> Simple fix, just change the definition.
> I found 13 attributes like this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-2252) AttributeDefinition should reject configs with a default value that are also set as required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2252:
-------------------------------------
Component/s: (was: Test Suite)
Description:
If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
AttributeDefinition should reject this combination in its constructor.
I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
was:
If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
The subsystem tests should validate this (core model tests too.)
I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
Summary: AttributeDefinition should reject configs with a default value that are also set as required (was: Subsystem tests should check for attributes with a default value that are configured as required)
> AttributeDefinition should reject configs with a default value that are also set as required
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-2252
> URL: https://issues.jboss.org/browse/WFCORE-2252
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
>
> If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
> AttributeDefinition should reject this combination in its constructor.
> I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-2252) Subsystem tests should check for attributes with a default value that are configured as required
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2252:
----------------------------------------
Summary: Subsystem tests should check for attributes with a default value that are configured as required
Key: WFCORE-2252
URL: https://issues.jboss.org/browse/WFCORE-2252
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management, Test Suite
Reporter: Brian Stansberry
If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
The subsystem tests should validate this (core model tests too.)
I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8004) should not be configured as required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8004?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-8004:
-----------------------------------
Description:
A number of elytron subsystem attributes are configured as being required even though they have a default value (which implies not requiring a user-provided setting).
Once WFCORE-2249 is fixed which results in proper validation of complex object attributes, this bug results in the server failing to boot:
{code}
2017-01-31 12:28:04,055 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 13) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("mechanism-provider-filtering-sasl-server-factory" => "elytron")
]) - failure description: "WFLYCTL0155: 'version-comparison' may not be null"
{code}
Simple fix, just change the definition.
I found 13 attributes like this.
was:
This attribute is configured as being required even though it has a default value (which implies not requiring a user-provided setting).
Once WFCORE-2249 is fixed which results in proper validation of complex object attributes, this bug results in the server failing to boot:
{code}
2017-01-31 12:28:04,055 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 13) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("mechanism-provider-filtering-sasl-server-factory" => "elytron")
]) - failure description: "WFLYCTL0155: 'version-comparison' may not be null"
{code}
Simple fix.
There may be others like this that are revealed by WFCORE-2249. If so I'll include them in this work, if they are part of the elytron subsystem.
Summary: should not be configured as required (was: SaslServerDefinitions VERSION_COMPARISON should not be configured as required)
> should not be configured as required
> -------------------------------------
>
> Key: WFLY-8004
> URL: https://issues.jboss.org/browse/WFLY-8004
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> A number of elytron subsystem attributes are configured as being required even though they have a default value (which implies not requiring a user-provided setting).
> Once WFCORE-2249 is fixed which results in proper validation of complex object attributes, this bug results in the server failing to boot:
> {code}
> 2017-01-31 12:28:04,055 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 13) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mechanism-provider-filtering-sasl-server-factory" => "elytron")
> ]) - failure description: "WFLYCTL0155: 'version-comparison' may not be null"
> {code}
> Simple fix, just change the definition.
> I found 13 attributes like this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8004) SaslServerDefinitions VERSION_COMPARISON should not be configured as required
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8004:
--------------------------------------
Summary: SaslServerDefinitions VERSION_COMPARISON should not be configured as required
Key: WFLY-8004
URL: https://issues.jboss.org/browse/WFLY-8004
Project: WildFly
Issue Type: Bug
Components: Domain Management, Security
Reporter: Brian Stansberry
Assignee: Brian Stansberry
This attribute is configured as being required even though it has a default value (which implies not requiring a user-provided setting).
Once WFCORE-2249 is fixed which results in proper validation of complex object attributes, this bug results in the server failing to boot:
{code}
2017-01-31 12:28:04,055 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 13) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("mechanism-provider-filtering-sasl-server-factory" => "elytron")
]) - failure description: "WFLYCTL0155: 'version-comparison' may not be null"
{code}
Simple fix.
There may be others like this that are revealed by WFCORE-2249. If so I'll include them in this work, if they are part of the elytron subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-7687) Authentication based on certificates does not work in Elytron with Undertow
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7687?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7687:
----------------------------------------
Actually I believe it depends on if you look at the spec or the API as to if it is '-' or '_'.
> Authentication based on certificates does not work in Elytron with Undertow
> ---------------------------------------------------------------------------
>
> Key: WFLY-7687
> URL: https://issues.jboss.org/browse/WFLY-7687
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Tymel
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
> Attachments: deployment.war, keystores.zip, standalone-elytron.xml
>
>
> It is not possible to set up authentication based on certificates. I followed the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything worked as expected until I tried to deploy an app. I got this output
> {code}
> 14:50:29,352 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./deployment: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:348)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:293)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:404)
> at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:207)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:235)
> ... 8 more
> 14:50:29,356 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "deployment.war")]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./deployment" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory."},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./deployment"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> {code}
> This might be caused by different representation of {{CLIENT-CERT}} attribute within Elytron and Undertow. It appears that Elytron uses {{CLIENT-CERT}} [3] whereas Undertow uses {{CLIENT_CERT}} [4]
> [1] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#Us...
> [2] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#Us...
> [3] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> [4] https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months