[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFWIP-339:
------------------------------
Steps to Reproduce:
# unzip server
# copy `server.jks`, `client.jks` and `standalone-full.xml` files into the `EAP_HOME/standalone/configuration` directory
# start server
{code:java}
./bin/standalone.sh -c standalone-full.xml
{code}
# see relevant `WFOPENSSL0002` message is present during the server boot
was:
# unzip server
# copy `server.jks`, `client.jks` and `standalone-full.xml` files into the `EAP_HOME/standalone/configuration` directory
# start server
{code}
./bin/standalone.sh -c standalone-full.xml
{code}
> OpenSSL security provider seems to be used when not defined now
> ---------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFWIP-339:
------------------------------
Attachment: client.jks
server.jks
standalone-full.xml
> OpenSSL security provider seems to be used when not defined now
> ---------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now
by Jan Stourac (Jira)
Jan Stourac created WFWIP-339:
---------------------------------
Summary: OpenSSL security provider seems to be used when not defined now
Key: WFWIP-339
URL: https://issues.redhat.com/browse/WFWIP-339
Project: WildFly WIP
Issue Type: Bug
Components: Security
Reporter: Jan Stourac
Assignee: Farah Juma
It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
{quote}
16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
{quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (WFLY-13793) Attribute enable-amq1-prefix doesn't work (remote artemis)
by Nicolas De Amicis (Jira)
[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ]
Nicolas De Amicis commented on WFLY-13793:
------------------------------------------
I tried the same case under wildfly 20 and it seems that the MDB listen on the right queue (without jms.queue prefix). The problem was corrected between wildfly 17 and wildfly 20.
> Attribute enable-amq1-prefix doesn't work (remote artemis)
> ----------------------------------------------------------
>
> Key: WFLY-13793
> URL: https://issues.redhat.com/browse/WFLY-13793
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Management
> Affects Versions: 17.0.1.Final
> Reporter: Nicolas De Amicis
> Assignee: Chao Wang
> Priority: Major
>
> I need to connect Wildfly 17.0.1 to a remote Artemis server. I follow the doc here: [https://docs.wildfly.org/17/Admin_Guide.html#Messaging_Connect_a_pooled-c...] No problem for point 1 to 3. But when I follow the instruction for disabling the compatibility mode (enable-amq1-prefix) I have this error:
> {quote}{{[standalone@localhost:9990 /] /subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="enable-amq1-prefix", value="false")}}
> \{{{}}
> \{{ "outcome" => "failed",}}
> \{{ "failure-description" => "WFLYCTL0248: Invalid value false for enable-amq1-prefix; legal values are [XA_GENERIC, GENERIC, XA_T}}
> {{OPIC, TOPIC, QUEUE, XA_QUEUE]",}}
> \{{ "rolled-back" => true}}
> {{}}}
> {quote}
> If I deploy my MDB that connects to queue myqueue, I see in artemis console my MDB is connected to jms.queue.myqueue.
> I also tried to add the attribute manually but it seems it doesn't work:
> {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/}}{{jms/remoteCF}}{{" connectors="remote-artemis" enable-amq1-prefix="false"/>}}
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (WFWIP-335) Test SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites fails on RHEL8
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-335?page=com.atlassian.jira.plugin... ]
Jan Stourac resolved WFWIP-335.
-------------------------------
Resolution: Done
> Test SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites fails on RHEL8
> ------------------------------------------------------------------------------
>
> Key: WFWIP-335
> URL: https://issues.redhat.com/browse/WFWIP-335
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
>
> There is failing a new test directly in your PR for 'wildfly-openssl' project - [org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherS...]. I encountered this failure on RHEL8 with OpenSSL 1.1.1c installed:
> {code:title=ComparisonFailure}
> testAvailableProtocolsWithTLS13CipherSuites(org.wildfly.openssl.SslCiphersTest) Time elapsed: 0.112 sec <<< FAILURE!
> org.junit.ComparisonFailure: expected:<TLS_[AES_256_GCM_SHA384]> but was:<TLS_[CHACHA20_POLY1305_SHA256]>
> at org.junit.Assert.assertEquals(Assert.java:123)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites(SslCiphersTest.java:170)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
> After some investigation, it looks like this failure is tied with this version of OpenSSL and does not occur with newer 1.1.1g version. I also saw another failure with combination of OpenJDK 11.0.4 and OpenSSL 1.1.1c:
> {code:title=different failure - API incompatibility?}
> testAvailableProtocolsWithTLS13CipherSuites(org.wildfly.openssl.SslCiphersTest) Time elapsed: 0.031 sec <<< ERROR!
> javax.net.ssl.SSLException: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag
> at org.wildfly.openssl.OpenSSLEngine.handshake(OpenSSLEngine.java:1129)
> at org.wildfly.openssl.OpenSSLEngine.beginHandshakeImplicitly(OpenSSLEngine.java:1071)
> at org.wildfly.openssl.OpenSSLEngine.wrap(OpenSSLEngine.java:435)
> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:479)
> at org.wildfly.openssl.OpenSSLSocket.runHandshake(OpenSSLSocket.java:305)
> at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:509)
> at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:555)
> at org.wildfly.openssl.OpenSSLOutputStream.write(OpenSSLOutputStream.java:51)
> at org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites(SslCiphersTest.java:159)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
> Here is a summary, see:
> {quote}
> OpenJDK 11.0.4 + OpenSSL 1.1.1c = fail - different failure - some API incompatibilty???
> OpenJDK 11.0.4 + OpenSSL 1.1.1g = pass
> OpenJDK 11.0.6 + OpenSSL 1.1.1c = ComparisonFailure as mentioned above
> OpenJDK 11.0.6 + OpenSSL 1.1.1g = pass
> OpenJDK 11.0.8 + OpenSSL 1.1.1c = ComparisonFailure as mentioned above
> OpenJDK 11.0.8 + OpenSSL 1.1.1g = pass
> {quote}
> Basically means that newer OpenSSL works okay. Although, this may still be problem for customers of RHEL8 until OpenSSL there is not updated.
> Not sure whether this test failure may have any real bad effect on customers, still I wanted to point this out here
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (WFWIP-335) Test SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites fails on RHEL8
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-335?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFWIP-335:
-----------------------------------
Hi [~fjuma], thank you for your detailed explanation! This makes sense. I can see that test is fixed now too. Marking this as resolved. Thank you!
> Test SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites fails on RHEL8
> ------------------------------------------------------------------------------
>
> Key: WFWIP-335
> URL: https://issues.redhat.com/browse/WFWIP-335
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
>
> There is failing a new test directly in your PR for 'wildfly-openssl' project - [org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherS...]. I encountered this failure on RHEL8 with OpenSSL 1.1.1c installed:
> {code:title=ComparisonFailure}
> testAvailableProtocolsWithTLS13CipherSuites(org.wildfly.openssl.SslCiphersTest) Time elapsed: 0.112 sec <<< FAILURE!
> org.junit.ComparisonFailure: expected:<TLS_[AES_256_GCM_SHA384]> but was:<TLS_[CHACHA20_POLY1305_SHA256]>
> at org.junit.Assert.assertEquals(Assert.java:123)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites(SslCiphersTest.java:170)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
> After some investigation, it looks like this failure is tied with this version of OpenSSL and does not occur with newer 1.1.1g version. I also saw another failure with combination of OpenJDK 11.0.4 and OpenSSL 1.1.1c:
> {code:title=different failure - API incompatibility?}
> testAvailableProtocolsWithTLS13CipherSuites(org.wildfly.openssl.SslCiphersTest) Time elapsed: 0.031 sec <<< ERROR!
> javax.net.ssl.SSLException: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag
> at org.wildfly.openssl.OpenSSLEngine.handshake(OpenSSLEngine.java:1129)
> at org.wildfly.openssl.OpenSSLEngine.beginHandshakeImplicitly(OpenSSLEngine.java:1071)
> at org.wildfly.openssl.OpenSSLEngine.wrap(OpenSSLEngine.java:435)
> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:479)
> at org.wildfly.openssl.OpenSSLSocket.runHandshake(OpenSSLSocket.java:305)
> at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:509)
> at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:555)
> at org.wildfly.openssl.OpenSSLOutputStream.write(OpenSSLOutputStream.java:51)
> at org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites(SslCiphersTest.java:159)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
> Here is a summary, see:
> {quote}
> OpenJDK 11.0.4 + OpenSSL 1.1.1c = fail - different failure - some API incompatibilty???
> OpenJDK 11.0.4 + OpenSSL 1.1.1g = pass
> OpenJDK 11.0.6 + OpenSSL 1.1.1c = ComparisonFailure as mentioned above
> OpenJDK 11.0.6 + OpenSSL 1.1.1g = pass
> OpenJDK 11.0.8 + OpenSSL 1.1.1c = ComparisonFailure as mentioned above
> OpenJDK 11.0.8 + OpenSSL 1.1.1g = pass
> {quote}
> Basically means that newer OpenSSL works okay. Although, this may still be problem for customers of RHEL8 until OpenSSL there is not updated.
> Not sure whether this test failure may have any real bad effect on customers, still I wanted to point this out here
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (WFCORE-5105) ProtocolConnectionUtils may leak connection objects whose future takes too long to complete
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-5105:
----------------------------------------
Summary: ProtocolConnectionUtils may leak connection objects whose future takes too long to complete
Key: WFCORE-5105
URL: https://issues.redhat.com/browse/WFCORE-5105
Project: WildFly Core
Issue Type: Bug
Components: Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
ProtocolConnectionUtils.connectSync calls remoting to connect and receives an IoFuture<Connection>, which it then waits on for, by default, 5 seconds. If the future completes or fails, it's fine. But if it times out connectSync throws an exception without first cancelling the future. This means remoting has no idea the connection isn't going to be used and if the connection ends up getting established it leaks via the chain WorkerThread -> selector -> table of SelectorKeys maintained by Selector -> NioSocketConduit -> NioSocketStreamConnection.
This has the potential to leak the connection on the other side as well, since if the connection was successfully established but never used or closed down by the initiating side it can just sit there.
One place where this can be more problematic is a remote HostController re-connecting to the DomainController after the HC successfully started but then the connection was lost. The HC will loop continually trying to connect. If this problem keeps happening the leaked connection objects will accumulate.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (WFLY-13793) Attribute enable-amq1-prefix doesn't work (remote artemis)
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ]
Chao Wang commented on WFLY-13793:
----------------------------------
Yes, that would be helpful if you can provide those files to reproduce the issue.
> Attribute enable-amq1-prefix doesn't work (remote artemis)
> ----------------------------------------------------------
>
> Key: WFLY-13793
> URL: https://issues.redhat.com/browse/WFLY-13793
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Management
> Affects Versions: 17.0.1.Final
> Reporter: Nicolas De Amicis
> Assignee: Chao Wang
> Priority: Major
>
> I need to connect Wildfly 17.0.1 to a remote Artemis server. I follow the doc here: [https://docs.wildfly.org/17/Admin_Guide.html#Messaging_Connect_a_pooled-c...] No problem for point 1 to 3. But when I follow the instruction for disabling the compatibility mode (enable-amq1-prefix) I have this error:
> {quote}{{[standalone@localhost:9990 /] /subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="enable-amq1-prefix", value="false")}}
> \{{{}}
> \{{ "outcome" => "failed",}}
> \{{ "failure-description" => "WFLYCTL0248: Invalid value false for enable-amq1-prefix; legal values are [XA_GENERIC, GENERIC, XA_T}}
> {{OPIC, TOPIC, QUEUE, XA_QUEUE]",}}
> \{{ "rolled-back" => true}}
> {{}}}
> {quote}
> If I deploy my MDB that connects to queue myqueue, I see in artemis console my MDB is connected to jms.queue.myqueue.
> I also tried to add the attribute manually but it seems it doesn't work:
> {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/}}{{jms/remoteCF}}{{" connectors="remote-artemis" enable-amq1-prefix="false"/>}}
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up
by Alojzij Blatnik (Jira)
[ https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi... ]
Alojzij Blatnik updated WFLY-13808:
-----------------------------------
Description:
HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase.
That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly).
I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode.
was:
HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase.
That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly).
I was poking around the source code (see diff.patch) and made a small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode.
> Make HTTP server available during deployment when starting up
> -------------------------------------------------------------
>
> Key: WFLY-13808
> URL: https://issues.redhat.com/browse/WFLY-13808
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 20.0.1.Final
> Reporter: Alojzij Blatnik
> Assignee: Brian Stansberry
> Priority: Major
>
> HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase.
> That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly).
> I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up
by Alojzij Blatnik (Jira)
Alojzij Blatnik created WFLY-13808:
--------------------------------------
Summary: Make HTTP server available during deployment when starting up
Key: WFLY-13808
URL: https://issues.redhat.com/browse/WFLY-13808
Project: WildFly
Issue Type: Bug
Affects Versions: 20.0.1.Final
Reporter: Alojzij Blatnik
Assignee: Brian Stansberry
HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase.
That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly).
I was poking around the source code (see diff.patch) and made a small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months