[jira] [Commented] (ARTEMIS-4174) JMX RMI connector-ports limited to localhost listen for remote connections
[
https://issues.apache.org/jira/browse/ARTEMIS-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761385#comment-17761385
]
ASF subversion and git services commented on ARTEMIS-4174:
--
Commit 98710fe0320c391631626736291962df3639de7f in activemq-artemis's branch
refs/heads/main from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=98710fe032 ]
ARTEMIS-4174 Changing JMXRMIRegistryPortTest to extend ActiveMQTestBase
This way we ensure no thread leaks in tests
> JMX RMI connector-ports limited to localhost listen for remote connections
> --
>
> Key: ARTEMIS-4174
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4174
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Marvin Blauth
>Priority: Minor
> Fix For: 2.31.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The documentation in docs/user-manual/en/management.md allows the
> interpretation that setting the connector-host of the "" element
> in management.xml could be used to limit the exposure of the JMX RMI TCP port
> to localhost only. It says the "connector-host" attribute for the
> "" element could be used to specify "the host to expose the agent
> on". Depending on the definition of the word "exposure" this may not be the
> case.
> The documentation in examples/features/standard/jmx-ssl/readme.md in contrast
> says 'To access this MBeanServer remotely, add the following to the
> management.xml configuration: connector-host="localhost"/>'. This is describing a remote connection using
> "localhost" in "connector-host", which at least would be in violation of my
> understanding of the notion of limiting exposure.
> Setting "connector-host" to "localhost" (which is the default) in fact leads
> to opening a port listening to all incoming external requests. This is due to
> creating an RMI registry in
> org.apache.activemq.artemis.core.server.management.RmiRegistryFactory.init()
> without providing a SocketFactory limiting the host.
> Example netstat output for such a setup:
> {noformat}
> $ netstat -tan | grep 1099 | grep LISTEN
> tcp6 0 0 :::1099 :::*LISTEN
> {noformat}
> It is unclear to me what the intended behavior is in terms of open TCP
> sockets. I assume a limitation of the exposure should be possible in my
> following suggestion for a solution (I can provide a patch, if this approach
> is to be taken).
>
> *Possible solution (if indeed desired this way)*
> If one wanted to expose the registry to the specified host only (not clear if
> that is the intended behavior as described above), a custom
> RMIServerSocketFactory could be created instead that only creates
> ServerSockets limited to the host name provided by the user in the
> "connector-host" attribute. This would then lead to the service only
> listening to the IP associated with the provided host name.
> Example netstat output using the same configuration but with the described
> change to the RmiRegistryFactory, showing the expected output:
> {noformat}
> $ netstat -tan | grep 1099 | grep LISTEN
> tcp6 0 0 127.0.0.1:1099 :::*LISTEN
> {noformat}
> A downside of this approach is that currently "localhost" seems to be the
> default value for connector-host if not explicitly set, see
> org.apache.activemq.artemis.core.config.JMXConnectorConfiguration. So a
> change in the semantics of the connector-host attributed would lead to a
> change of the behavior of users using this value implicitly. I assume that
> currently a remote login is not possible anyway if "localhost" is set, even
> though it is possible to initiate a TCP connection to the service, but I did
> not investigate this (note that this would be in contrast to the
> documentation cited above, so it should probably be investigated). If the
> assumption is indeed correct, the change in semantics should not negatively
> affect users.
>
> *Workaround*
> As workaround external connection attempts to the RMI ports can of course be
> dropped using a firewall.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4409) Update examples to use management.xml
[
https://issues.apache.org/jira/browse/ARTEMIS-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4409.
-
Fix Version/s: 2.31.0
Resolution: Fixed
> Update examples to use management.xml
> -
>
> Key: ARTEMIS-4409
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4409
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.31.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the "client-kickoff" and "xa-heuristic" examples use System
> properties to configure remote JMX connectivity. This kind of configuration
> was made obsolete by {{management.xml}}, but the examples weren't updated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4409) Update examples to use management.xml
[
https://issues.apache.org/jira/browse/ARTEMIS-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761372#comment-17761372
]
ASF subversion and git services commented on ARTEMIS-4409:
--
Commit 75c995198ebdb441fe08b2e1c2de82663261d7b5 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=75c995198e ]
ARTEMIS-4409 update examples to use management.xml
> Update examples to use management.xml
> -
>
> Key: ARTEMIS-4409
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4409
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the "client-kickoff" and "xa-heuristic" examples use System
> properties to configure remote JMX connectivity. This kind of configuration
> was made obsolete by {{management.xml}}, but the examples weren't updated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4416) Client can't use anycast without FQQN
[
https://issues.apache.org/jira/browse/ARTEMIS-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761348#comment-17761348
]
Justin Bertram edited comment on ARTEMIS-4416 at 9/1/23 4:43 PM:
-
Can you include example configuration to demonstrate your use-case?
For example, are you using something like this?
{code:xml}
{code}
was (Author: jbertram):
Can you include example configuration to demonstrate your use-case?
> Client can't use anycast without FQQN
> -
>
> Key: ARTEMIS-4416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4416
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.7.0, 2.28.0
>Reporter: Damien Picard
>Priority: Major
>
> Since artemis-jms-client@2.7.0, it's no longer possible to create an
> ActiveMQQueue object with an address (only FQQN).
> Use case:
> 1. We have an address with one or more queues (declare with an anycast
> router).
> 2. We create filters to distribute our messages to the correct queue
> 3. A producer sends a message to an address and the server is responsible for
> forwarding it to the correct queue.
> This use case works in 2.6.4. Since 2.7.0, we have an error raised by the
> "checkDestination" method ("Destination xxx does not exist, address exists
> but autoCreateQueues=false").
> ActiveMQ Artemis lets you do this, but the client prevents it.
> If we're using ActiveMQTopic, it works exclusively in multicast mode, so the
> above use case doesn't work either.
> Also, we could use FQQN exclusively, but we didn't design our architecture
> that way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4416) Client can't use anycast without FQQN
[
https://issues.apache.org/jira/browse/ARTEMIS-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761348#comment-17761348
]
Justin Bertram commented on ARTEMIS-4416:
-
Can you include example configuration to demonstrate your use-case?
> Client can't use anycast without FQQN
> -
>
> Key: ARTEMIS-4416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4416
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.7.0, 2.28.0
>Reporter: Damien Picard
>Priority: Major
>
> Since artemis-jms-client@2.7.0, it's no longer possible to create an
> ActiveMQQueue object with an address (only FQQN).
> Use case:
> 1. We have an address with one or more queues (declare with an anycast
> router).
> 2. We create filters to distribute our messages to the correct queue
> 3. A producer sends a message to an address and the server is responsible for
> forwarding it to the correct queue.
> This use case works in 2.6.4. Since 2.7.0, we have an error raised by the
> "checkDestination" method ("Destination xxx does not exist, address exists
> but autoCreateQueues=false").
> ActiveMQ Artemis lets you do this, but the client prevents it.
> If we're using ActiveMQTopic, it works exclusively in multicast mode, so the
> above use case doesn't work either.
> Also, we could use FQQN exclusively, but we didn't design our architecture
> that way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4416) Client can't use anycast without FQQN
[
https://issues.apache.org/jira/browse/ARTEMIS-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Picard updated ARTEMIS-4416:
---
Fix Version/s: (was: 2.6.4)
> Client can't use anycast without FQQN
> -
>
> Key: ARTEMIS-4416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4416
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.7.0, 2.28.0
>Reporter: Damien Picard
>Priority: Major
>
> Since artemis-jms-client@2.7.0, it's no longer possible to create an
> ActiveMQQueue object with an address (only FQQN).
> Use case:
> 1. We have an address with one or more queues (declare with an anycast
> router).
> 2. We create filters to distribute our messages to the correct queue
> 3. A producer sends a message to an address and the server is responsible for
> forwarding it to the correct queue.
> This use case works in 2.6.4. Since 2.7.0, we have an error raised by the
> "checkDestination" method ("Destination xxx does not exist, address exists
> but autoCreateQueues=false").
> ActiveMQ Artemis lets you do this, but the client prevents it.
> If we're using ActiveMQTopic, it works exclusively in multicast mode, so the
> above use case doesn't work either.
> Also, we could use FQQN exclusively, but we didn't design our architecture
> that way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4416) Client can't use anycast without FQQN
Damien Picard created ARTEMIS-4416:
--
Summary: Client can't use anycast without FQQN
Key: ARTEMIS-4416
URL: https://issues.apache.org/jira/browse/ARTEMIS-4416
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 2.28.0, 2.7.0
Reporter: Damien Picard
Fix For: 2.6.4
Since artemis-jms-client@2.7.0, it's no longer possible to create an
ActiveMQQueue object with an address (only FQQN).
Use case:
1. We have an address with one or more queues (declare with an anycast router).
2. We create filters to distribute our messages to the correct queue
3. A producer sends a message to an address and the server is responsible for
forwarding it to the correct queue.
This use case works in 2.6.4. Since 2.7.0, we have an error raised by the
"checkDestination" method ("Destination xxx does not exist, address exists but
autoCreateQueues=false").
ActiveMQ Artemis lets you do this, but the client prevents it.
If we're using ActiveMQTopic, it works exclusively in multicast mode, so the
above use case doesn't work either.
Also, we could use FQQN exclusively, but we didn't design our architecture that
way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4174) JMX RMI connector-ports limited to localhost listen for remote connections
[
https://issues.apache.org/jira/browse/ARTEMIS-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761347#comment-17761347
]
ASF subversion and git services commented on ARTEMIS-4174:
--
Commit 691771c7661efea52c8be3c4f535db4f939e3077 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=691771c766 ]
ARTEMIS-4174 fix style & rat
> JMX RMI connector-ports limited to localhost listen for remote connections
> --
>
> Key: ARTEMIS-4174
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4174
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Marvin Blauth
>Priority: Minor
> Fix For: 2.31.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The documentation in docs/user-manual/en/management.md allows the
> interpretation that setting the connector-host of the "" element
> in management.xml could be used to limit the exposure of the JMX RMI TCP port
> to localhost only. It says the "connector-host" attribute for the
> "" element could be used to specify "the host to expose the agent
> on". Depending on the definition of the word "exposure" this may not be the
> case.
> The documentation in examples/features/standard/jmx-ssl/readme.md in contrast
> says 'To access this MBeanServer remotely, add the following to the
> management.xml configuration: connector-host="localhost"/>'. This is describing a remote connection using
> "localhost" in "connector-host", which at least would be in violation of my
> understanding of the notion of limiting exposure.
> Setting "connector-host" to "localhost" (which is the default) in fact leads
> to opening a port listening to all incoming external requests. This is due to
> creating an RMI registry in
> org.apache.activemq.artemis.core.server.management.RmiRegistryFactory.init()
> without providing a SocketFactory limiting the host.
> Example netstat output for such a setup:
> {noformat}
> $ netstat -tan | grep 1099 | grep LISTEN
> tcp6 0 0 :::1099 :::*LISTEN
> {noformat}
> It is unclear to me what the intended behavior is in terms of open TCP
> sockets. I assume a limitation of the exposure should be possible in my
> following suggestion for a solution (I can provide a patch, if this approach
> is to be taken).
>
> *Possible solution (if indeed desired this way)*
> If one wanted to expose the registry to the specified host only (not clear if
> that is the intended behavior as described above), a custom
> RMIServerSocketFactory could be created instead that only creates
> ServerSockets limited to the host name provided by the user in the
> "connector-host" attribute. This would then lead to the service only
> listening to the IP associated with the provided host name.
> Example netstat output using the same configuration but with the described
> change to the RmiRegistryFactory, showing the expected output:
> {noformat}
> $ netstat -tan | grep 1099 | grep LISTEN
> tcp6 0 0 127.0.0.1:1099 :::*LISTEN
> {noformat}
> A downside of this approach is that currently "localhost" seems to be the
> default value for connector-host if not explicitly set, see
> org.apache.activemq.artemis.core.config.JMXConnectorConfiguration. So a
> change in the semantics of the connector-host attributed would lead to a
> change of the behavior of users using this value implicitly. I assume that
> currently a remote login is not possible anyway if "localhost" is set, even
> though it is possible to initiate a TCP connection to the service, but I did
> not investigate this (note that this would be in contrast to the
> documentation cited above, so it should probably be investigated). If the
> assumption is indeed correct, the change in semantics should not negatively
> affect users.
>
> *Workaround*
> As workaround external connection attempts to the RMI ports can of course be
> dropped using a firewall.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4174) JMX RMI connector-ports limited to localhost listen for remote connections
[
https://issues.apache.org/jira/browse/ARTEMIS-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-4174.
-
Fix Version/s: 2.31.0
Resolution: Fixed
> JMX RMI connector-ports limited to localhost listen for remote connections
> --
>
> Key: ARTEMIS-4174
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4174
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Marvin Blauth
>Priority: Minor
> Fix For: 2.31.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The documentation in docs/user-manual/en/management.md allows the
> interpretation that setting the connector-host of the "" element
> in management.xml could be used to limit the exposure of the JMX RMI TCP port
> to localhost only. It says the "connector-host" attribute for the
> "" element could be used to specify "the host to expose the agent
> on". Depending on the definition of the word "exposure" this may not be the
> case.
> The documentation in examples/features/standard/jmx-ssl/readme.md in contrast
> says 'To access this MBeanServer remotely, add the following to the
> management.xml configuration: connector-host="localhost"/>'. This is describing a remote connection using
> "localhost" in "connector-host", which at least would be in violation of my
> understanding of the notion of limiting exposure.
> Setting "connector-host" to "localhost" (which is the default) in fact leads
> to opening a port listening to all incoming external requests. This is due to
> creating an RMI registry in
> org.apache.activemq.artemis.core.server.management.RmiRegistryFactory.init()
> without providing a SocketFactory limiting the host.
> Example netstat output for such a setup:
> {noformat}
> $ netstat -tan | grep 1099 | grep LISTEN
> tcp6 0 0 :::1099 :::*LISTEN
> {noformat}
> It is unclear to me what the intended behavior is in terms of open TCP
> sockets. I assume a limitation of the exposure should be possible in my
> following suggestion for a solution (I can provide a patch, if this approach
> is to be taken).
>
> *Possible solution (if indeed desired this way)*
> If one wanted to expose the registry to the specified host only (not clear if
> that is the intended behavior as described above), a custom
> RMIServerSocketFactory could be created instead that only creates
> ServerSockets limited to the host name provided by the user in the
> "connector-host" attribute. This would then lead to the service only
> listening to the IP associated with the provided host name.
> Example netstat output using the same configuration but with the described
> change to the RmiRegistryFactory, showing the expected output:
> {noformat}
> $ netstat -tan | grep 1099 | grep LISTEN
> tcp6 0 0 127.0.0.1:1099 :::*LISTEN
> {noformat}
> A downside of this approach is that currently "localhost" seems to be the
> default value for connector-host if not explicitly set, see
> org.apache.activemq.artemis.core.config.JMXConnectorConfiguration. So a
> change in the semantics of the connector-host attributed would lead to a
> change of the behavior of users using this value implicitly. I assume that
> currently a remote login is not possible anyway if "localhost" is set, even
> though it is possible to initiate a TCP connection to the service, but I did
> not investigate this (note that this would be in contrast to the
> documentation cited above, so it should probably be investigated). If the
> assumption is indeed correct, the change in semantics should not negatively
> affect users.
>
> *Workaround*
> As workaround external connection attempts to the RMI ports can of course be
> dropped using a firewall.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4174) JMX RMI connector-ports limited to localhost listen for remote connections
[
https://issues.apache.org/jira/browse/ARTEMIS-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761346#comment-17761346
]
ASF subversion and git services commented on ARTEMIS-4174:
--
Commit 4d46588cdf87f2c00e27cc1122ac1118aad0aeb2 in activemq-artemis's branch
refs/heads/main from Marvin Blauth
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4d46588cdf ]
ARTEMIS-4174 Listen only to provided connector-host for JMX RMI sockets
> JMX RMI connector-ports limited to localhost listen for remote connections
> --
>
> Key: ARTEMIS-4174
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4174
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Marvin Blauth
>Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The documentation in docs/user-manual/en/management.md allows the
> interpretation that setting the connector-host of the "" element
> in management.xml could be used to limit the exposure of the JMX RMI TCP port
> to localhost only. It says the "connector-host" attribute for the
> "" element could be used to specify "the host to expose the agent
> on". Depending on the definition of the word "exposure" this may not be the
> case.
> The documentation in examples/features/standard/jmx-ssl/readme.md in contrast
> says 'To access this MBeanServer remotely, add the following to the
> management.xml configuration: connector-host="localhost"/>'. This is describing a remote connection using
> "localhost" in "connector-host", which at least would be in violation of my
> understanding of the notion of limiting exposure.
> Setting "connector-host" to "localhost" (which is the default) in fact leads
> to opening a port listening to all incoming external requests. This is due to
> creating an RMI registry in
> org.apache.activemq.artemis.core.server.management.RmiRegistryFactory.init()
> without providing a SocketFactory limiting the host.
> Example netstat output for such a setup:
> {noformat}
> $ netstat -tan | grep 1099 | grep LISTEN
> tcp6 0 0 :::1099 :::*LISTEN
> {noformat}
> It is unclear to me what the intended behavior is in terms of open TCP
> sockets. I assume a limitation of the exposure should be possible in my
> following suggestion for a solution (I can provide a patch, if this approach
> is to be taken).
>
> *Possible solution (if indeed desired this way)*
> If one wanted to expose the registry to the specified host only (not clear if
> that is the intended behavior as described above), a custom
> RMIServerSocketFactory could be created instead that only creates
> ServerSockets limited to the host name provided by the user in the
> "connector-host" attribute. This would then lead to the service only
> listening to the IP associated with the provided host name.
> Example netstat output using the same configuration but with the described
> change to the RmiRegistryFactory, showing the expected output:
> {noformat}
> $ netstat -tan | grep 1099 | grep LISTEN
> tcp6 0 0 127.0.0.1:1099 :::*LISTEN
> {noformat}
> A downside of this approach is that currently "localhost" seems to be the
> default value for connector-host if not explicitly set, see
> org.apache.activemq.artemis.core.config.JMXConnectorConfiguration. So a
> change in the semantics of the connector-host attributed would lead to a
> change of the behavior of users using this value implicitly. I assume that
> currently a remote login is not possible anyway if "localhost" is set, even
> though it is possible to initiate a TCP connection to the service, but I did
> not investigate this (note that this would be in contrast to the
> documentation cited above, so it should probably be investigated). If the
> assumption is indeed correct, the change in semantics should not negatively
> affect users.
>
> *Workaround*
> As workaround external connection attempts to the RMI ports can of course be
> dropped using a firewall.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4408) Update docker-run.sh for overriding etc folder after instance creation
[ https://issues.apache.org/jira/browse/ARTEMIS-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761345#comment-17761345 ] ASF subversion and git services commented on ARTEMIS-4408: -- Commit fd5b64f035aa4a7ec8d4a5951818ee331a8d3a62 in activemq-artemis's branch refs/heads/main from Muammer Eroglu [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fd5b64f035 ] ARTEMIS-4408 Update docker-run.sh for etc override ARTEMIS-4408 Update docker-run.sh for etc override After creating the artemis docker image using the docker-run.sh script, it is not possible to map a user supplied broker.xml using a volume mapping. The broker.xml file is not there before instance creation, so we cannot a static file mapping. This change introduces an etc-override folder to write over the etc folder contents. If a folder named etc-override exists inside the instance folder, its contents will be copied over to etc folder after instance creation. In order to use custom files that reside in etc, eg. broker.xml or artemis.profile; it is sufficient to place these files to a folder and map it to /var/lib/artemis-instance/etc-override folder of the image. The usage is also documented in readme.md file under the docker folder. > Update docker-run.sh for overriding etc folder after instance creation > -- > > Key: ARTEMIS-4408 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4408 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4372) Move CLI framework to picocli and implement auto-complete
[ https://issues.apache.org/jira/browse/ARTEMIS-4372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761338#comment-17761338 ] ASF subversion and git services commented on ARTEMIS-4372: -- Commit 78a3e66f3d5548407d720e3bad4da09c667089a8 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=78a3e66f3d ] ARTEMIS-4372 Renaming --staticCluster as --static-cluster > Move CLI framework to picocli and implement auto-complete > - > > Key: ARTEMIS-4372 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4372 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.31.0 > > Time Spent: 6h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4413) CheckTest.testNodeCheckTopology fails sporadically
[ https://issues.apache.org/jira/browse/ARTEMIS-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761339#comment-17761339 ] ASF subversion and git services commented on ARTEMIS-4413: -- Commit 47a3ee5304cdb1d26373988d9930f2b3ee763a24 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=47a3ee5304 ] ARTEMIS-4413 Improve reliability of CheckTest.testNodeCheckTopology I have also made some other quick changes to make testing here easier. > CheckTest.testNodeCheckTopology fails sporadically > -- > > Key: ARTEMIS-4413 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4413 > Project: ActiveMQ Artemis > Issue Type: Test >Affects Versions: 2.31.0 >Reporter: Robbie Gemmell >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > CheckTest.testNodeCheckTopology fails sporadically in CI, due to a thread > leak from shutdown issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4415) org.apache.activemq.artemis.tests.integration.server.LVQTest#testMultipleMessages fails intermittently
Gary Tully created ARTEMIS-4415: --- Summary: org.apache.activemq.artemis.tests.integration.server.LVQTest#testMultipleMessages fails intermittently Key: ARTEMIS-4415 URL: https://issues.apache.org/jira/browse/ARTEMIS-4415 Project: ActiveMQ Artemis Issue Type: Bug Components: Tests Affects Versions: 2.30.0 Reporter: Gary Tully Fix For: 2.31.0 org.apache.activemq.artemis.tests.integration.server.LVQTest#testMultipleMessages it produces 4 messages in two last value groups and asserts that it can consume the two last values in order. on occasion it only sees the first values -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4408) Update docker-run.sh for overriding etc folder after instance creation
[ https://issues.apache.org/jira/browse/ARTEMIS-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761331#comment-17761331 ] Muammer commented on ARTEMIS-4408: -- Added usage documentation, squashed commits and updated commit message: [https://github.com/apache/activemq-artemis/pull/4575/commits/226a35e1917781d79a23937137f87a808641b085] Also updated the title of pull request, including issue id: [https://github.com/apache/activemq-artemis/pull/4575] > Update docker-run.sh for overriding etc folder after instance creation > -- > > Key: ARTEMIS-4408 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4408 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4414) "AMQ214019: Invalid configuration" should provide clear information about file and maybe line number
[
https://issues.apache.org/jira/browse/ARTEMIS-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761315#comment-17761315
]
Justin Bertram edited comment on ARTEMIS-4414 at 9/1/23 1:40 PM:
-
The broker delegates all XML validation as well as basic parsing (including the
["xinclude"
functionality|https://activemq.apache.org/components/artemis/documentation/latest/configuration-index.html#modularising-brokerxml])
to the JVM. Therefore, if the validation of {{broker.xml}} fails (as it does
in this case) the broker doesn't necessarily know which file the invalid
configuration might be in. As you may have noticed, the exception is coming
from:
{noformat}
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException{noformat}
The broker doesn't control this code. It's coming from whatever JVM you're
running. You may be able to get this behavior changed by filing a bug report
with your JVM/JDK vendor, although it's worth noting that the input isnt'
necessarily tied to a file.
That said, there is a strong clue about where the invalid _content_ lies based
on this message:
{noformat}
Invalid content was found starting with element
'{"urn:activemq:core":connectors}'.{noformat}
Whatever file holds the {{connectors}} content is where I would start the
investigation.
In the mean-time could you let us know what the actual problem was/is. Perhaps
we missed something in the release notes. Thanks!
was (Author: jbertram):
The broker delegates all XML validation as well as basic parsing (including the
["xinclude"
functionality|https://activemq.apache.org/components/artemis/documentation/latest/configuration-index.html#modularising-brokerxml]))
to the JVM. Therefore, if the validation of {{broker.xml}} fails (as it does
in this case) the broker doesn't necessarily know which file the invalid
configuration might be in. As you may have noticed, the exception is coming
from:
{noformat}
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException{noformat}
The broker doesn't control this code. It's coming from whatever JVM you're
running. You may be able to get this behavior changed by filing a bug report
with your JVM/JDK vendor, although it's worth noting that the input isnt'
necessarily tied to a file.
That said, there is a strong clue about where the invalid _content_ lies based
on this message:
{noformat}
Invalid content was found starting with element
'{"urn:activemq:core":connectors}'.{noformat}
Whatever file holds the {{connectors}} content is where I would start the
investigation.
In the mean-time could you let us know what the actual problem was/is. Perhaps
we missed something in the release notes. Thanks!
> "AMQ214019: Invalid configuration" should provide clear information about
> file and maybe line number
>
>
> Key: ARTEMIS-4414
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4414
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: arne anka
>Priority: Minor
>
> Figured out the basic issue. Remains the ... limited information in the log.
> The error does NOWHERE mention what config file actually causes the error.
> That renders the error message mostly pointless and makes fixing
> unnecessarily difficult:
> {code:java}
> 2023-09-01 14:15:35,485 ERROR [org.apache.activemq.artemis.core.client]
> AMQ214019: Invalid configuration
> org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was
> found starting with element '{"urn:activemq:core":connectors}'. One of
> '{"urn:activemq:core":system-property-prefix,
> "urn:activemq:core":internal-naming-prefix,
> "urn:activemq:core":amqp-use-core-subscription-naming,
> "urn:activemq:core":resolve-protocols,
> "urn:activemq:core":graceful-shutdown-enabled,
> "urn:activemq:core":graceful-shutdown-timeout,"urn:activemq:core":security-enabled,
> "urn:activemq:core":security-invalidation-interval,
> "urn:activemq:core":authentication-cache-size,
> "urn:activemq:core":authorization-cache-size,
> "urn:activemq:core":journal-lock-acquisition-timeout,
> "urn:activemq:core":wild-card-routing-enabled,
> "urn:activemq:core":management-address,
> "urn:activemq:core":management-notification-address,
> "urn:activemq:core":cluster-user, "urn:activemq:core":cluster-password,
> "urn:activemq:core":password-codec, "urn:activemq:core":mask-password,
> "urn:activemq:core":log-delegate-factory-class-name,
> "urn:activemq:core":jmx-management-enabled, "urn:activemq:core":jmx-domain,
> "urn:activemq:core":jmx-use-broker-name,
> "urn:activemq:core":message-counter-enabled,
> "urn:activemq:core":message-counter-sample-period,
>
[jira] [Comment Edited] (ARTEMIS-4414) "AMQ214019: Invalid configuration" should provide clear information about file and maybe line number
[
https://issues.apache.org/jira/browse/ARTEMIS-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761315#comment-17761315
]
Justin Bertram edited comment on ARTEMIS-4414 at 9/1/23 1:39 PM:
-
The broker delegates all XML validation as well as basic parsing (including the
["xinclude"
functionality|https://activemq.apache.org/components/artemis/documentation/latest/configuration-index.html#modularising-brokerxml]))
to the JVM. Therefore, if the validation of {{broker.xml}} fails (as it does
in this case) the broker doesn't necessarily know which file the invalid
configuration might be in. As you may have noticed, the exception is coming
from:
{noformat}
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException{noformat}
The broker doesn't control this code. It's coming from whatever JVM you're
running. You may be able to get this behavior changed by filing a bug report
with your JVM/JDK vendor, although it's worth noting that the input isnt'
necessarily tied to a file.
That said, there is a strong clue about where the invalid _content_ lies based
on this message:
{noformat}
Invalid content was found starting with element
'{"urn:activemq:core":connectors}'.{noformat}
Whatever file holds the {{connectors}} content is where I would start the
investigation.
In the mean-time could you let us know what the actual problem was/is. Perhaps
we missed something in the release notes. Thanks!
was (Author: jbertram):
The broker delegates all XML validation as well as the ["xinclude"
functionality|https://activemq.apache.org/components/artemis/documentation/latest/configuration-index.html#modularising-brokerxml])
to the JVM. Therefore, if the validation of {{broker.xml}} fails (as it does
in this case) the broker doesn't necessarily know which file the invalid
configuration might be in. As you may have noticed, the exception is coming
from:
{noformat}
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException{noformat}
The broker doesn't control this code. It's coming from whatever JVM you're
running. You may be able to get this behavior changed by filing a bug report
with your JVM/JDK vendor, although it's worth noting that the input isnt'
necessarily tied to a file.
That said, there is a strong clue about where the invalid _content_ lies based
on this message:
{noformat}
Invalid content was found starting with element
'{"urn:activemq:core":connectors}'.{noformat}
Whatever file holds the {{connectors}} content is where I would start the
investigation.
In the mean-time could you let us know what the actual problem was/is. Perhaps
we missed something in the release notes. Thanks!
> "AMQ214019: Invalid configuration" should provide clear information about
> file and maybe line number
>
>
> Key: ARTEMIS-4414
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4414
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: arne anka
>Priority: Minor
>
> Figured out the basic issue. Remains the ... limited information in the log.
> The error does NOWHERE mention what config file actually causes the error.
> That renders the error message mostly pointless and makes fixing
> unnecessarily difficult:
> {code:java}
> 2023-09-01 14:15:35,485 ERROR [org.apache.activemq.artemis.core.client]
> AMQ214019: Invalid configuration
> org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was
> found starting with element '{"urn:activemq:core":connectors}'. One of
> '{"urn:activemq:core":system-property-prefix,
> "urn:activemq:core":internal-naming-prefix,
> "urn:activemq:core":amqp-use-core-subscription-naming,
> "urn:activemq:core":resolve-protocols,
> "urn:activemq:core":graceful-shutdown-enabled,
> "urn:activemq:core":graceful-shutdown-timeout,"urn:activemq:core":security-enabled,
> "urn:activemq:core":security-invalidation-interval,
> "urn:activemq:core":authentication-cache-size,
> "urn:activemq:core":authorization-cache-size,
> "urn:activemq:core":journal-lock-acquisition-timeout,
> "urn:activemq:core":wild-card-routing-enabled,
> "urn:activemq:core":management-address,
> "urn:activemq:core":management-notification-address,
> "urn:activemq:core":cluster-user, "urn:activemq:core":cluster-password,
> "urn:activemq:core":password-codec, "urn:activemq:core":mask-password,
> "urn:activemq:core":log-delegate-factory-class-name,
> "urn:activemq:core":jmx-management-enabled, "urn:activemq:core":jmx-domain,
> "urn:activemq:core":jmx-use-broker-name,
> "urn:activemq:core":message-counter-enabled,
> "urn:activemq:core":message-counter-sample-period,
> "urn:activemq:core":message-counter-max-day-history,
>
[jira] [Commented] (ARTEMIS-4414) "AMQ214019: Invalid configuration" should provide clear information about file and maybe line number
[
https://issues.apache.org/jira/browse/ARTEMIS-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761315#comment-17761315
]
Justin Bertram commented on ARTEMIS-4414:
-
The broker delegates all XML validation as well as the ["xinclude"
functionality|https://activemq.apache.org/components/artemis/documentation/latest/configuration-index.html#modularising-brokerxml])
to the JVM. Therefore, if the validation of {{broker.xml}} fails (as it does
in this case) the broker doesn't necessarily know which file the invalid
configuration might be in. As you may have noticed, the exception is coming
from:
{noformat}
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException{noformat}
The broker doesn't control this code. It's coming from whatever JVM you're
running. You may be able to get this behavior changed by filing a bug report
with your JVM/JDK vendor, although it's worth noting that the input isnt'
necessarily tied to a file.
That said, there is a strong clue about where the invalid _content_ lies based
on this message:
{noformat}
Invalid content was found starting with element
'{"urn:activemq:core":connectors}'.{noformat}
Whatever file holds the {{connectors}} content is where I would start the
investigation.
In the mean-time could you let us know what the actual problem was/is. Perhaps
we missed something in the release notes. Thanks!
> "AMQ214019: Invalid configuration" should provide clear information about
> file and maybe line number
>
>
> Key: ARTEMIS-4414
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4414
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: arne anka
>Priority: Minor
>
> Figured out the basic issue. Remains the ... limited information in the log.
> The error does NOWHERE mention what config file actually causes the error.
> That renders the error message mostly pointless and makes fixing
> unnecessarily difficult:
> {code:java}
> 2023-09-01 14:15:35,485 ERROR [org.apache.activemq.artemis.core.client]
> AMQ214019: Invalid configuration
> org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was
> found starting with element '{"urn:activemq:core":connectors}'. One of
> '{"urn:activemq:core":system-property-prefix,
> "urn:activemq:core":internal-naming-prefix,
> "urn:activemq:core":amqp-use-core-subscription-naming,
> "urn:activemq:core":resolve-protocols,
> "urn:activemq:core":graceful-shutdown-enabled,
> "urn:activemq:core":graceful-shutdown-timeout,"urn:activemq:core":security-enabled,
> "urn:activemq:core":security-invalidation-interval,
> "urn:activemq:core":authentication-cache-size,
> "urn:activemq:core":authorization-cache-size,
> "urn:activemq:core":journal-lock-acquisition-timeout,
> "urn:activemq:core":wild-card-routing-enabled,
> "urn:activemq:core":management-address,
> "urn:activemq:core":management-notification-address,
> "urn:activemq:core":cluster-user, "urn:activemq:core":cluster-password,
> "urn:activemq:core":password-codec, "urn:activemq:core":mask-password,
> "urn:activemq:core":log-delegate-factory-class-name,
> "urn:activemq:core":jmx-management-enabled, "urn:activemq:core":jmx-domain,
> "urn:activemq:core":jmx-use-broker-name,
> "urn:activemq:core":message-counter-enabled,
> "urn:activemq:core":message-counter-sample-period,
> "urn:activemq:core":message-counter-max-day-history,
> "urn:activemq:core":connection-ttl-override,
> "urn:activemq:core":connection-ttl-check-interval,
> "urn:activemq:core":configuration-file-refresh-period,
> "urn:activemq:core":temporary-queue-namespace,
> "urn:activemq:core":async-connection-execution-enabled,
> "urn:activemq:core":transaction-timeout,
> "urn:activemq:core":transaction-timeout-scan-period,
> "urn:activemq:core":message-expiry-scan-period,
> "urn:activemq:core":message-expiry-thread-priority,
> "urn:activemq:core":address-queue-scan-period,
> "urn:activemq:core":id-cache-size, "urn:activemq:core":persist-id-cache,
> "urn:activemq:core":remoting-incoming-interceptors,
> "urn:activemq:core":remoting-outgoing-interceptors,
> "urn:activemq:core":persist-delivery-count-before-delivery,
> "urn:activemq:core":max-redelivery-records,
> "urn:activemq:core":populate-validated-user,
> "urn:activemq:core":reject-empty-validated-user,
> "urn:activemq:core":mqtt-session-scan-interval,
> "urn:activemq:core":broadcast-groups,
> "urn:activemq:core":discovery-groups,"urn:activemq:core":diverts,
> "urn:activemq:core":queues, "urn:activemq:core":bridges,
> "urn:activemq:core":federations, "urn:activemq:core":ha-policy,
> "urn:activemq:core":cluster-connections,
> "urn:activemq:core":broker-connections,
> "urn:activemq:core":connection-routers,
[jira] [Updated] (ARTEMIS-4414) "AMQ214019: Invalid configuration" should provide clear information about file and maybe line number
[
https://issues.apache.org/jira/browse/ARTEMIS-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
arne anka updated ARTEMIS-4414:
---
Description:
Figured out the basic issue. Remains the ... limited information in the log.
The error does NOWHERE mention what config file actually causes the error.
That renders the error message mostly pointless and makes fixing unnecessarily
difficult:
{code:java}
2023-09-01 14:15:35,485 ERROR [org.apache.activemq.artemis.core.client]
AMQ214019: Invalid configuration
org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was
found starting with element '{"urn:activemq:core":connectors}'. One of
'{"urn:activemq:core":system-property-prefix,
"urn:activemq:core":internal-naming-prefix,
"urn:activemq:core":amqp-use-core-subscription-naming,
"urn:activemq:core":resolve-protocols,
"urn:activemq:core":graceful-shutdown-enabled,
"urn:activemq:core":graceful-shutdown-timeout,"urn:activemq:core":security-enabled,
"urn:activemq:core":security-invalidation-interval,
"urn:activemq:core":authentication-cache-size,
"urn:activemq:core":authorization-cache-size,
"urn:activemq:core":journal-lock-acquisition-timeout,
"urn:activemq:core":wild-card-routing-enabled,
"urn:activemq:core":management-address,
"urn:activemq:core":management-notification-address,
"urn:activemq:core":cluster-user, "urn:activemq:core":cluster-password,
"urn:activemq:core":password-codec, "urn:activemq:core":mask-password,
"urn:activemq:core":log-delegate-factory-class-name,
"urn:activemq:core":jmx-management-enabled, "urn:activemq:core":jmx-domain,
"urn:activemq:core":jmx-use-broker-name,
"urn:activemq:core":message-counter-enabled,
"urn:activemq:core":message-counter-sample-period,
"urn:activemq:core":message-counter-max-day-history,
"urn:activemq:core":connection-ttl-override,
"urn:activemq:core":connection-ttl-check-interval,
"urn:activemq:core":configuration-file-refresh-period,
"urn:activemq:core":temporary-queue-namespace,
"urn:activemq:core":async-connection-execution-enabled,
"urn:activemq:core":transaction-timeout,
"urn:activemq:core":transaction-timeout-scan-period,
"urn:activemq:core":message-expiry-scan-period,
"urn:activemq:core":message-expiry-thread-priority,
"urn:activemq:core":address-queue-scan-period,
"urn:activemq:core":id-cache-size, "urn:activemq:core":persist-id-cache,
"urn:activemq:core":remoting-incoming-interceptors,
"urn:activemq:core":remoting-outgoing-interceptors,
"urn:activemq:core":persist-delivery-count-before-delivery,
"urn:activemq:core":max-redelivery-records,
"urn:activemq:core":populate-validated-user,
"urn:activemq:core":reject-empty-validated-user,
"urn:activemq:core":mqtt-session-scan-interval,
"urn:activemq:core":broadcast-groups,
"urn:activemq:core":discovery-groups,"urn:activemq:core":diverts,
"urn:activemq:core":queues, "urn:activemq:core":bridges,
"urn:activemq:core":federations, "urn:activemq:core":ha-policy,
"urn:activemq:core":cluster-connections,
"urn:activemq:core":broker-connections, "urn:activemq:core":connection-routers,
"urn:activemq:core":grouping-handler, "urn:activemq:core":create-bindings-dir,
"urn:activemq:core":page-max-concurrent-io,
"urn:activemq:core":read-whole-page,
"urn:activemq:core":journal-retention-directory,
"urn:activemq:core":node-manager-lock-directory,
"urn:activemq:core":create-journal-dir,
"urn:activemq:core":journal-buffer-size,
"urn:activemq:core":journal-sync-transactional,
"urn:activemq:core":journal-sync-non-transactional,
"urn:activemq:core":log-journal-write-rate,
"urn:activemq:core":journal-compact-percentage,
"urn:activemq:core":journal-compact-min-files,
"urn:activemq:core":journal-file-open-timeout,
"urn:activemq:core":server-dump-interval, "urn:activemq:core":global-max-size,
"urn:activemq:core":memory-warning-threshold,
"urn:activemq:core":memory-measure-interval, "urn:activemq:core":store,
"urn:activemq:core":suppress-session-notifications,
"urn:activemq:core":broker-plugins, "urn:activemq:core":metrics-plugin,
"urn:activemq:core":metrics, "urn:activemq:core":resource-limit-settings,
"urn:activemq:core":connector-services, "urn:activemq:core":network-check-list,
"urn:activemq:core":network-check-URL-list,
"urn:activemq:core":network-check-period,
"urn:activemq:core":network-check-timeout,
"urn:activemq:core":network-check-NIC,
"urn:activemq:core":network-check-ping-command,
"urn:activemq:core":network-check-ping6-command}' is expected.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204)
~[?:?]
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
~[?:?]
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
~[?:?]
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
[jira] [Created] (ARTEMIS-4414) After update 2.29.0 to 2.30.0: "AMQ214019: Invalid configuration" but no info in what file
arne anka created ARTEMIS-4414:
--
Summary: After update 2.29.0 to 2.30.0: "AMQ214019: Invalid
configuration" but no info in what file
Key: ARTEMIS-4414
URL: https://issues.apache.org/jira/browse/ARTEMIS-4414
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 2.30.0
Reporter: arne anka
I've split the runtime and configuration in two separate folders and thus only
need to unpack the relaesed TAR, replace the previous one and restart Artemis.
That works very well and is just to make clear that there's no chance, a
configuration was modified during upgrade!
Since neither the release notes nor the documentation mention any configuration
changes from 2.29.0 to 2.30.0 I did the same as usual, but after restart the
log is full of the error message below.
What's even worse – the error does NOWHERE mention what config file actually
causes the error.
That renders the error message mostly pointless nad makes fixing unnecessarily
difficult:
{code:java}
2023-09-01 14:15:35,485 ERROR [org.apache.activemq.artemis.core.client]
AMQ214019: Invalid configuration
org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was
found starting with element '{"urn:activemq:core":connectors}'. One of
'{"urn:activemq:core":system-property-prefix,
"urn:activemq:core":internal-naming-prefix,
"urn:activemq:core":amqp-use-core-subscription-naming,
"urn:activemq:core":resolve-protocols,
"urn:activemq:core":graceful-shutdown-enabled,
"urn:activemq:core":graceful-shutdown-timeout,"urn:activemq:core":security-enabled,
"urn:activemq:core":security-invalidation-interval,
"urn:activemq:core":authentication-cache-size,
"urn:activemq:core":authorization-cache-size,
"urn:activemq:core":journal-lock-acquisition-timeout,
"urn:activemq:core":wild-card-routing-enabled,
"urn:activemq:core":management-address,
"urn:activemq:core":management-notification-address,
"urn:activemq:core":cluster-user, "urn:activemq:core":cluster-password,
"urn:activemq:core":password-codec, "urn:activemq:core":mask-password,
"urn:activemq:core":log-delegate-factory-class-name,
"urn:activemq:core":jmx-management-enabled, "urn:activemq:core":jmx-domain,
"urn:activemq:core":jmx-use-broker-name,
"urn:activemq:core":message-counter-enabled,
"urn:activemq:core":message-counter-sample-period,
"urn:activemq:core":message-counter-max-day-history,
"urn:activemq:core":connection-ttl-override,
"urn:activemq:core":connection-ttl-check-interval,
"urn:activemq:core":configuration-file-refresh-period,
"urn:activemq:core":temporary-queue-namespace,
"urn:activemq:core":async-connection-execution-enabled,
"urn:activemq:core":transaction-timeout,
"urn:activemq:core":transaction-timeout-scan-period,
"urn:activemq:core":message-expiry-scan-period,
"urn:activemq:core":message-expiry-thread-priority,
"urn:activemq:core":address-queue-scan-period,
"urn:activemq:core":id-cache-size, "urn:activemq:core":persist-id-cache,
"urn:activemq:core":remoting-incoming-interceptors,
"urn:activemq:core":remoting-outgoing-interceptors,
"urn:activemq:core":persist-delivery-count-before-delivery,
"urn:activemq:core":max-redelivery-records,
"urn:activemq:core":populate-validated-user,
"urn:activemq:core":reject-empty-validated-user,
"urn:activemq:core":mqtt-session-scan-interval,
"urn:activemq:core":broadcast-groups,
"urn:activemq:core":discovery-groups,"urn:activemq:core":diverts,
"urn:activemq:core":queues, "urn:activemq:core":bridges,
"urn:activemq:core":federations, "urn:activemq:core":ha-policy,
"urn:activemq:core":cluster-connections,
"urn:activemq:core":broker-connections, "urn:activemq:core":connection-routers,
"urn:activemq:core":grouping-handler, "urn:activemq:core":create-bindings-dir,
"urn:activemq:core":page-max-concurrent-io,
"urn:activemq:core":read-whole-page,
"urn:activemq:core":journal-retention-directory,
"urn:activemq:core":node-manager-lock-directory,
"urn:activemq:core":create-journal-dir,
"urn:activemq:core":journal-buffer-size,
"urn:activemq:core":journal-sync-transactional,
"urn:activemq:core":journal-sync-non-transactional,
"urn:activemq:core":log-journal-write-rate,
"urn:activemq:core":journal-compact-percentage,
"urn:activemq:core":journal-compact-min-files,
"urn:activemq:core":journal-file-open-timeout,
"urn:activemq:core":server-dump-interval, "urn:activemq:core":global-max-size,
"urn:activemq:core":memory-warning-threshold,
"urn:activemq:core":memory-measure-interval, "urn:activemq:core":store,
"urn:activemq:core":suppress-session-notifications,
"urn:activemq:core":broker-plugins, "urn:activemq:core":metrics-plugin,
"urn:activemq:core":metrics, "urn:activemq:core":resource-limit-settings,
"urn:activemq:core":connector-services, "urn:activemq:core":network-check-list,
"urn:activemq:core":network-check-URL-list,
"urn:activemq:core":network-check-period,
[jira] [Resolved] (ARTEMIS-4410) Openwire prefetched messages can be out of order after failover to an exclusive queue
[ https://issues.apache.org/jira/browse/ARTEMIS-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4410. - Resolution: Fixed > Openwire prefetched messages can be out of order after failover to an > exclusive queue > - > > Key: ARTEMIS-4410 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4410 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.31.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > related to ARTEMIS-4284 but when the connection drops, and the client > reconnects. Any inflight messages can be addSorted to the queue, but any new > consumer on a newly created connection can see the queue without certainty > that prefetched are added back. > with an exclusive queue, the order should be preserved for each successive > exclusive consumer. > The default prefetch means this is typical with openwire, but the visibility > of delivered messages is not unique to that protocol. With any unacked > messages that exceed credit this can occur in the event of unclean disconnect > and reconnect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4410) Openwire prefetched messages can be out of order after failover to an exclusive queue
[ https://issues.apache.org/jira/browse/ARTEMIS-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761289#comment-17761289 ] ASF subversion and git services commented on ARTEMIS-4410: -- Commit b11945e0c7376db01f25aaf1b61934bda95cb80e in activemq-artemis's branch refs/heads/main from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=b11945e0c7 ] ARTEMIS-4410 - process deliveries before removing consumer on session close, ensure strict order for a single consumer > Openwire prefetched messages can be out of order after failover to an > exclusive queue > - > > Key: ARTEMIS-4410 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4410 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.31.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > related to ARTEMIS-4284 but when the connection drops, and the client > reconnects. Any inflight messages can be addSorted to the queue, but any new > consumer on a newly created connection can see the queue without certainty > that prefetched are added back. > with an exclusive queue, the order should be preserved for each successive > exclusive consumer. > The default prefetch means this is typical with openwire, but the visibility > of delivered messages is not unique to that protocol. With any unacked > messages that exceed credit this can occur in the event of unclean disconnect > and reconnect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
