[jira] [Created] (AMQ-9408) Jolokia throws exception during Windows service startup
Aaron Steigerwald created AMQ-9408: -- Summary: Jolokia throws exception during Windows service startup Key: AMQ-9408 URL: https://issues.apache.org/jira/browse/AMQ-9408 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.18.3 Reporter: Aaron Steigerwald The issue fixed in AMQ-9126 exists in the Windows service wrapper.conf file and causes the same problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-3968) Optionally disable Management UI HTTPS SNI host checking
[
https://issues.apache.org/jira/browse/ARTEMIS-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599724#comment-17599724
]
Aaron Steigerwald edited comment on ARTEMIS-3968 at 9/2/22 9:54 PM:
Yes, that solves the problem from a certificate perspective. However, the goal
of this Jira issue is to provide a means to disable SNI host checking without
having to modify the certificate or introduce DNS values that will not be there
in production.
was (Author: steigerwalda):
Yes, that solves the problem from a certificate perspective. However, the goal
of this Jira issue was to provide a means to disable SNI host checking without
having to modify the certificate or introduce DNS values that will not be there
in production.
> Optionally disable Management UI HTTPS SNI host checking
>
>
> Key: ARTEMIS-3968
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3968
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
>Affects Versions: 2.24.0
>Reporter: Aaron Steigerwald
>Priority: Major
>
> The Management UI, when configured to run in HTTPS mode, returns "HTTP ERROR
> 400 Invalid SNI" to the client browser if the web server's certificate
> (defined in the {{bootstrap.xml}} file's web element's {{keyStorePath}}
> attribute) does not contain the server's DNS name. It also prevents the
> browser from using "https://localhost...";. This makes running the broker in a
> dev and test environment difficult. A work around is to run it in HTTP mode
> but this prevents exercising the HTTPS parameters and certificates.
> I think the upgrade from Jetty 9.x to 10.x caused SNI host checking to be
> enabled by default or at least more strictly enforced.
> I disabled SNI host checking by modifying
> {{org.apache.activemq.artemis.component.WebServerComponent}} in the following
> way:
> Current 2.24.0 version:
> {code:java}
> httpConfiguration.addCustomizer(new SecureRequestCustomizer());{code}
> Modified 2.24.0 version to disable SNI host checking:
> {code:java}
> SecureRequestCustomizer secureRequestCustomizer = new
> SecureRequestCustomizer();
> secureRequestCustomizer.setSniHostCheck(false);
> httpConfiguration.addCustomizer(secureRequestCustomizer);{code}
> Adding another binding attribute to the {{bootstrap.xml}} file's web element,
> like "disableSniHostCheck", and using it to set
> "secureRequestCustomizer.setSniHostCheck(false)" would allow a configurable
> way to disable SNI host checking.
> -
> The following is provided for reference:
> Server Name Indication (SNI)
> https://stackoverflow.com/questions/69945173/http-error-400-invalid-sni-jetty-https-servlet
> Search for "jetty.ssl.sniHostCheck" in
> https://www.eclipse.org/jetty/documentation/jetty-10/operations-guide/index.html
> {{artemis.log}} entries:
> {noformat}
> 2022-08-31 21:35:39,512 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /console org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI
> 2022-08-31 21:35:39,560 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /favicon.ico org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI{noformat}
> Browser message when trying to access https://localhost:8163/console with SNI
> host checking enabled and a certificate with a DNS entry that does not match
> the server:
> {noformat}
> HTTP ERROR 400 Invalid SNI
> URI: /console
> STATUS: 400
> MESSAGE: Invalid SNI
> SERVLET: -
> CAUSED BY: org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> Caused by:
> org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> at
> org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:266)
> at
> org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:207)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$0(HttpChannel.java:501)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:762)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:497)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:282)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:319)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
> at
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:558)
> at
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:379)
> at
> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:146)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
> at
> org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(Sele
[jira] [Commented] (ARTEMIS-3968) Optionally disable Management UI HTTPS SNI host checking
[
https://issues.apache.org/jira/browse/ARTEMIS-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599724#comment-17599724
]
Aaron Steigerwald commented on ARTEMIS-3968:
Yes, that solves the problem from a certificate perspective. However, the goal
of this Jira issue was to provide a means to disable SNI host checking without
having to modify the certificate or introduce DNS values that will not be there
in production.
> Optionally disable Management UI HTTPS SNI host checking
>
>
> Key: ARTEMIS-3968
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3968
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
>Affects Versions: 2.24.0
>Reporter: Aaron Steigerwald
>Priority: Major
>
> The Management UI, when configured to run in HTTPS mode, returns "HTTP ERROR
> 400 Invalid SNI" to the client browser if the web server's certificate
> (defined in the {{bootstrap.xml}} file's web element's {{keyStorePath}}
> attribute) does not contain the server's DNS name. It also prevents the
> browser from using "https://localhost...";. This makes running the broker in a
> dev and test environment difficult. A work around is to run it in HTTP mode
> but this prevents exercising the HTTPS parameters and certificates.
> I think the upgrade from Jetty 9.x to 10.x caused SNI host checking to be
> enabled by default or at least more strictly enforced.
> I disabled SNI host checking by modifying
> {{org.apache.activemq.artemis.component.WebServerComponent}} in the following
> way:
> Current 2.24.0 version:
> {code:java}
> httpConfiguration.addCustomizer(new SecureRequestCustomizer());{code}
> Modified 2.24.0 version to disable SNI host checking:
> {code:java}
> SecureRequestCustomizer secureRequestCustomizer = new
> SecureRequestCustomizer();
> secureRequestCustomizer.setSniHostCheck(false);
> httpConfiguration.addCustomizer(secureRequestCustomizer);{code}
> Adding another binding attribute to the {{bootstrap.xml}} file's web element,
> like "disableSniHostCheck", and using it to set
> "secureRequestCustomizer.setSniHostCheck(false)" would allow a configurable
> way to disable SNI host checking.
> -
> The following is provided for reference:
> Server Name Indication (SNI)
> https://stackoverflow.com/questions/69945173/http-error-400-invalid-sni-jetty-https-servlet
> Search for "jetty.ssl.sniHostCheck" in
> https://www.eclipse.org/jetty/documentation/jetty-10/operations-guide/index.html
> {{artemis.log}} entries:
> {noformat}
> 2022-08-31 21:35:39,512 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /console org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI
> 2022-08-31 21:35:39,560 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /favicon.ico org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI{noformat}
> Browser message when trying to access https://localhost:8163/console with SNI
> host checking enabled and a certificate with a DNS entry that does not match
> the server:
> {noformat}
> HTTP ERROR 400 Invalid SNI
> URI: /console
> STATUS: 400
> MESSAGE: Invalid SNI
> SERVLET: -
> CAUSED BY: org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> Caused by:
> org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> at
> org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:266)
> at
> org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:207)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$0(HttpChannel.java:501)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:762)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:497)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:282)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:319)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
> at
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:558)
> at
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:379)
> at
> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:146)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
> at
> org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:412)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:381)
> at
> org.eclipse.jetty.util.thread.strategy.Adap
[jira] [Commented] (ARTEMIS-3968) Optionally disable Management UI HTTPS SNI host checking
[
https://issues.apache.org/jira/browse/ARTEMIS-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599682#comment-17599682
]
Aaron Steigerwald commented on ARTEMIS-3968:
You are correct, it doesn't matter in this configuration. Feel free to remove
the trustStorePath and trustStorePassword attributes. I just did and still
experience the same issue.
> Optionally disable Management UI HTTPS SNI host checking
>
>
> Key: ARTEMIS-3968
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3968
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
>Affects Versions: 2.24.0
>Reporter: Aaron Steigerwald
>Priority: Major
>
> The Management UI, when configured to run in HTTPS mode, returns "HTTP ERROR
> 400 Invalid SNI" to the client browser if the web server's certificate
> (defined in the {{bootstrap.xml}} file's web element's {{keyStorePath}}
> attribute) does not contain the server's DNS name. It also prevents the
> browser from using "https://localhost...";. This makes running the broker in a
> dev and test environment difficult. A work around is to run it in HTTP mode
> but this prevents exercising the HTTPS parameters and certificates.
> I think the upgrade from Jetty 9.x to 10.x caused SNI host checking to be
> enabled by default or at least more strictly enforced.
> I disabled SNI host checking by modifying
> {{org.apache.activemq.artemis.component.WebServerComponent}} in the following
> way:
> Current 2.24.0 version:
> {code:java}
> httpConfiguration.addCustomizer(new SecureRequestCustomizer());{code}
> Modified 2.24.0 version to disable SNI host checking:
> {code:java}
> SecureRequestCustomizer secureRequestCustomizer = new
> SecureRequestCustomizer();
> secureRequestCustomizer.setSniHostCheck(false);
> httpConfiguration.addCustomizer(secureRequestCustomizer);{code}
> Adding another binding attribute to the {{bootstrap.xml}} file's web element,
> like "disableSniHostCheck", and using it to set
> "secureRequestCustomizer.setSniHostCheck(false)" would allow a configurable
> way to disable SNI host checking.
> -
> The following is provided for reference:
> Server Name Indication (SNI)
> https://stackoverflow.com/questions/69945173/http-error-400-invalid-sni-jetty-https-servlet
> Search for "jetty.ssl.sniHostCheck" in
> https://www.eclipse.org/jetty/documentation/jetty-10/operations-guide/index.html
> {{artemis.log}} entries:
> {noformat}
> 2022-08-31 21:35:39,512 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /console org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI
> 2022-08-31 21:35:39,560 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /favicon.ico org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI{noformat}
> Browser message when trying to access https://localhost:8163/console with SNI
> host checking enabled and a certificate with a DNS entry that does not match
> the server:
> {noformat}
> HTTP ERROR 400 Invalid SNI
> URI: /console
> STATUS: 400
> MESSAGE: Invalid SNI
> SERVLET: -
> CAUSED BY: org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> Caused by:
> org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> at
> org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:266)
> at
> org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:207)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$0(HttpChannel.java:501)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:762)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:497)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:282)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:319)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
> at
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:558)
> at
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:379)
> at
> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:146)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
> at
> org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:412)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:381)
> at
> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:268)
>
[jira] [Comment Edited] (ARTEMIS-3968) Optionally disable Management UI HTTPS SNI host checking
[
https://issues.apache.org/jira/browse/ARTEMIS-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599677#comment-17599677
]
Aaron Steigerwald edited comment on ARTEMIS-3968 at 9/2/22 7:02 PM:
I login to the web console using username and password.
Hopefully you can reproduce it with this info:
{noformat}
# Create self-signed cert.
keytool -genkey -keyalg RSA -alias test_selfsigned -keystore test_keystore.jks
-storepass password -validity 3600 -keysize 2048
# Export the public key.
keytool -export -keystore test_keystore.jks -alias test_selfsigned -file
test_keystore.cer
# Import the public cert into the test_truststore.jks trust store.
keytool -import -alias test_selfsigned -file test_keystore.cer -storetype JKS
-keystore test_truststore.jks -storepass password{noformat}
bootstrap.xml web element:
{noformat}
https://0.0.0.0:8163";
path="web"
keyStorePath=""
keyStorePassword="password"
trustStorePath=""
trustStorePassword="password"
clientAuth="false"
includedTLSProtocols="TLSv1.2">
{noformat}
was (Author: steigerwalda):
I login to the web console using username and password.
Hopefully you can reproduce it with this info:
# Create self-signed cert.
keytool -genkey -keyalg RSA -alias test_selfsigned -keystore test_keystore.jks
-storepass password -validity 3600 -keysize 2048
# Export the public key.
keytool -export -keystore test_keystore.jks -alias test_selfsigned -file
test_keystore.cer
# Import the public cert into the test_truststore.jks trust store.
keytool -import -alias test_selfsigned -file test_keystore.cer -storetype JKS
-keystore test_truststore.jks -storepass password
bootstrap.xml web element:
https://0.0.0.0:8163";
path="web"
keyStorePath=""
keyStorePassword="password"
trustStorePath=""
trustStorePassword="password"
clientAuth="false"
includedTLSProtocols="TLSv1.2">
> Optionally disable Management UI HTTPS SNI host checking
>
>
> Key: ARTEMIS-3968
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3968
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
>Affects Versions: 2.24.0
>Reporter: Aaron Steigerwald
>Priority: Major
>
> The Management UI, when configured to run in HTTPS mode, returns "HTTP ERROR
> 400 Invalid SNI" to the client browser if the web server's certificate
> (defined in the {{bootstrap.xml}} file's web element's {{keyStorePath}}
> attribute) does not contain the server's DNS name. It also prevents the
> browser from using "https://localhost...";. This makes running the broker in a
> dev and test environment difficult. A work around is to run it in HTTP mode
> but this prevents exercising the HTTPS parameters and certificates.
> I think the upgrade from Jetty 9.x to 10.x caused SNI host checking to be
> enabled by default or at least more strictly enforced.
> I disabled SNI host checking by modifying
> {{org.apache.activemq.artemis.component.WebServerComponent}} in the following
> way:
> Current 2.24.0 version:
> {code:java}
> httpConfiguration.addCustomizer(new SecureRequestCustomizer());{code}
> Modified 2.24.0 version to disable SNI host checking:
> {code:java}
> SecureRequestCustomizer secureRequestCustomizer = new
> SecureRequestCustomizer();
> secureRequestCustomizer.setSniHostCheck(false);
> httpConfiguration.addCustomizer(secureRequestCustomizer);{code}
> Adding another binding attribute to the {{bootstrap.xml}} file's web element,
> like "disableSniHostCheck", and using it to set
> "secureRequestCustomizer.setSniHostCheck(false)" would allow a configurable
> way to disable SNI host checking.
> -
> The following is provided for reference:
> Server Name Indication (SNI)
> https://stackoverflow.com/questions/69945173/http-error-400-invalid-sni-jetty-https-servlet
> Search for "jetty.ssl.sniHostCheck" in
> https://www.eclipse.org/jetty/documentation/jetty-10/operations-guide/index.html
> {{artemis.log}} entries:
> {noformat}
> 2022-08-31 21:35:39,512 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /console org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI
> 2022-08-31 21:35:39,560 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /favicon.ico org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI{noformat}
> Browser message when trying to access https://localhost:8163/console with SNI
> host checking enabled and a certificate with a DNS entry that does not match
> the server:
> {noformat}
> HTTP ERROR 400 Invalid SNI
> URI: /console
> STATUS: 400
> MESSAGE: Invalid SNI
> SERVLET: -
> CAUSED BY: org.eclipse.jetty.ht
[jira] [Commented] (ARTEMIS-3968) Optionally disable Management UI HTTPS SNI host checking
[
https://issues.apache.org/jira/browse/ARTEMIS-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599677#comment-17599677
]
Aaron Steigerwald commented on ARTEMIS-3968:
I login to the web console using username and password.
Hopefully you can reproduce it with this info:
# Create self-signed cert.
keytool -genkey -keyalg RSA -alias test_selfsigned -keystore test_keystore.jks
-storepass password -validity 3600 -keysize 2048
# Export the public key.
keytool -export -keystore test_keystore.jks -alias test_selfsigned -file
test_keystore.cer
# Import the public cert into the test_truststore.jks trust store.
keytool -import -alias test_selfsigned -file test_keystore.cer -storetype JKS
-keystore test_truststore.jks -storepass password
bootstrap.xml web element:
https://0.0.0.0:8163";
path="web"
keyStorePath=""
keyStorePassword="password"
trustStorePath=""
trustStorePassword="password"
clientAuth="false"
includedTLSProtocols="TLSv1.2">
> Optionally disable Management UI HTTPS SNI host checking
>
>
> Key: ARTEMIS-3968
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3968
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
>Affects Versions: 2.24.0
>Reporter: Aaron Steigerwald
>Priority: Major
>
> The Management UI, when configured to run in HTTPS mode, returns "HTTP ERROR
> 400 Invalid SNI" to the client browser if the web server's certificate
> (defined in the {{bootstrap.xml}} file's web element's {{keyStorePath}}
> attribute) does not contain the server's DNS name. It also prevents the
> browser from using "https://localhost...";. This makes running the broker in a
> dev and test environment difficult. A work around is to run it in HTTP mode
> but this prevents exercising the HTTPS parameters and certificates.
> I think the upgrade from Jetty 9.x to 10.x caused SNI host checking to be
> enabled by default or at least more strictly enforced.
> I disabled SNI host checking by modifying
> {{org.apache.activemq.artemis.component.WebServerComponent}} in the following
> way:
> Current 2.24.0 version:
> {code:java}
> httpConfiguration.addCustomizer(new SecureRequestCustomizer());{code}
> Modified 2.24.0 version to disable SNI host checking:
> {code:java}
> SecureRequestCustomizer secureRequestCustomizer = new
> SecureRequestCustomizer();
> secureRequestCustomizer.setSniHostCheck(false);
> httpConfiguration.addCustomizer(secureRequestCustomizer);{code}
> Adding another binding attribute to the {{bootstrap.xml}} file's web element,
> like "disableSniHostCheck", and using it to set
> "secureRequestCustomizer.setSniHostCheck(false)" would allow a configurable
> way to disable SNI host checking.
> -
> The following is provided for reference:
> Server Name Indication (SNI)
> https://stackoverflow.com/questions/69945173/http-error-400-invalid-sni-jetty-https-servlet
> Search for "jetty.ssl.sniHostCheck" in
> https://www.eclipse.org/jetty/documentation/jetty-10/operations-guide/index.html
> {{artemis.log}} entries:
> {noformat}
> 2022-08-31 21:35:39,512 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /console org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI
> 2022-08-31 21:35:39,560 WARN [org.eclipse.jetty.server.HttpChannel]
> handleException /favicon.ico org.eclipse.jetty.http.BadMessageException: 400:
> Invalid SNI{noformat}
> Browser message when trying to access https://localhost:8163/console with SNI
> host checking enabled and a certificate with a DNS entry that does not match
> the server:
> {noformat}
> HTTP ERROR 400 Invalid SNI
> URI: /console
> STATUS: 400
> MESSAGE: Invalid SNI
> SERVLET: -
> CAUSED BY: org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> Caused by:
> org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI
> at
> org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:266)
> at
> org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:207)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$0(HttpChannel.java:501)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:762)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:497)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:282)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:319)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
> at
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:558)
> at
> org.eclipse.jetty.io.ssl.SslCon
[jira] [Created] (ARTEMIS-3968) Optionally disable Management UI HTTPS SNI host checking
Aaron Steigerwald created ARTEMIS-3968: -- Summary: Optionally disable Management UI HTTPS SNI host checking Key: ARTEMIS-3968 URL: https://issues.apache.org/jira/browse/ARTEMIS-3968 Project: ActiveMQ Artemis Issue Type: Improvement Components: Web Console Affects Versions: 2.24.0 Reporter: Aaron Steigerwald The Management UI, when configured to run in HTTPS mode, returns "HTTP ERROR 400 Invalid SNI" to the client browser if the web server's certificate (defined in the bootstrap.xml file's web element's keyStorePath attribute) does not contain the server's DNS name. It also prevents the browser from using "https://localhost...";. This makes running the broker in a dev and test environment difficult. A work around is to run it in HTTP mode but this prevents exercising the HTTPS parameters and certificates. I think the upgrade from Jetty 9.x to 10.x caused SNI host checking to be enabled by default or at least more strictly enforced. I disabled SNI host checking by modifying org.apache.activemq.artemis.component.WebServerComponent in the following way: Current 2.24.0 version: httpConfiguration.addCustomizer(new SecureRequestCustomizer()); Modified 2.24.0 version to disable SNI host checking: SecureRequestCustomizer secureRequestCustomizer = new SecureRequestCustomizer(); secureRequestCustomizer.setSniHostCheck(false); httpConfiguration.addCustomizer(secureRequestCustomizer); Adding another binding attribute to the bootstrap.xml file's web element, like "disableSniHostCheck", and using it to set "secureRequestCustomizer.setSniHostCheck(false)" would allow a configurable way to disable SNI host checking. - The following is provided for reference: Server Name Indication (SNI) https://stackoverflow.com/questions/69945173/http-error-400-invalid-sni-jetty-https-servlet Search for "jetty.ssl.sniHostCheck" in https://www.eclipse.org/jetty/documentation/jetty-10/operations-guide/index.html artemis.log entries: 2022-08-31 21:35:39,512 WARN [org.eclipse.jetty.server.HttpChannel] handleException /console org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI 2022-08-31 21:35:39,560 WARN [org.eclipse.jetty.server.HttpChannel] handleException /favicon.ico org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI Browser message when trying to access https://localhost:8163/console with SNI host checking enabled and a certificate with a DNS entry that does not match the server: HTTP ERROR 400 Invalid SNI URI: /console STATUS: 400 MESSAGE: Invalid SNI SERVLET: - CAUSED BY: org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI Caused by: org.eclipse.jetty.http.BadMessageException: 400: Invalid SNI at org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:266) at org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:207) at org.eclipse.jetty.server.HttpChannel.lambda$handle$0(HttpChannel.java:501) at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:762) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:497) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:282) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:319) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100) at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:558) at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:379) at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:146) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100) at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:412) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:381) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:268) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.lambda$new$0(AdaptiveExecutionStrategy.java:138) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:407) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:894) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1038) at java.base/java.lang.Thread.run(Thread.java:829) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-3967) Camel WAR pom.xml file incorrect and incomplete
Aaron Steigerwald created ARTEMIS-3967:
--
Summary: Camel WAR pom.xml file incorrect and incomplete
Key: ARTEMIS-3967
URL: https://issues.apache.org/jira/browse/ARTEMIS-3967
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 2.24.0
Reporter: Aaron Steigerwald
The Camel WAR pom.xml file uses Camel 3.16.0. However, the pom.xml file is
incorrect and incomplete. The incorrect part is it specifies 2.20.0 for
camel-jms. The incomplete part is that Camel 3.x is much more modular than 2.x
and requires specifying individual modules. In addition to camel-spring and
camel-jms that are specified, the following are needed for everyone:
camel-spring-xml (for reading XML config files) and camel-jmx (for JMX
integration, which allows Artemis's HawtIO UI to interface with the Camel
config). The following are needed for my camelApplicationContext.xml file and
may be common enough to include for everyone: camel-core-languages (for
element filter rules) and camel-xpath (for element filter
rules).
The following pom.xml file worked for me:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.x
sd">
4.0.0
org.apache.activemq.examples.broker.camel
camel
2.24.0
camel-war
war
ActiveMQ Artemis Camel WAR Application
${project.basedir}/../../../../..
org.springframework
spring-web
${spring.version}
org.springframework
spring-tx
${spring.version}
org.springframework
spring-context
org.apache.camel
camel-spring
3.16.0
org.slf4j
slf4j-api
org.apache.camel
camel-spring-xml
3.16.0
org.slf4j
slf4j-api
org.apache.camel
camel-core-languages
3.16.0
org.slf4j
slf4j-api
org.apache.camel
camel-xpath
3.16.0
org.slf4j
slf4j-api
org.apache.camel
camel-jmx
3.16.0
org.slf4j
slf4j-api
org.apache.camel
camel-jms
3.16.0
org.slf4j
slf4j-api
org.apache.geronimo.specs
geronimo-jms_2.0_spec
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3388) URI query values decoded twice
[ https://issues.apache.org/jira/browse/ARTEMIS-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17381572#comment-17381572 ] Aaron Steigerwald commented on ARTEMIS-3388: Yes, I see your point. For whatever reason Artemis doesn't currently have a problem with any other character in that string, only the + sign. I'll encode the other characters in the future if I must. Thanks! > URI query values decoded twice > -- > > Key: ARTEMIS-3388 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3388 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Aaron Steigerwald >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > An encoded acceptor password like > keyStorePassword=ENC(ql6LSJ%2BYMxGN1yn1r/F0yw==) is changed to ENC(ql6LSJ > YMxGN1yn1r/F0yw==) prior to being passed to the SensitiveDataCodec.decode > method. This causes exceptions like "java.lang.IllegalArgumentException: > Illegal base64 character 20" if the SensitiveDataCodec implementation is > expecting Base64 characters because a space is not a valid Base64 character . > This appears to be happening because the string is URL decoded twice. The > first time is implicit in the > org.apache.activemq.artemis.utils.uri.URISchema.newObject method. It calls > uri.getQuery(), which according to > [https://docs.oracle.com/javase/8/docs/api/java/net/URI.html] "The > getUserInfo, getPath, getQuery, getFragment, getAuthority, and > getSchemeSpecificPart methods +decode+ any escaped octets in their > corresponding components. The strings returned by these methods may contain > both other characters and illegal characters, and will not contain any > escaped octets." The second time is explicit in the > org.apache.activemq.artemis.utils.uri.BeanSupport.decodeURI method. It calls > URLDecoder.decode(value, "UTF-8"). > The workaround is to replace all spaces with plus + characters in the custom > SensitiveDataCodec.decode method. This is safe because the method is > expecting only valid Base64 characters and the space character will only > exist if it's been converted from a plus + character. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3388) Encoded acceptor passwords replace plus + sign with space
Aaron Steigerwald created ARTEMIS-3388: -- Summary: Encoded acceptor passwords replace plus + sign with space Key: ARTEMIS-3388 URL: https://issues.apache.org/jira/browse/ARTEMIS-3388 Project: ActiveMQ Artemis Issue Type: Bug Components: ActiveMQ-Artemis-Native Affects Versions: 2.17.0 Reporter: Aaron Steigerwald Assignee: Clebert Suconic An encoded acceptor password like keyStorePassword=ENC(ql6LSJ%2BYMxGN1yn1r/F0yw==) is changed to ENC(ql6LSJ YMxGN1yn1r/F0yw==) prior to being passed to the SensitiveDataCodec.decode method. This causes exceptions like "java.lang.IllegalArgumentException: Illegal base64 character 20" if the SensitiveDataCodec implementation is expecting Base64 characters because a space is not a valid Base64 character . This appears to be happening because the string is URL decoded twice. The first time is implicit in the org.apache.activemq.artemis.utils.uri.URISchema.newObject method. It calls uri.getQuery(), which according to [https://docs.oracle.com/javase/8/docs/api/java/net/URI.html] "The getUserInfo, getPath, getQuery, getFragment, getAuthority, and getSchemeSpecificPart methods +decode+ any escaped octets in their corresponding components. The strings returned by these methods may contain both other characters and illegal characters, and will not contain any escaped octets." The second time is explicit in the org.apache.activemq.artemis.utils.uri.BeanSupport.decodeURI method. It calls URLDecoder.decode(value, "UTF-8"). The workaround is to replace all spaces with plus + characters in the custom SensitiveDataCodec.decode method. This is safe because the method is expecting only valid Base64 characters and the space character will only exist if it's been converted from a plus + character. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3031) Add SERVER_STOP_CALLED Notification
[
https://issues.apache.org/jira/browse/ARTEMIS-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17258369#comment-17258369
]
Aaron Steigerwald commented on ARTEMIS-3031:
Awesome! That looks great! Thank you!
> Add SERVER_STOP_CALLED Notification
> ---
>
> Key: ARTEMIS-3031
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3031
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Aaron Steigerwald
>Priority: Minor
> Attachments:
> Artemis_Camel_shutdown_with_SERVER_STOP_CALLED_Notification.txt,
> Artemis_Camel_shutdown_without_SERVER_STOP_CALLED_Notification.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There doesn't appear to be a way to tell when the Artemis server is starting
> to stop. This is needed to communicate with some web applications running
> inside the server's JVM. For example, it is needed to suspend or stop Camel
> before much of the Artemis server shuts down. Currently, most of the Artemis
> server's components shutdown before the WebServerComponent does, which
> contains web applications like Camel. A SERVER_STOP_CALLED Notification can
> be used to suspend or stop Camel via JMX before the Artemis server's
> acceptors shutdown.
> One way to accomplish this is to:
> 1) Add a new SERVER_STOP_CALLED enum to
> org.apache.activemq.artemis.api.core.management.CoreNotificationType.
> 2) Send a SERVER_STOP_CALLED Notification in
> org.apache.activemq.artemis.cli.commands.Run.stop() like the following:
> {noformat}
> if (server != null) {
> // Start new code
> TypedProperties props = new TypedProperties();
> props.putSimpleStringProperty(new SimpleString("callingClass"),
> new SimpleString(this.getClass().getName()));
> props.putSimpleStringProperty(new SimpleString("callingMethod"),
> new SimpleString("stop"));
> server.getServer().getManagementService().sendNotification(new
> Notification(null, SyndeoNotificationType.SERVER_STOP_CALLED, props));
> // End new code
> server.stop(true);
> }{noformat}
> Without this feature, web applications like Camel can take a long time to
> shutdown depending on the configuration. Also, the shutdown can appear
> ungraceful and it's unclear what impact it has on inflight messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3031) Add SERVER_STOP_CALLED Notification
[
https://issues.apache.org/jira/browse/ARTEMIS-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252007#comment-17252007
]
Aaron Steigerwald commented on ARTEMIS-3031:
Yes, I've got a Camel web application deployed within the same JVM as the
broker.
I am using the ActivateCallback interface and have implemented the deactivate()
and activationComplete() methods for suspending and resuming Camel. The problem
is deactivate() is called after Artemis has already shutdown some of its
components that affect Camel connections. Camel logs errors and takes several
seconds to shutdown (7 in the attached example), which is likely due to the
Camel connection retry strategy.
The attached logs illustrate the difference between suspending embedded Camel
immediately after an Artemis stop is initiated using the SERVER_STOP_CALLED
Notification versus a regular embedded Camel shutdown without the
SERVER_STOP_CALLED Notification. Suspending Camel using the deactivate() method
produces the same results as shutting down without the SERVER_STOP_CALLED
Notification. I did not provide the deactivate() method log file because it's a
bit of effort to modify everything in my environment to generate it. I verified
the behavior during development. I can generate the deactivate() method log if
you would like to see it.
> Add SERVER_STOP_CALLED Notification
> ---
>
> Key: ARTEMIS-3031
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3031
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Aaron Steigerwald
>Priority: Minor
> Attachments:
> Artemis_Camel_shutdown_with_SERVER_STOP_CALLED_Notification.txt,
> Artemis_Camel_shutdown_without_SERVER_STOP_CALLED_Notification.txt
>
>
> There doesn't appear to be a way to tell when the Artemis server is starting
> to stop. This is needed to communicate with some web applications running
> inside the server's JVM. For example, it is needed to suspend or stop Camel
> before much of the Artemis server shuts down. Currently, most of the Artemis
> server's components shutdown before the WebServerComponent does, which
> contains web applications like Camel. A SERVER_STOP_CALLED Notification can
> be used to suspend or stop Camel via JMX before the Artemis server's
> acceptors shutdown.
> One way to accomplish this is to:
> 1) Add a new SERVER_STOP_CALLED enum to
> org.apache.activemq.artemis.api.core.management.CoreNotificationType.
> 2) Send a SERVER_STOP_CALLED Notification in
> org.apache.activemq.artemis.cli.commands.Run.stop() like the following:
> {noformat}
> if (server != null) {
> // Start new code
> TypedProperties props = new TypedProperties();
> props.putSimpleStringProperty(new SimpleString("callingClass"),
> new SimpleString(this.getClass().getName()));
> props.putSimpleStringProperty(new SimpleString("callingMethod"),
> new SimpleString("stop"));
> server.getServer().getManagementService().sendNotification(new
> Notification(null, SyndeoNotificationType.SERVER_STOP_CALLED, props));
> // End new code
> server.stop(true);
> }{noformat}
> Without this feature, web applications like Camel can take a long time to
> shutdown depending on the configuration. Also, the shutdown can appear
> ungraceful and it's unclear what impact it has on inflight messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3031) Add SERVER_STOP_CALLED Notification
[
https://issues.apache.org/jira/browse/ARTEMIS-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Steigerwald updated ARTEMIS-3031:
---
Attachment: Artemis_Camel_shutdown_with_SERVER_STOP_CALLED_Notification.txt
> Add SERVER_STOP_CALLED Notification
> ---
>
> Key: ARTEMIS-3031
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3031
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Aaron Steigerwald
>Priority: Minor
> Attachments:
> Artemis_Camel_shutdown_with_SERVER_STOP_CALLED_Notification.txt,
> Artemis_Camel_shutdown_without_SERVER_STOP_CALLED_Notification.txt
>
>
> There doesn't appear to be a way to tell when the Artemis server is starting
> to stop. This is needed to communicate with some web applications running
> inside the server's JVM. For example, it is needed to suspend or stop Camel
> before much of the Artemis server shuts down. Currently, most of the Artemis
> server's components shutdown before the WebServerComponent does, which
> contains web applications like Camel. A SERVER_STOP_CALLED Notification can
> be used to suspend or stop Camel via JMX before the Artemis server's
> acceptors shutdown.
> One way to accomplish this is to:
> 1) Add a new SERVER_STOP_CALLED enum to
> org.apache.activemq.artemis.api.core.management.CoreNotificationType.
> 2) Send a SERVER_STOP_CALLED Notification in
> org.apache.activemq.artemis.cli.commands.Run.stop() like the following:
> {noformat}
> if (server != null) {
> // Start new code
> TypedProperties props = new TypedProperties();
> props.putSimpleStringProperty(new SimpleString("callingClass"),
> new SimpleString(this.getClass().getName()));
> props.putSimpleStringProperty(new SimpleString("callingMethod"),
> new SimpleString("stop"));
> server.getServer().getManagementService().sendNotification(new
> Notification(null, SyndeoNotificationType.SERVER_STOP_CALLED, props));
> // End new code
> server.stop(true);
> }{noformat}
> Without this feature, web applications like Camel can take a long time to
> shutdown depending on the configuration. Also, the shutdown can appear
> ungraceful and it's unclear what impact it has on inflight messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3031) Add SERVER_STOP_CALLED Notification
[
https://issues.apache.org/jira/browse/ARTEMIS-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Steigerwald updated ARTEMIS-3031:
---
Attachment:
Artemis_Camel_shutdown_without_SERVER_STOP_CALLED_Notification.txt
> Add SERVER_STOP_CALLED Notification
> ---
>
> Key: ARTEMIS-3031
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3031
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Aaron Steigerwald
>Priority: Minor
> Attachments:
> Artemis_Camel_shutdown_with_SERVER_STOP_CALLED_Notification.txt,
> Artemis_Camel_shutdown_without_SERVER_STOP_CALLED_Notification.txt
>
>
> There doesn't appear to be a way to tell when the Artemis server is starting
> to stop. This is needed to communicate with some web applications running
> inside the server's JVM. For example, it is needed to suspend or stop Camel
> before much of the Artemis server shuts down. Currently, most of the Artemis
> server's components shutdown before the WebServerComponent does, which
> contains web applications like Camel. A SERVER_STOP_CALLED Notification can
> be used to suspend or stop Camel via JMX before the Artemis server's
> acceptors shutdown.
> One way to accomplish this is to:
> 1) Add a new SERVER_STOP_CALLED enum to
> org.apache.activemq.artemis.api.core.management.CoreNotificationType.
> 2) Send a SERVER_STOP_CALLED Notification in
> org.apache.activemq.artemis.cli.commands.Run.stop() like the following:
> {noformat}
> if (server != null) {
> // Start new code
> TypedProperties props = new TypedProperties();
> props.putSimpleStringProperty(new SimpleString("callingClass"),
> new SimpleString(this.getClass().getName()));
> props.putSimpleStringProperty(new SimpleString("callingMethod"),
> new SimpleString("stop"));
> server.getServer().getManagementService().sendNotification(new
> Notification(null, SyndeoNotificationType.SERVER_STOP_CALLED, props));
> // End new code
> server.stop(true);
> }{noformat}
> Without this feature, web applications like Camel can take a long time to
> shutdown depending on the configuration. Also, the shutdown can appear
> ungraceful and it's unclear what impact it has on inflight messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-3031) Add SERVER_STOP_CALLED Notification
Aaron Steigerwald created ARTEMIS-3031:
--
Summary: Add SERVER_STOP_CALLED Notification
Key: ARTEMIS-3031
URL: https://issues.apache.org/jira/browse/ARTEMIS-3031
Project: ActiveMQ Artemis
Issue Type: New Feature
Components: Broker
Reporter: Aaron Steigerwald
There doesn't appear to be a way to tell when the Artemis server is starting to
stop. This is needed to communicate with some web applications running inside
the server's JVM. For example, it is needed to suspend or stop Camel before
much of the Artemis server shuts down. Currently, most of the Artemis server's
components shutdown before the WebServerComponent does, which contains web
applications like Camel. A SERVER_STOP_CALLED Notification can be used to
suspend or stop Camel via JMX before the Artemis server's acceptors shutdown.
One way to accomplish this is to:
1) Add a new SERVER_STOP_CALLED enum to
org.apache.activemq.artemis.api.core.management.CoreNotificationType.
2) Send a SERVER_STOP_CALLED Notification in
org.apache.activemq.artemis.cli.commands.Run.stop() like the following:
{noformat}
if (server != null) {
// Start new code
TypedProperties props = new TypedProperties();
props.putSimpleStringProperty(new SimpleString("callingClass"), new
SimpleString(this.getClass().getName()));
props.putSimpleStringProperty(new SimpleString("callingMethod"),
new SimpleString("stop"));
server.getServer().getManagementService().sendNotification(new
Notification(null, SyndeoNotificationType.SERVER_STOP_CALLED, props));
// End new code
server.stop(true);
}{noformat}
Without this feature, web applications like Camel can take a long time to
shutdown depending on the configuration. Also, the shutdown can appear
ungraceful and it's unclear what impact it has on inflight messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2923) Configuration plugins are not serializable and cause replication to fail
[
https://issues.apache.org/jira/browse/ARTEMIS-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Steigerwald updated ARTEMIS-2923:
---
Description:
The org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy()
method fails to serialize plugin list members containing one or more elements.
This can be demonstrated using the
examples\features\ha\colocated-failover-scale-down example. In each broker.xml
file, change the element to
(also remove the element) and add the
NotificationActiveMQServerPlugin from
[https://activemq.apache.org/components/artemis/documentation/latest/broker-plugins.html:]
{noformat}
{noformat}
Modified broker.xml files for the
examples\features\ha\colocated-failover-scale-down example are attached.
The following exception is generated:
{noformat}
ColocatedFailoverScaleDownExample0-out:2020-09-29 17:22:31,917 WARN
[org.apache.activemq.artemis.core.server] AMQ61: Failed to activate a
backup: java.security.PrivilegedActionException:
java.io.NotSerializableException:
org.apache.activemq.artemis.core.server.plugin.impl.NotificationActiveMQServerPlugin{noformat}
Two options exist for fixing this:
1) Implement the Serializable interface in all affected plugin classes.
2) Make all org.apache.activemq.artemis.core.config.impl.ConfigurationImpl
plugin list members transient and NOT final, create setters for them, and
manually copy the plugin lists after serialization in the
org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy() method
like so:
{noformat}
// Manually copy all plugins because they have been defined as
transient due to many classes in their hierarchy not implementing the
Serializable interface.
((ConfigurationImpl) config).setBrokerPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerPlugins()));
((ConfigurationImpl) config).setBrokerConnectionPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerConnectionPlugins()));
((ConfigurationImpl) config).setBrokerSessionPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerSessionPlugins()));
((ConfigurationImpl) config).setBrokerConsumerPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerConsumerPlugins()));
((ConfigurationImpl) config).setBrokerAddressPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerAddressPlugins()));
((ConfigurationImpl) config).setBrokerQueuePlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerQueuePlugins()));
((ConfigurationImpl) config).setBrokerBindingPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerBindingPlugins()));
((ConfigurationImpl) config).setBrokerMessagePlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerMessagePlugins()));
((ConfigurationImpl) config).setBrokerBridgePlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerBridgePlugins()));
((ConfigurationImpl) config).setBrokerCriticalPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerCriticalPlugins()));
((ConfigurationImpl) config).setBrokerFederationPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerFederationPlugins()));
((ConfigurationImpl) config).setBrokerResourcePlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerResourcePlugins()));
{noformat}
was:
The org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy()
method fails to serialize plugin list members containing one or more elements.
This can be demonstrated using the
examples\features\ha\colocated-failover-scale-down example. In each broker.xml
file, change the element to
(also remove the element) and add the
NotificationActiveMQServerPlugin from
[https://activemq.apache.org/components/artemis/documentation/latest/broker-plugins.html:]
{noformat}
{noformat}
The following exception is generated:
{noformat}
ColocatedFailoverScaleDownExample0-out:2020-09-29 17:22:31,917 WARN
[org.apache.activemq.artemis.core.server] AMQ61: Failed to activate a
backup: java.security.PrivilegedActionException:
java.io.NotSerializableException:
org.apache.activemq.artemis.core.server.plugin.impl.NotificationActiveMQServerPlugin{noformat}
Two options exist for fixing this:
1) Implement the Serializable interface in all affected plugin classes.
2) Make all org.apache.activemq.artemis.core.config.impl.ConfigurationImpl
plugin list members transient and NOT final, create setters for them, and
manually copy the plugin lists after serialization in the
org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy() method
like so:
{noformat}
// Manually copy all plugins because they have been defined as
transient due to many classes in their h
[jira] [Updated] (ARTEMIS-2923) Configuration plugins are not serializable and cause replication to fail
[
https://issues.apache.org/jira/browse/ARTEMIS-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Steigerwald updated ARTEMIS-2923:
---
Attachment: broker.xml.server1
> Configuration plugins are not serializable and cause replication to fail
>
>
> Key: ARTEMIS-2923
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2923
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.15.0
>Reporter: Aaron Steigerwald
>Priority: Major
> Attachments: broker.xml.server0, broker.xml.server1
>
>
> The org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy()
> method fails to serialize plugin list members containing one or more elements.
> This can be demonstrated using the
> examples\features\ha\colocated-failover-scale-down example. In each
> broker.xml file, change the element to
> (also remove the element) and
> add the NotificationActiveMQServerPlugin from
> [https://activemq.apache.org/components/artemis/documentation/latest/broker-plugins.html:]
> {noformat}
>
> class-name="org.apache.activemq.artemis.core.server.plugin.impl.NotificationActiveMQServerPlugin">
>
>
>
> {noformat}
> The following exception is generated:
> {noformat}
> ColocatedFailoverScaleDownExample0-out:2020-09-29 17:22:31,917 WARN
> [org.apache.activemq.artemis.core.server] AMQ61: Failed to activate a
> backup: java.security.PrivilegedActionException:
> java.io.NotSerializableException:
> org.apache.activemq.artemis.core.server.plugin.impl.NotificationActiveMQServerPlugin{noformat}
> Two options exist for fixing this:
> 1) Implement the Serializable interface in all affected plugin classes.
> 2) Make all org.apache.activemq.artemis.core.config.impl.ConfigurationImpl
> plugin list members transient and NOT final, create setters for them, and
> manually copy the plugin lists after serialization in the
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy() method
> like so:
> {noformat}
> // Manually copy all plugins because they have been defined as
> transient due to many classes in their hierarchy not implementing the
> Serializable interface.
> ((ConfigurationImpl) config).setBrokerPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerPlugins()));
> ((ConfigurationImpl) config).setBrokerConnectionPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerConnectionPlugins()));
> ((ConfigurationImpl) config).setBrokerSessionPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerSessionPlugins()));
> ((ConfigurationImpl) config).setBrokerConsumerPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerConsumerPlugins()));
> ((ConfigurationImpl) config).setBrokerAddressPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerAddressPlugins()));
> ((ConfigurationImpl) config).setBrokerQueuePlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerQueuePlugins()));
> ((ConfigurationImpl) config).setBrokerBindingPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerBindingPlugins()));
> ((ConfigurationImpl) config).setBrokerMessagePlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerMessagePlugins()));
> ((ConfigurationImpl) config).setBrokerBridgePlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerBridgePlugins()));
> ((ConfigurationImpl) config).setBrokerCriticalPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerCriticalPlugins()));
> ((ConfigurationImpl) config).setBrokerFederationPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerFederationPlugins()));
> ((ConfigurationImpl) config).setBrokerResourcePlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerResourcePlugins()));
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2923) Configuration plugins are not serializable and cause replication to fail
[
https://issues.apache.org/jira/browse/ARTEMIS-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Steigerwald updated ARTEMIS-2923:
---
Attachment: broker.xml.server0
> Configuration plugins are not serializable and cause replication to fail
>
>
> Key: ARTEMIS-2923
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2923
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.15.0
>Reporter: Aaron Steigerwald
>Priority: Major
> Attachments: broker.xml.server0, broker.xml.server1
>
>
> The org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy()
> method fails to serialize plugin list members containing one or more elements.
> This can be demonstrated using the
> examples\features\ha\colocated-failover-scale-down example. In each
> broker.xml file, change the element to
> (also remove the element) and
> add the NotificationActiveMQServerPlugin from
> [https://activemq.apache.org/components/artemis/documentation/latest/broker-plugins.html:]
> {noformat}
>
> class-name="org.apache.activemq.artemis.core.server.plugin.impl.NotificationActiveMQServerPlugin">
>
>
>
> {noformat}
> The following exception is generated:
> {noformat}
> ColocatedFailoverScaleDownExample0-out:2020-09-29 17:22:31,917 WARN
> [org.apache.activemq.artemis.core.server] AMQ61: Failed to activate a
> backup: java.security.PrivilegedActionException:
> java.io.NotSerializableException:
> org.apache.activemq.artemis.core.server.plugin.impl.NotificationActiveMQServerPlugin{noformat}
> Two options exist for fixing this:
> 1) Implement the Serializable interface in all affected plugin classes.
> 2) Make all org.apache.activemq.artemis.core.config.impl.ConfigurationImpl
> plugin list members transient and NOT final, create setters for them, and
> manually copy the plugin lists after serialization in the
> org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy() method
> like so:
> {noformat}
> // Manually copy all plugins because they have been defined as
> transient due to many classes in their hierarchy not implementing the
> Serializable interface.
> ((ConfigurationImpl) config).setBrokerPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerPlugins()));
> ((ConfigurationImpl) config).setBrokerConnectionPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerConnectionPlugins()));
> ((ConfigurationImpl) config).setBrokerSessionPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerSessionPlugins()));
> ((ConfigurationImpl) config).setBrokerConsumerPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerConsumerPlugins()));
> ((ConfigurationImpl) config).setBrokerAddressPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerAddressPlugins()));
> ((ConfigurationImpl) config).setBrokerQueuePlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerQueuePlugins()));
> ((ConfigurationImpl) config).setBrokerBindingPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerBindingPlugins()));
> ((ConfigurationImpl) config).setBrokerMessagePlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerMessagePlugins()));
> ((ConfigurationImpl) config).setBrokerBridgePlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerBridgePlugins()));
> ((ConfigurationImpl) config).setBrokerCriticalPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerCriticalPlugins()));
> ((ConfigurationImpl) config).setBrokerFederationPlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerFederationPlugins()));
> ((ConfigurationImpl) config).setBrokerResourcePlugins(new
> CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerResourcePlugins()));
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2923) Configuration plugins are not serializable and cause replication to fail
Aaron Steigerwald created ARTEMIS-2923:
--
Summary: Configuration plugins are not serializable and cause
replication to fail
Key: ARTEMIS-2923
URL: https://issues.apache.org/jira/browse/ARTEMIS-2923
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.15.0
Reporter: Aaron Steigerwald
The org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy()
method fails to serialize plugin list members containing one or more elements.
This can be demonstrated using the
examples\features\ha\colocated-failover-scale-down example. In each broker.xml
file, change the element to
(also remove the element) and add the
NotificationActiveMQServerPlugin from
[https://activemq.apache.org/components/artemis/documentation/latest/broker-plugins.html:]
{noformat}
{noformat}
The following exception is generated:
{noformat}
ColocatedFailoverScaleDownExample0-out:2020-09-29 17:22:31,917 WARN
[org.apache.activemq.artemis.core.server] AMQ61: Failed to activate a
backup: java.security.PrivilegedActionException:
java.io.NotSerializableException:
org.apache.activemq.artemis.core.server.plugin.impl.NotificationActiveMQServerPlugin{noformat}
Two options exist for fixing this:
1) Implement the Serializable interface in all affected plugin classes.
2) Make all org.apache.activemq.artemis.core.config.impl.ConfigurationImpl
plugin list members transient and NOT final, create setters for them, and
manually copy the plugin lists after serialization in the
org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy() method
like so:
{noformat}
// Manually copy all plugins because they have been defined as
transient due to many classes in their hierarchy not implementing the
Serializable interface.
((ConfigurationImpl) config).setBrokerPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerPlugins()));
((ConfigurationImpl) config).setBrokerConnectionPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerConnectionPlugins()));
((ConfigurationImpl) config).setBrokerSessionPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerSessionPlugins()));
((ConfigurationImpl) config).setBrokerConsumerPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerConsumerPlugins()));
((ConfigurationImpl) config).setBrokerAddressPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerAddressPlugins()));
((ConfigurationImpl) config).setBrokerQueuePlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerQueuePlugins()));
((ConfigurationImpl) config).setBrokerBindingPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerBindingPlugins()));
((ConfigurationImpl) config).setBrokerMessagePlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerMessagePlugins()));
((ConfigurationImpl) config).setBrokerBridgePlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerBridgePlugins()));
((ConfigurationImpl) config).setBrokerCriticalPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerCriticalPlugins()));
((ConfigurationImpl) config).setBrokerFederationPlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerFederationPlugins()));
((ConfigurationImpl) config).setBrokerResourcePlugins(new
CopyOnWriteArrayList<>(ConfigurationImpl.this.getBrokerResourcePlugins()));
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
