[JBoss JIRA] (DROOLS-2582) Workbench may block after some operation
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2582?page=com.atlassian.jira.plugi... ]
Kylin Soong updated DROOLS-2582:
--------------------------------
Attachment: Screenshot from 2018-05-23 16-23-05.png
> Workbench may block after some operation
> ----------------------------------------
>
> Key: DROOLS-2582
> URL: https://issues.jboss.org/browse/DROOLS-2582
> Project: Drools
> Issue Type: Bug
> Components: Examples (Workbench)
> Affects Versions: 7.5.0.Final
> Environment: * 7.5.0.Final-redhat-4 from RHDM 7.0
> Reporter: Kylin Soong
> Assignee: Michael Anstis
> Attachments: Screenshot from 2018-05-23 12-54-50.png, Screenshot from 2018-05-23 16-23-05.png
>
>
> Add asserts in RHDM 7 decision-central, in some occasion, a button click may cause the decision-central block, and a pop up wizard on the enter with running cycle and never stop, block the further operating.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3875) [jdk10] PatchModuleInvalidationWithRenamingFailureTestCase#test failure
by Petr Kremensky (JIRA)
Petr Kremensky created WFCORE-3875:
--------------------------------------
Summary: [jdk10] PatchModuleInvalidationWithRenamingFailureTestCase#test failure
Key: WFCORE-3875
URL: https://issues.jboss.org/browse/WFCORE-3875
Project: WildFly Core
Issue Type: Bug
Components: Patching , Test Suite
Affects Versions: 5.0.0.Beta4
Reporter: Petr Kremensky
Assignee: Alexey Loubyansky
org.jboss.as.patching.tests.PatchModuleInvalidationWithRenamingFailureTestCase#test from patching module of wildfly-core fails with JDK10, works fine with JDK9.
*reproduce*
{noformat}
wildfly-core]$ mvn test -Dtest=PatchModuleInvalidationWithRenamingFailureTestCase#test -pl patching
...
[INFO] Running org.jboss.as.patching.tests.PatchModuleInvalidationWithRenamingFailureTestCase
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.363 s <<< FAILURE! - in org.jboss.as.patching.tests.PatchModuleInvalidationWithRenamingFailureTestCase
[ERROR] test(org.jboss.as.patching.tests.PatchModuleInvalidationWithRenamingFailureTestCase) Time elapsed: 0.359 s <<< FAILURE!
java.lang.AssertionError:
Expected: is <false>
but: was <true>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:956)
at org.junit.Assert.assertThat(Assert.java:923)
at org.jboss.as.patching.tests.PatchModuleInvalidationWithRenamingFailureTestCase.test(PatchModuleInvalidationWithRenamingFailureTestCase.java:97)
...
{noformat}
Environment:
{noformat}
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
Maven home: /usr/lib/maven
Java version: 10.0.1, vendor: Oracle Corporation
{noformat}
Byteman is being involved in the test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3869) [jdk10] DeletionCollisionTest#testFileLockByRemoveContent failure
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3869?page=com.atlassian.jira.plugi... ]
Petr Kremensky updated WFCORE-3869:
-----------------------------------
Description:
org.jboss.as.repository.DeletionCollisionTest#testFileLockByRemoveContent from deployment-repository module of wildfly-core fails with JDK10, works fine with JDK9.
*reproduce*
{noformat}
wildfly-core]$ mvn test -Dtest=DeletionCollisionTest#testFileLockByRemoveContent -pl deployment-repository
...
[INFO] Running org.jboss.as.repository.DeletionCollisionTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.307 s <<< FAILURE! - in org.jboss.as.repository.DeletionCollisionTest
[ERROR] testFileLockByRemoveContent(org.jboss.as.repository.DeletionCollisionTest) Time elapsed: 0.301 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.jboss.as.repository.DeletionCollisionTest.testFileLockByRemoveContent(DeletionCollisionTest.java:117)
...
{noformat}
Exception expected by the test - [WFLYDR0019|https://github.com/wildfly/wildfly-core/blob/master/deployment...]
{noformat}
Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0019: Deployment is locked by another operation
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:550)
at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Actual exception thrown with JDK10
{noformat}
Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0020: Error accessing deployment files
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:563)
at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.io.FileNotFoundException: target
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:376)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.readFile(PathUtil.java:356)
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:554)
... 5 more
{noformat}
Environment:
{noformat}
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
Maven home: /usr/lib/maven
Java version: 10.0.1, vendor: Oracle Corporation
{noformat}
Byteman is being involved in the test.
was:
DeletionCollisionTest#testFileLockByRemoveContent from deployment-repository module of wildfly-core fails with JDK10, works fine with JDK9.
*reproduce*
{noformat}
wildfly-core]$ mvn test -Dtest=DeletionCollisionTest#testFileLockByRemoveContent -pl deployment-repository
...
[INFO] Running org.jboss.as.repository.DeletionCollisionTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.307 s <<< FAILURE! - in org.jboss.as.repository.DeletionCollisionTest
[ERROR] testFileLockByRemoveContent(org.jboss.as.repository.DeletionCollisionTest) Time elapsed: 0.301 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.jboss.as.repository.DeletionCollisionTest.testFileLockByRemoveContent(DeletionCollisionTest.java:117)
...
{noformat}
Exception expected by the test - [WFLYDR0019|https://github.com/wildfly/wildfly-core/blob/master/deployment...]
{noformat}
Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0019: Deployment is locked by another operation
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:550)
at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Actual exception thrown with JDK10
{noformat}
Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0020: Error accessing deployment files
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:563)
at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.io.FileNotFoundException: target
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:376)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.readFile(PathUtil.java:356)
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:554)
... 5 more
{noformat}
Environment:
{noformat}
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
Maven home: /usr/lib/maven
Java version: 10.0.1, vendor: Oracle Corporation
{noformat}
Byteman is being involved in the test.
> [jdk10] DeletionCollisionTest#testFileLockByRemoveContent failure
> -----------------------------------------------------------------
>
> Key: WFCORE-3869
> URL: https://issues.jboss.org/browse/WFCORE-3869
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Test Suite
> Affects Versions: 5.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: ehsavoie Hugonnet
>
> org.jboss.as.repository.DeletionCollisionTest#testFileLockByRemoveContent from deployment-repository module of wildfly-core fails with JDK10, works fine with JDK9.
>
> *reproduce*
> {noformat}
> wildfly-core]$ mvn test -Dtest=DeletionCollisionTest#testFileLockByRemoveContent -pl deployment-repository
> ...
> [INFO] Running org.jboss.as.repository.DeletionCollisionTest
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.307 s <<< FAILURE! - in org.jboss.as.repository.DeletionCollisionTest
> [ERROR] testFileLockByRemoveContent(org.jboss.as.repository.DeletionCollisionTest) Time elapsed: 0.301 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.jboss.as.repository.DeletionCollisionTest.testFileLockByRemoveContent(DeletionCollisionTest.java:117)
> ...
> {noformat}
>
> Exception expected by the test - [WFLYDR0019|https://github.com/wildfly/wildfly-core/blob/master/deployment...]
> {noformat}
> Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0019: Deployment is locked by another operation
> at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:550)
> at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
> Actual exception thrown with JDK10
> {noformat}
> Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0020: Error accessing deployment files
> at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:563)
> at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: java.io.FileNotFoundException: target
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:376)
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
> at org.jboss.as.repository.PathUtil.readFile(PathUtil.java:356)
> at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:554)
> ... 5 more
> {noformat}
> Environment:
> {noformat}
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: /usr/lib/maven
> Java version: 10.0.1, vendor: Oracle Corporation
> {noformat}
> Byteman is being involved in the test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3874) [jdk10] FileSystemDeploymentServiceUnitTestCase#testNoUndeployment failure
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3874?page=com.atlassian.jira.plugi... ]
Petr Kremensky updated WFCORE-3874:
-----------------------------------
Description:
org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase#testNoUndeployment from deployment-scanner module of wildfly-core fails with JDK10, works fine with JDK9.
*reproduce*
{noformat}
wildfly-core]$ mvn test -Dtest=FileSystemDeploymentServiceUnitTestCase#testNoUndeployment -pl deployment-scanner
...
[INFO] Running org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.121 s <<< FAILURE! - in org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase
[ERROR] testNoUndeployment(org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase) Time elapsed: 0.115 s <<< FAILURE!
java.lang.AssertionError: RuntimeException expected
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment(FileSystemDeploymentServiceUnitTestCase.java:1798)
...
{noformat}
Environment:
{noformat}
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
Maven home: /usr/lib/maven
Java version: 10.0.1, vendor: Oracle Corporation
{noformat}
Byteman is being involved in the test.
was:
FileSystemDeploymentServiceUnitTestCase#testNoUndeployment from deployment-scanner module of wildfly-core fails with JDK10, works fine with JDK9.
*reproduce*
{noformat}
wildfly-core]$ mvn test -Dtest=FileSystemDeploymentServiceUnitTestCase#testNoUndeployment -pl deployment-scanner
...
[INFO] Running org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.121 s <<< FAILURE! - in org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase
[ERROR] testNoUndeployment(org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase) Time elapsed: 0.115 s <<< FAILURE!
java.lang.AssertionError: RuntimeException expected
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment(FileSystemDeploymentServiceUnitTestCase.java:1798)
...
{noformat}
Environment:
{noformat}
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
Maven home: /usr/lib/maven
Java version: 10.0.1, vendor: Oracle Corporation
{noformat}
Byteman is being involved in the test.
> [jdk10] FileSystemDeploymentServiceUnitTestCase#testNoUndeployment failure
> --------------------------------------------------------------------------
>
> Key: WFCORE-3874
> URL: https://issues.jboss.org/browse/WFCORE-3874
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Test Suite
> Affects Versions: 5.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: ehsavoie Hugonnet
>
> org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase#testNoUndeployment from deployment-scanner module of wildfly-core fails with JDK10, works fine with JDK9.
> *reproduce*
> {noformat}
> wildfly-core]$ mvn test -Dtest=FileSystemDeploymentServiceUnitTestCase#testNoUndeployment -pl deployment-scanner
> ...
> [INFO] Running org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.121 s <<< FAILURE! - in org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase
> [ERROR] testNoUndeployment(org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase) Time elapsed: 0.115 s <<< FAILURE!
> java.lang.AssertionError: RuntimeException expected
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment(FileSystemDeploymentServiceUnitTestCase.java:1798)
> ...
> {noformat}
> Environment:
> {noformat}
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: /usr/lib/maven
> Java version: 10.0.1, vendor: Oracle Corporation
> {noformat}
> Byteman is being involved in the test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Kabir Khan resolved WFLY-10392.
-------------------------------
Fix Version/s: 13.0.0.CR1
Resolution: Done
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 13.0.0.CR1
>
> Attachments: image-2018-05-19-10-26-05-662.png
>
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3869) [jdk10] DeletionCollisionTest#testFileLockByRemoveContent failure
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3869?page=com.atlassian.jira.plugi... ]
Petr Kremensky updated WFCORE-3869:
-----------------------------------
Description:
DeletionCollisionTest#testFileLockByRemoveContent from deployment-repository module of wildfly-core fails with JDK10, works fine with JDK9.
*reproduce*
{noformat}
wildfly-core]$ mvn test -Dtest=DeletionCollisionTest#testFileLockByRemoveContent -pl deployment-repository
...
[INFO] Running org.jboss.as.repository.DeletionCollisionTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.307 s <<< FAILURE! - in org.jboss.as.repository.DeletionCollisionTest
[ERROR] testFileLockByRemoveContent(org.jboss.as.repository.DeletionCollisionTest) Time elapsed: 0.301 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.jboss.as.repository.DeletionCollisionTest.testFileLockByRemoveContent(DeletionCollisionTest.java:117)
...
{noformat}
Exception expected by the test - [WFLYDR0019|https://github.com/wildfly/wildfly-core/blob/master/deployment...]
{noformat}
Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0019: Deployment is locked by another operation
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:550)
at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Actual exception thrown with JDK10
{noformat}
Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0020: Error accessing deployment files
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:563)
at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.io.FileNotFoundException: target
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:376)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.readFile(PathUtil.java:356)
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:554)
... 5 more
{noformat}
Environment:
{noformat}
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
Maven home: /usr/lib/maven
Java version: 10.0.1, vendor: Oracle Corporation
{noformat}
Byteman is being involved in the test.
was:
DeletionCollisionTest#testFileLockByRemoveContent from deployment-repository module of wildfly-core fails with JDK10, works fine with JDK9.
*reproduce*
{noformat}
wildfly-core]$ mvn test -Dtest=DeletionCollisionTest#testFileLockByRemoveContent -DtestLogToFile=false -pl deployment-repository
...
[INFO] Running org.jboss.as.repository.DeletionCollisionTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.307 s <<< FAILURE! - in org.jboss.as.repository.DeletionCollisionTest
[ERROR] testFileLockByRemoveContent(org.jboss.as.repository.DeletionCollisionTest) Time elapsed: 0.301 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.jboss.as.repository.DeletionCollisionTest.testFileLockByRemoveContent(DeletionCollisionTest.java:117)
{noformat}
Exception expected by the test - [WFLYDR0019|https://github.com/wildfly/wildfly-core/blob/master/deployment...]
{noformat}
Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0019: Deployment is locked by another operation
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:550)
at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Actual exception thrown with JDK10
{noformat}
Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0020: Error accessing deployment files
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:563)
at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.io.FileNotFoundException: target
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:376)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
at org.jboss.as.repository.PathUtil.readFile(PathUtil.java:356)
at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:554)
... 5 more
{noformat}
Environment:
{noformat}
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
Maven home: /usr/lib/maven
Java version: 10.0.1, vendor: Oracle Corporation
{noformat}
> [jdk10] DeletionCollisionTest#testFileLockByRemoveContent failure
> -----------------------------------------------------------------
>
> Key: WFCORE-3869
> URL: https://issues.jboss.org/browse/WFCORE-3869
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Test Suite
> Affects Versions: 5.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: ehsavoie Hugonnet
>
> DeletionCollisionTest#testFileLockByRemoveContent from deployment-repository module of wildfly-core fails with JDK10, works fine with JDK9.
>
> *reproduce*
> {noformat}
> wildfly-core]$ mvn test -Dtest=DeletionCollisionTest#testFileLockByRemoveContent -pl deployment-repository
> ...
> [INFO] Running org.jboss.as.repository.DeletionCollisionTest
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.307 s <<< FAILURE! - in org.jboss.as.repository.DeletionCollisionTest
> [ERROR] testFileLockByRemoveContent(org.jboss.as.repository.DeletionCollisionTest) Time elapsed: 0.301 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.jboss.as.repository.DeletionCollisionTest.testFileLockByRemoveContent(DeletionCollisionTest.java:117)
> ...
> {noformat}
>
> Exception expected by the test - [WFLYDR0019|https://github.com/wildfly/wildfly-core/blob/master/deployment...]
> {noformat}
> Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0019: Deployment is locked by another operation
> at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:550)
> at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
> Actual exception thrown with JDK10
> {noformat}
> Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0020: Error accessing deployment files
> at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:563)
> at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: java.io.FileNotFoundException: target
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:376)
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
> at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374)
> at org.jboss.as.repository.PathUtil.readFile(PathUtil.java:356)
> at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:554)
> ... 5 more
> {noformat}
> Environment:
> {noformat}
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: /usr/lib/maven
> Java version: 10.0.1, vendor: Oracle Corporation
> {noformat}
> Byteman is being involved in the test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3874) [jdk10] FileSystemDeploymentServiceUnitTestCase#testNoUndeployment failure
by Petr Kremensky (JIRA)
Petr Kremensky created WFCORE-3874:
--------------------------------------
Summary: [jdk10] FileSystemDeploymentServiceUnitTestCase#testNoUndeployment failure
Key: WFCORE-3874
URL: https://issues.jboss.org/browse/WFCORE-3874
Project: WildFly Core
Issue Type: Bug
Components: Deployment Scanner, Test Suite
Affects Versions: 5.0.0.Beta4
Reporter: Petr Kremensky
Assignee: ehsavoie Hugonnet
FileSystemDeploymentServiceUnitTestCase#testNoUndeployment from deployment-scanner module of wildfly-core fails with JDK10, works fine with JDK9.
*reproduce*
{noformat}
wildfly-core]$ mvn test -Dtest=FileSystemDeploymentServiceUnitTestCase#testNoUndeployment -pl deployment-scanner
...
[INFO] Running org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.121 s <<< FAILURE! - in org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase
[ERROR] testNoUndeployment(org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase) Time elapsed: 0.115 s <<< FAILURE!
java.lang.AssertionError: RuntimeException expected
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment(FileSystemDeploymentServiceUnitTestCase.java:1798)
...
{noformat}
Environment:
{noformat}
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
Maven home: /usr/lib/maven
Java version: 10.0.1, vendor: Oracle Corporation
{noformat}
Byteman is being involved in the test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1294) Wildfly Elytron Tool, Credential-store command, --salt option is validated only when --summary is used too.
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/ELY-1294?page=com.atlassian.jira.plugin.s... ]
Chao Wang updated ELY-1294:
---------------------------
Git Pull Request: https://github.com/wildfly-security/wildfly-elytron-tool/pull/90, https://github.com/wildfly-security/wildfly-elytron-tool/pull/99, https://github.com/wildfly-security/wildfly-elytron-tool/pull/148, https://github.com/wildfly-security/wildfly-elytron-tool/pull/149 (was: https://github.com/wildfly-security/wildfly-elytron-tool/pull/90, https://github.com/wildfly-security/wildfly-elytron-tool/pull/99)
> Wildfly Elytron Tool, Credential-store command, --salt option is validated only when --summary is used too.
> -----------------------------------------------------------------------------------------------------------
>
> Key: ELY-1294
> URL: https://issues.jboss.org/browse/ELY-1294
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Command-Line Tool, Credential Store
> Reporter: Hynek Švábek
> Assignee: Chao Wang
>
> Credential-store command \-\-salt option is validated only when is \-\-summary is used too.
> It is caused by generation MASKed password for summary output[1].
> It is at least strange and confusing to user: without \-\-summary is passed, with \-\-summary is failed (entry is stored in storage successfully).
> *How to reproduce*
> {code}
> [hsvabek@dhcp-10-40-5-17 bin]$ ./elytron-tool.sh credential-store --add secret_alias --password pass123 --create -x secret_password -l store005.jceks -s 1234567890 -i 230 --summary --debug
> Alias "secret_alias" has been successfully stored
> Exception encountered executing the command:
> java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long
> at com.sun.crypto.provider.PBES1Core.init(PBES1Core.java:234)
> at com.sun.crypto.provider.PBES1Core.init(PBES1Core.java:331)
> at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineInit(PBEWithMD5AndDESCipher.java:228)
> at javax.crypto.Cipher.implInit(Cipher.java:810)
> at javax.crypto.Cipher.chooseProvider(Cipher.java:864)
> at javax.crypto.Cipher.init(Cipher.java:1539)
> at javax.crypto.Cipher.init(Cipher.java:1470)
> at org.wildfly.security.util.PasswordBasedEncryptionUtil$Builder.createAndInitCipher(PasswordBasedEncryptionUtil.java:506)
> at org.wildfly.security.util.PasswordBasedEncryptionUtil$Builder.build(PasswordBasedEncryptionUtil.java:589)
> at org.wildfly.security.tool.MaskCommand.computeMasked(MaskCommand.java:117)
> at org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:287)
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.CR2/s...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10430) Warnings in log when failover is executed after clean shut down
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFLY-10430?page=com.atlassian.jira.plugin... ]
Jiri Ondrusek moved JBEAP-14779 to WFLY-10430:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-10430 (was: JBEAP-14779)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: (was: ActiveMQ)
Affects Version/s: 13.0.0.Beta1
(was: 7.0.0.ER1)
(was: 7.0.0.ER6)
> Warnings in log when failover is executed after clean shut down
> ---------------------------------------------------------------
>
> Key: WFLY-10430
> URL: https://issues.jboss.org/browse/WFLY-10430
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 13.0.0.Beta1
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
>
> Hi I have noticed that after failover there are warnings even if live server was shut down cleanly. Some of our customers watch logs for warnings very carefully and it makes them uncomfortable when correctly used operations make warnings. According to them such operations should trigger only info logging.
> 12:53:38,564 WARN [org.apache.activemq.artemis.core.client] (Thread-0 (ActiveMQ-client-global-threads-1770095631)) AMQ212037: Connection failure has been detected: AMQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 12:53:38,570 WARN [org.apache.activemq.artemis.core.client] (Thread-2 (ActiveMQ-client-global-threads-1770095631)) AMQ212037: Connection failure has been detected: AMQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 12:53:38,575 WARN [org.apache.activemq.artemis.core.client] (Thread-1 (ActiveMQ-client-global-threads-1770095631)) AMQ212037: Connection failure has been detected: AMQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 12:53:38,579 WARN [org.apache.activemq.artemis.core.client] (Thread-3 (ActiveMQ-client-global-threads-1770095631)) AMQ212037: Connection failure has been detected: AMQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 12:53:38,587 WARN [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-global-threads-1770095631)) AMQ222095: Connection failed with failedOver=false: ActiveMQDisconnectedException[errorType=DISCONNECTED message=AMQ119015: The connection was disconnected because of server shutdown]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:946)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:94)
> 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)
> 12:53:38,604 WARN [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-global-threads-1770095631)) AMQ222095: Connection failed with failedOver=false: ActiveMQDisconnectedException[errorType=DISCONNECTED message=AMQ119015: The connection was disconnected because of server shutdown]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:946)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:94)
> 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)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3873) SNI support for https-listeners
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3873?page=com.atlassian.jira.plugi... ]
Stuart Douglas moved WFLY-10429 to WFCORE-3873:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3873 (was: WFLY-10429)
Component/s: Security
(was: Security)
> SNI support for https-listeners
> -------------------------------
>
> Key: WFCORE-3873
> URL: https://issues.jboss.org/browse/WFCORE-3873
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Labels: Previous_RFE
>
> Java 8 has introduced for server side SNI support. The use case needed is having 1 jboss with more than 1 virtual servers and the customer wants to be able to use a different server certificate for each virtual server
> This may already be underway because of:
> https://issues.jboss.org/browse/UNDERTOW-750, and
> Elytron commits that indicate they are thinking about SNI support (org/wildfly/security/ssl/SSLUtils has SNI matcher)
> 2. Who is the customer behind the request?
> American Express (5384240)
> TAM customer: yes
> SRM customer: yes
> Strategic: yes
> 3. What is the nature and description of the request?
> Want SNI support to allow two applications with different hostnames and different certificates. Alternative is having certificates apply to both hostnames.
> 4. Why does the customer need this? (List the business requirements here)
> Avoid having overly broad certificates.
> 5. How would the customer like to achieve this? (List the functional requirements here)
> virtual-server (vhost) configuration should tie into SSL certificates configuration somehow. probably allow one to specify an alias name in the virtual-server element
> 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
> Configure two virtual-servers with different certificates. Verify a SSL client can connect and get the appropriate certificate
> 7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
> UNDERTOW-750 but with Elytron's TLS/SSL consolidation I expect other changes are needed
> 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
> As soon as possible in EAP 7.x
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month