[JBoss JIRA] (ELY-1130) Elytron Client configuration file requires alias for keystore
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1130?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse reassigned ELY-1130:
-------------------------------------
Assignee: Chao Wang (was: Darran Lofthouse)
> Elytron Client configuration file requires alias for keystore
> -------------------------------------------------------------
>
> Key: ELY-1130
> URL: https://issues.jboss.org/browse/ELY-1130
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Affects Versions: 1.1.0.Beta38
> Reporter: Ondrej Lukas
> Assignee: Chao Wang
>
> In Elytron Client configuration file all elements related to keystore (key-store-ssl-certificate, key-store-reference and key-store-credential) require element alias. It is difference from Elytron subsystem where alias is not required.
> Usage of alias should be consistent between subsystem and Elytron Client configuration file. Elytron is able to found out certificate without passed alias if keystore includes just one entry.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1151) Empty authorization name for Digest mechanism causes authentication fail
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-1151?page=com.atlassian.jira.plugin.s... ]
Ondrej Lukas updated ELY-1151:
------------------------------
Affects Version/s: 1.1.0.Beta38
> Empty authorization name for Digest mechanism causes authentication fail
> ------------------------------------------------------------------------
>
> Key: ELY-1151
> URL: https://issues.jboss.org/browse/ELY-1151
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta38
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> SASL specification says about Authorization Identity String [1]:
> {quote}
> If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. *An empty string is equivalent to an absent authorization identity.*
> {quote}
> In case when authentication configuration includes empty name for authorization name then authentication fail. In correct behavior authentication name should be used if authorization name is empty string.
> It is caused by passing empty {{defaultName}} to {{NameCallback}} constructor which results to {{IllegalArgumentException}}. Condition in [2] checks only non-null value of {{authorizationId}} but it seems it should also check empty name.
> It can be reproduced with correctly set wildfly-config.xml (i.e. configuration where authentication succeed) - in case {{set-authorization-name}} element with empty string is added to this configuration file then authentication starts to fail.
> The same issue can occurs for every supported SASL mechanism. In needs to be revisited.
> We request blocker flag since current behavior violates SASL specification.
> [1] https://tools.ietf.org/html/rfc4422#section-3.4.1
> [2] https://github.com/wildfly-security/wildfly-elytron/blob/596f25e853c8fbae...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1151) Empty authorization name for Digest mechanism causes authentication fail
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-1151:
---------------------------------
Summary: Empty authorization name for Digest mechanism causes authentication fail
Key: ELY-1151
URL: https://issues.jboss.org/browse/ELY-1151
Project: WildFly Elytron
Issue Type: Bug
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Blocker
SASL specification says about Authorization Identity String [1]:
{quote}
If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. *An empty string is equivalent to an absent authorization identity.*
{quote}
In case when authentication configuration includes empty name for authorization name then authentication fail. In correct behavior authentication name should be used if authorization name is empty string.
It is caused by passing empty {{defaultName}} to {{NameCallback}} constructor which results to {{IllegalArgumentException}}. Condition in [2] checks only non-null value of {{authorizationId}} but it seems it should also check empty name.
It can be reproduced with correctly set wildfly-config.xml (i.e. configuration where authentication succeed) - in case {{set-authorization-name}} element with empty string is added to this configuration file then authentication starts to fail.
The same issue can occurs for every supported SASL mechanism. In needs to be revisited.
We request blocker flag since current behavior violates SASL specification.
[1] https://tools.ietf.org/html/rfc4422#section-3.4.1
[2] https://github.com/wildfly-security/wildfly-elytron/blob/596f25e853c8fbae...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8757) Intermittent fail - MDB20TopicTestCase testEjb20TopicMDBs
by Miroslav Novak (JIRA)
Miroslav Novak created WFLY-8757:
------------------------------------
Summary: Intermittent fail - MDB20TopicTestCase testEjb20TopicMDBs
Key: WFLY-8757
URL: https://issues.jboss.org/browse/WFLY-8757
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 11.0.0.Alpha1
Reporter: Miroslav Novak
Assignee: Miroslav Novak
There are intermittent failures of MDB20TopicTestCase#testEjb20TopicMDBs. It's very very rare and I cannot not reproduce it locally. Only in Jenkins CI environment.
Test randomly fails on:
{code}
public void testEjb20TopicMDBs() {
sendTextMessage("Say hello to the topic", topic);
final Message replyA = receiveMessage(replyQueueA, TimeoutUtil.adjust(5000));
Assert.assertNotNull("Reply message was null on reply queue: " + replyQueueA, replyA);
final Message replyB = receiveMessage(replyQueueB, TimeoutUtil.adjust(5000));
Assert.assertNotNull("Reply message was null on reply queue: " + replyQueueB, replyB); <--- here is the failure
}
{code}
Test is failling on:
{code}
&#27;[0m&#27;[31m15:12:58,493 SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.testEjb20TopicMDBs: java.lang.AssertionError: Reply message was null on reply queue: ActiveMQQueue[ejb2x/replyQueueB]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:712)
at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.testEjb20TopicMDBs(MDB20TopicTestCase.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1027) CS tool, Parameter --salt requires --iteration and vice versa
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/ELY-1027?page=com.atlassian.jira.plugin.s... ]
Yeray Borges reassigned ELY-1027:
---------------------------------
Assignee: Yeray Borges
> CS tool, Parameter --salt requires --iteration and vice versa
> -------------------------------------------------------------
>
> Key: ELY-1027
> URL: https://issues.jboss.org/browse/ELY-1027
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Yeray Borges
>
> If I use only one parameter from --salt or --iteration then this one is ignored and result password is in clear text.
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --location="test.store" --uri "cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary --salt="abcdefgh"
> {code}
> Result of this command is:
> {code}
> Alias "myalias" has been successfully stored
> Credential store command summary:
> --------------------------------------
> /subsystem=elytron/credential-store=test:add(uri="cr-store://test?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"})
> {code}
> *There is expected error.*
> Please add there this constraint: parameter --salt requires --iteration and vice versa
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1145) WildFly Elytron Tool, Vault command bulk-convert must contain in --help output which options are required.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1145?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek updated ELY-1145:
------------------------------
Description:
Vault command bulk-convert must contain in --help output which options are required.
All options are required with two exceptions:
"properties" option and
when user uses plain-text password then he can omit SALT and ITERATION option.
was:
Vault command bulk-convert must contain in --help output which options are required.
All options are required with one exception:
When user uses plain-text password then he can omit SALT and ITERATION option.
> WildFly Elytron Tool, Vault command bulk-convert must contain in --help output which options are required.
> ----------------------------------------------------------------------------------------------------------
>
> Key: ELY-1145
> URL: https://issues.jboss.org/browse/ELY-1145
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
> Priority: Critical
>
> Vault command bulk-convert must contain in --help output which options are required.
> All options are required with two exceptions:
> "properties" option and
> when user uses plain-text password then he can omit SALT and ITERATION option.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ]
Ondrej Lukas commented on WFCORE-2746:
--------------------------------------
[~jamezp] [~luck3y] I totally agree, I am also not a big fan of running test in some pre-defined order since common tests should be independent on each other. However point of usage InSequence is decreasing a time needed for running particular test case if server reloads are needed there.
See the example:
Configure 4 different Elytron ssl-contexts. We want to run 4 tests for every of that ssl-context used in http-interface. We setup server configuration in @BeforeClass, then there are two ways how to simply run the tests:
* Definitely, clear solution is setup needed ssl-context in http-interface (through write-attribute) for particular test case which means that test are independent. However, every this change needs to reload server, which means 16 server reload.
* In case we use InSequence, then we can setup ssl-context A and run all tests for it, then setup ssl-context B and run all tests for it and so on. It means 4 server reloads are needed.
It is just an example, but I think it describes use case for current usage of InSequence annotation. Is there any different way how to deal with mentioned above scenario in general?
> Move elytron management security tests from full to core
> --------------------------------------------------------
>
> Key: WFCORE-2746
> URL: https://issues.jboss.org/browse/WFCORE-2746
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security, Test Suite
> Reporter: Brian Stansberry
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> -org.jboss.as.test.integration.security.perimeter.* [2]-
> -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> org.jboss.as.test.integration.security.credentialreference [2]
> integration/elytron/
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8756) http-remoting-connector attributes wrongly declared as "restart-required" => "no-services"
by Martin Choma (JIRA)
Martin Choma created WFLY-8756:
----------------------------------
Summary: http-remoting-connector attributes wrongly declared as "restart-required" => "no-services"
Key: WFLY-8756
URL: https://issues.jboss.org/browse/WFLY-8756
Project: WildFly
Issue Type: Bug
Components: Remoting
Reporter: Martin Choma
Assignee: David Lloyd
Changing http-remoting-connector leads to reload required state. But all attributes are marked as {{"restart-required" => "no-services"}} in model. Based on documentation [1] I think they should be rather {{"restart-required" => "resource-services"}}
{code}
[standalone@localhost:9990 /] /subsystem=remoting/http-connector=http-remoting-connector:read-resource-description
{
"outcome" => "success",
"result" => {
"description" => "The configuration of a HTTP Upgrade based Remoting connector.",
"capabilities" => [{
"name" => "org.wildfly.remoting.http-connector",
"dynamic" => true
}],
"attributes" => {
"authentication-provider" => {
"type" => STRING,
"description" => "The \"authentication-provider\" element contains the name of the authentication provider to use for incoming connections.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-constraints" => {"sensitive" => {"remoting-security" => {"type" => "remoting"}}},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"connector-ref" => {
"type" => STRING,
"description" => "The name (or names) of a connector in the Undertow subsystem to connect to.",
"expressions-allowed" => false,
"required" => true,
"nillable" => false,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"sasl-authentication-factory" => {
"type" => STRING,
"description" => "Reference to the SASL authentication factory to use for this connector.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"nil-significant" => true,
"capability-reference" => "org.wildfly.security.sasl-authentication-factory",
"min-length" => 1L,
"max-length" => 2147483647L,
"access-constraints" => {"sensitive" => {"authentication-factory-ref" => {"type" => "core"}}},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"sasl-protocol" => {
"type" => STRING,
"description" => "The protocol to pass into the SASL mechanisms used for authentication.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"default" => "remote",
"min-length" => 1L,
"max-length" => 2147483647L,
"access-constraints" => {"sensitive" => {"remoting-security" => {"type" => "remoting"}}},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"security-realm" => {
"type" => STRING,
"description" => "The associated security realm to use for authentication for this connector.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-constraints" => {"sensitive" => {
"security-realm-ref" => {"type" => "core"},
"remoting-security" => {"type" => "remoting"}
}},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"server-name" => {
"type" => STRING,
"description" => "The server name to send in the initial message exchange and for SASL based authentication.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-constraints" => {"sensitive" => {"remoting-security" => {"type" => "remoting"}}},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
}
},
"operations" => undefined,
"notifications" => undefined,
"children" => {
"security" => {
"description" => "Configuration of security for this connector.",
"model-description" => undefined
},
"property" => {
"description" => "Properties to further configure the connector.",
"model-description" => undefined
}
}
},
"response-headers" => {"process-state" => "reload-required"}
}
{code}
[1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2786) Improve the composition operation output
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2786?page=com.atlassian.jira.plugi... ]
Filippe Spolti edited comment on WFCORE-2786 at 5/11/17 5:01 PM:
-----------------------------------------------------------------
Edited as Brian's suggestions on the PR.
was (Author: filippe.spolti):
I did a little modification and got this result:
{code:title=Request}
{
"address": [],
"json.pretty": 1,
"operation": "composite",
"rename-steps": "true",
"steps": [
{
"name": "server-state",
"operation": "read-attribute"
},
{
"address": {
"deployment": "*"
},
"name": "deployment-status",
"operation": "read-attribute"
},
{
"address": {
"core-service": "management"
},
"name": "read-boot-errors",
"operation": "read-boot-errors"
}
]
}
{code}
{code:title=response}
{
"outcome": "success",
"result": {
"deployment-status": {
"outcome": "success",
"result": []
},
"read-boot-errors": {
"outcome": "success",
"result": []
},
"server-state": {
"outcome": "success",
"result": "running"
}
}
}
{code}
In this case the user can add a parameter in the request "rename-steps" to true, if false or its absence the step-N will be used.
Also, user must define the operation name, like:
{code}
{
"address": {
"deployment": "*"
},
"name": "deployment-info",
"operation": "read-attribute"
}
{code}
If no name is set, step-N will be used.
> Improve the composition operation output
> ----------------------------------------
>
> Key: WFCORE-2786
> URL: https://issues.jboss.org/browse/WFCORE-2786
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Filippe Spolti
>
> When you perform a composite operations with many commands the output will be enumerated in steps, like: step-1, step-2, ..., step-N.
> I am not sure, but looks like the step-X correspond to the order of the commands sent in the request payload, example:
> {code:title=Payload}
> {
> "address": [],
> "json.pretty": 1,
> "operation": "composite",
> "steps": [
> {
> "name": "server-state",
> "operation": "read-attribute"
> },
> {
> "address": {
> "deployment": "*"
> },
> "name": "status",
> "operation": "read-attribute"
> }
> ]
> }
> {code}
> {code:title=Response}
> {
> "outcome": "success",
> "result": {
> "step-1": {
> "outcome": "success",
> "result": "running"
> },
> "step-2": {
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
> If you have something the dynamically builds the composite payload, it is very hard to identify the output corresponding to each command in the payload.
> It will be great if we can add a extra field in the response or change the steps name to its operation name, for example:
> {code}
> {
> "outcome": "success",
> "result": {
> "step-1": {
> "operation-name": "server-state",
> "outcome": "success",
> "result": "running"
> },
> "step-2": {
> "operation-name": "deployment-info",
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
> Or
> {code}
> {
> "outcome": "success",
> "result": {
> "server-state": {
> "outcome": "success",
> "result": "running"
> },
> "deployment-info": {
> "outcome": "success",
> "result": []
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8753) OpenSSL via Wildfly-OpenSSL crashes JVM when mod_cluster used
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-8753?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek updated WFLY-8753:
--------------------------------------
Summary: OpenSSL via Wildfly-OpenSSL crashes JVM when mod_cluster used (was: OpenSSL via Wildfly-OpenSSL crashes VM on application server shutdown when mod_cluster used)
> OpenSSL via Wildfly-OpenSSL crashes JVM when mod_cluster used
> -------------------------------------------------------------
>
> Key: WFLY-8753
> URL: https://issues.jboss.org/browse/WFLY-8753
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Beta1
> Environment: RHEL 7 x86_64
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: wildfly-openssl
> Attachments: crashes_on_mod_cluster_connection.server.log, hs_err_pid12281.log, new_hs_err_pid13002.log, server.log, standalone-ha.xml
>
>
> h3. Previously I thought it happens just on server shutdown...
> {quote}
> Worker node with this mod_cluster and Elytron configuration [^standalone-ha.xml] keeps complaining on being unable to agree on a cipher suite with the Undertow balancer, whose Elytron configuration is identical, i.e. {code}
> <server-ssl-contexts>
> <server-ssl-context name="serverSSLContext" providers="openssl" need-client-auth="false" key-managers="keyManager" protocols="TLSv1.2" trust-managers="trustManager"/>
> </server-ssl-contexts>
> <client-ssl-contexts>
> <client-ssl-context name="clientSSLContext" providers="openssl" key-managers="clientKeyManager" protocols="TLSv1.2" trust-managers="trustManager"/>
> </client-ssl-contexts>{code}
> see:{code}
> 15:19:25,492 FINE [org.wildfly.openssl.OpenSSLEngine] (UndertowEventHandlerAdapter - 1) The version of SSL in use does not support cipher ordering
> 15:19:25,541 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) null: java.lang.NullPointerException
> at org.wildfly.openssl.CipherSuiteConverter.toJava(CipherSuiteConverter.java:284)
> at org.wildfly.openssl.OpenSSLEngine.toJavaCipherSuite(OpenSSLEngine.java:1021)
> at org.wildfly.openssl.OpenSSlSession.initCipherSuite(OpenSSlSession.java:305)
> at org.wildfly.openssl.OpenSSlSession.initialised(OpenSSlSession.java:296)
> at org.wildfly.openssl.OpenSSLSessionContext.clientSessionCreated(OpenSSLSessionContext.java:114)
> at org.wildfly.openssl.OpenSSLClientSessionContext.storeClientSideSession(OpenSSLClientSessionContext.java:92)
> at org.wildfly.openssl.OpenSSLEngine.handshakeFinished(OpenSSLEngine.java:940)
> at org.wildfly.openssl.OpenSSLEngine.getHandshakeStatus(OpenSSLEngine.java:989)
> at org.wildfly.openssl.OpenSSLEngine.unwrap(OpenSSLEngine.java:606)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
> at org.wildfly.openssl.OpenSSLSocket.runHandshake(OpenSSLSocket.java:316)
> at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:462)
> at org.wildfly.openssl.OpenSSLOutputStream.write(OpenSSLOutputStream.java:46)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.BufferedWriter.flush(BufferedWriter.java:254)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:526)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:169)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 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)
> {code}
> Full log: [^server.log].
> I might or might not have it misconfigured, but what definitely should not happen is that when I try to shut the server down:
> {code}
> INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested via an OS signal
> {code}
> it crashes JVM (doublefree?):
> {code}
> # JRE version: Java(TM) SE Runtime Environment (8.0_121-b13) (build 1.8.0_121-b13)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # C [libcrypto.so.1.0.2h+0x117a64] sk_pop_free+0x24
> #
> {code}
> Core: [^hs_err_pid12281.log]
> {quote}
> Now, with this configuration, it happens pretty much immediately after the worker tries to register with the balancer:
> h3. Elytron
> {code}
> <server-ssl-contexts>
> <server-ssl-context name="serverSSLContext" cipher-suite-filter="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" providers="openssl" need-client-auth="false" key-managers="keyManager" protocols="TLSv1.2" trust-managers="trustManager"/>
> </server-ssl-contexts>
> <client-ssl-contexts>
> <client-ssl-context name="clientSSLContext" cipher-suite-filter="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" providers="openssl" key-managers="clientKeyManager" protocols="TLSv1.2" trust-managers="trustManager"/>
> </client-ssl-contexts>
> {code}
> h3. Undertow
> {code}
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
> <https-listener name="https" socket-binding="https" enable-http2="true" ssl-context="serverSSLContext"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <access-log/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> {code}
> h3. mod_cluster
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:3.0">
> <mod-cluster-config advertise-socket="modcluster" connector="https" ssl-context="clientSSLContext">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> See new [^crashes_on_mod_cluster_connection.server.log] and [^new_hs_err_pid13002.log].
> I must admit I am somewhat getting into low spirits with this whole {{client <\-\-H/2\-\->mod_cluster balancer<\-\-H/2\-\->mod_cluster worker}} and "just use Elytron" situation. Would it be possible for you to actually give it a try? Take 1 Wildfly and Undertow mod_cluster balancer, set it up with H/2 via Elytron, take 1 Wildfly node as H/2 mod_cluster worker configured with Elytron, start it...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months