[jira] [Resolved] (ARTEMIS-4742) Decoding PersistedSecuritySetting fails after upgrade
[
https://issues.apache.org/jira/browse/ARTEMIS-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved ARTEMIS-4742.
-
Fix Version/s: 2.34.0
Resolution: Fixed
> Decoding PersistedSecuritySetting fails after upgrade
> -
>
> Key: ARTEMIS-4742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4742
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.34.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have faced problem when upgrading one of ActiveMQ Artemis servers from
> 2.32.0 to 2.33.0.
> Artemis cannot start and writes an error to the log:
> {noformat}
> 2024-04-18 13:31:44,975 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224000: Failure in initialisation
> java.lang.IndexOutOfBoundsException: readerIndex(82) + length(1) exceeds
> writerIndex(82): UnpooledHeapByteBuf(ridx: 82, widx: 82, cap: 82/82)
> at
> io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1442)
> ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:730)
> ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at io.netty.buffer.WrappedByteBuf.readByte(WrappedByteBuf.java:529)
> ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at
> org.apache.activemq.artemis.api.core.SimpleString.readNullableSimpleString(SimpleString.java:150)
> ~[artemis-commons-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:79)
> ~[artemis-commons-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.persistence.config.PersistedSecuritySetting.decode(PersistedSecuritySetting.java:255)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.newSecurityRecord(AbstractJournalStorageManager.java:2127)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.lambda$loadBindingJournal$5(AbstractJournalStorageManager.java:1640)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList$SparseArray.clear(SparseArrayLinkedList.java:114)
> ~[artemis-commons-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList.clearSparseArrayList(SparseArrayLinkedList.java:173)
> ~[artemis-commons-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList.clear(SparseArrayLinkedList.java:227)
> ~[artemis-commons-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadBindingJournal(AbstractJournalStorageManager.java:1613)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:3856)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3489)
> ~[artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.server.impl.ReplicationPrimaryActivation.run(ReplicationPrimaryActivation.java:145)
> [artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:738)
> [artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:628)
> [artemis-server-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66)
> [artemis-cli-2.33.0.jar:2.33.0]
> at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:130)
> [artemis-cli-2.33.0.jar:2.33.0]
> at
> org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:221)
> [artemis-cli-2.33.0.jar:2.33.0]
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:167)
> [artemis-cli-2.33.0.jar:2.33.0]
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[?:?]
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> ~[?:?]
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?]
> at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
> at
[jira] [Resolved] (ARTEMIS-4709) Add a plugin to provide periodic expiry of connections on a per acceptor basis
[ https://issues.apache.org/jira/browse/ARTEMIS-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4709. - Resolution: Fixed > Add a plugin to provide periodic expiry of connections on a per acceptor basis > -- > > Key: ARTEMIS-4709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4709 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.34.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > When credential rotation needs to be enforced, active connections need to be > terminated on some timeline to ensure credentials are reevaluated. There are > management apis that can be used but these require some intervention. > In addition to enforce some SLA around duration of connections, having an > easy way to limit connections to a given maximum period can be helpful. > A plugin that will be applied on an per acceptor basis, that can be used to > disconnect connections that have lived for some period can provide a nice > building block for these use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4528) TLS support PEM format for key and trust store type
[ https://issues.apache.org/jira/browse/ARTEMIS-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837168#comment-17837168 ] Gary Tully commented on ARTEMIS-4528: - ARTEMIS-4710 makes the bc dependency optional > TLS support PEM format for key and trust store type > --- > > Key: ARTEMIS-4528 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4528 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > Time Spent: 4.5h > Remaining Estimate: 0h > > managing key and trust store passwords when the credentials are securely > stored or managed by other means is a nuisance. > there is a nice PEM keystore provider at: > [https://github.com/ctron/pem-keystore] > This gives us an intuitive way to easily reference a simple cert or key > without a password as is the case with jsk or pkcs12 > name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.pem;keyStoreType=PEM > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-1968) Kerberos authentication/authorization support for STOMP and Openwire transports
[ https://issues.apache.org/jira/browse/ARTEMIS-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully closed ARTEMIS-1968. --- Resolution: Won't Do The amqp kerberos support sits under SASL, I don' see us adding SASL to STOMP or Openwire for this use case. Things like JWT tokens can already be provided over mtls in the password field for all transports/protocols and that is a viable path forward to externalise auth and have simple expiry/rotations. An alternative is plain mtls for identity with JAAS cert login nodule. > Kerberos authentication/authorization support for STOMP and Openwire > transports > --- > > Key: ARTEMIS-1968 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1968 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: OpenWire, STOMP >Affects Versions: 2.6.2 >Reporter: Abhi >Priority: Major > > I am looking to setup Artemis for my use-cases that are currently using > ActiveMQ v5.14.1 and want to use Kerberos auth which isn't available in > ActiveMQ currently. In Artemis, currently only AMQP transport supports > Kerberos auth. > Please add Kerberos auth to STOMP and Openwire. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4528) TLS support PEM format for key and trust store type
[ https://issues.apache.org/jira/browse/ARTEMIS-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837141#comment-17837141 ] Gary Tully commented on ARTEMIS-4528: - I don't know if there is a better alternative, or a smaller subset of bc that will satisfy the need. The subsequent change to remove the direct reference means that the static dependency is not longer required, if will only be resolved at runtime at first use. see: https://github.com/apache/activemq-artemis/commit/bf1ea4128775c97e6c6fc6a0ab6921feaf8197d5 that helps, but I am not aware of an alternative to bc. > TLS support PEM format for key and trust store type > --- > > Key: ARTEMIS-4528 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4528 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > Time Spent: 4.5h > Remaining Estimate: 0h > > managing key and trust store passwords when the credentials are securely > stored or managed by other means is a nuisance. > there is a nice PEM keystore provider at: > [https://github.com/ctron/pem-keystore] > This gives us an intuitive way to easily reference a simple cert or key > without a password as is the case with jsk or pkcs12 > name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.pem;keyStoreType=PEM > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4709) Add a plugin to provide periodic expiry of connections on a per acceptor basis
Gary Tully created ARTEMIS-4709: --- Summary: Add a plugin to provide periodic expiry of connections on a per acceptor basis Key: ARTEMIS-4709 URL: https://issues.apache.org/jira/browse/ARTEMIS-4709 Project: ActiveMQ Artemis Issue Type: New Feature Components: Broker Affects Versions: 2.33.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.34.0 When credential rotation needs to be enforced, active connections need to be terminated on some timeline to ensure credentials are reevaluated. There are management apis that can be used but these require some intervention. In addition to enforce some SLA around duration of connections, having an easy way to limit connections to a given maximum period can be helpful. A plugin that will be applied on an per acceptor basis, that can be used to disconnect connections that have lived for some period can provide a nice building block for these use cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4699) properties config - implied factoryClassName on TransportConfiguration can be wrong, it needs to be provided via a property value
[ https://issues.apache.org/jira/browse/ARTEMIS-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4699. - Resolution: Fixed > properties config - implied factoryClassName on TransportConfiguration can be > wrong, it needs to be provided via a property value > - > > Key: ARTEMIS-4699 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4699 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > > There is an incorrect setting of the factoryClassName for a transport > configuration. When initialised from a uri this is broken as the value is > already set and when used for acceptors it is plain wrong. > this default or implicit setting does not know the correct context, it should > be removed in favour of having it provided via the factoryClassName property > value -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4699) properties config - implied factoryClassName on TransportConfiguration can be wrong, it needs to be provided via a property value
Gary Tully created ARTEMIS-4699: --- Summary: properties config - implied factoryClassName on TransportConfiguration can be wrong, it needs to be provided via a property value Key: ARTEMIS-4699 URL: https://issues.apache.org/jira/browse/ARTEMIS-4699 Project: ActiveMQ Artemis Issue Type: Bug Components: Configuration Affects Versions: 2.33.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.34.0 There is an incorrect setting of the factoryClassName for a transport configuration. When initialised from a uri this is broken as the value is already set and when used for acceptors it is plain wrong. this default or implicit setting does not know the correct context, it should be removed in favour of having it provided via the factoryClassName property value -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4582) add view and edit permissions to extend security-settings rbac for management operations
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4582. - Fix Version/s: 2.33.0 Resolution: Fixed > add view and edit permissions to extend security-settings rbac for management > operations > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.33.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > we have the manage permission that allows sending to the management address, > to access any control resource. We don't however distinguish what a user can > do. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set or operations that mutate or modify. > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-4582) add view and edit permissions to extend security-settings rbac for management operations
[ https://issues.apache.org/jira/browse/ARTEMIS-4582 ] Gary Tully deleted comment on ARTEMIS-4582: - was (Author: gtully): The control resources are registered using prefixes, such that they are available for dynamic invocation, something like sever control is registered under "broker" using the management address as the root, permissions on activemq.management.control.broker would be used to configure permissions on the servercontrol etc. Where operations are on queuecontrol the actual queue name would be part of the key. > add view and edit permissions to extend security-settings rbac for management > operations > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 4h 20m > Remaining Estimate: 0h > > we have the manage permission that allows sending to the management address, > to access any control resource. We don't however distinguish what a user can > do. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set or operations that mutate or modify. > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4582) add view and edit permissions to extend security-settings rbac for management operations
[
https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810455#comment-17810455
]
Gary Tully edited comment on ARTEMIS-4582 at 3/14/24 8:33 PM:
--
existing permissions:
[https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses]
something like:
{{
}}
was (Author: gtully):
existing permissions:
[https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses]
something like:
{{
}}
> add view and edit permissions to extend security-settings rbac for management
> operations
>
>
> Key: ARTEMIS-4582
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4582
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration, JMX, Web Console
>Affects Versions: 2.31.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> we have the manage permission that allows sending to the management address,
> to access any control resource. We don't however distinguish what a user can
> do.
> We should segment control operations into categories: CRUD provides a basis
> view for get/is (Read)
> edit for set or operations that mutate or modify.
> We allow this sort of configuration via management.xml for jmx mbean access
> but using a different model based on object name.
> All of the mbeans delegate to the control resources.
> If we add these two additional permissions then we can have a single rbac
> model (that supports config reload) and more granularity on control resource
> access from the management address.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4582) add view and edit permissions to extend security-settings rbac for management operations
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4582: Description: we have the manage permission that allows sending to the management address, to access any control resource. We don't however distinguish what a user can do. We should segment control operations into categories: CRUD provides a basis view for get/is (Read) edit for set or operations that mutate or modify. We allow this sort of configuration via management.xml for jmx mbean access but using a different model based on object name. All of the mbeans delegate to the control resources. If we add these two additional permissions then we can have a single rbac model (that supports config reload) and more granularity on control resource access from the management address. was: we have the manage permission that allows sending to the management address, to access any control resource. We don't however distinguish what a user can do. We should segment control operations into categories: CRUD provides a basis view for get/is (Read) update for set or operations that mutate or modify. We allow this sort of configuration via management.xml for jmx mbean access but using a different model based on object name. All of the mbeans delegate to the control resources. If we add these two additional permissions then we can have a single rbac model (that supports config reload) and more granularity on control resource access from the management address. > add view and edit permissions to extend security-settings rbac for management > operations > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 4h 20m > Remaining Estimate: 0h > > we have the manage permission that allows sending to the management address, > to access any control resource. We don't however distinguish what a user can > do. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set or operations that mutate or modify. > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4582) add view and edit permissions to extend security-settings rbac for management operations
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4582: Summary: add view and edit permissions to extend security-settings rbac for management operations (was: add view and update permissions to augment the manage rbac for control resources) > add view and edit permissions to extend security-settings rbac for management > operations > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 4h 20m > Remaining Estimate: 0h > > we have the manage permission that allows sending to the management address, > to access any control resource. We don't however distinguish what a user can > do. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > update for set or operations that mutate or modify. > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4582) add view and update permissions to augment the manage rbac for control resources
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully reassigned ARTEMIS-4582: --- Assignee: Gary Tully > add view and update permissions to augment the manage rbac for control > resources > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > we have the manage permission that allows sending to the management address, > to access any control resource. We don't however distinguish what a user can > do. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > update for set or operations that mutate or modify. > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4582) add view and update permissions to augment the manage rbac for control resources
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4582: Description: we have the manage permission that allows sending to the management address, to access any control resource. We don't however distinguish what a user can do. We should segment control operations into categories: CRUD provides a basis view for get/is (Read) update for set or operations that mutate or modify. We allow this sort of configuration via management.xml for jmx mbean access but using a different model based on object name. All of the mbeans delegate to the control resources. If we add these two additional permissions then we can have a single rbac model (that supports config reload) and more granularity on control resource access from the management address. was: we have the manage permission that allows sending to the management address, to access any control resource. We should segment control operations into categories: CRUD provides a basis view for get/is (Read) edit for set (Update) manage for aggregate operations list* and Create, Delete) also implying both view & edit We allow this sort of configuration via management.xml for jmx mbean access but using a different model based on object name. All of the mbeans delegate to the control resources. If we add these two additional permissions then we can have a single rbac model (that supports config reload) and more granularity on control resource access from the management address. > add view and update permissions to augment the manage rbac for control > resources > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Priority: Major > > we have the manage permission that allows sending to the management address, > to access any control resource. We don't however distinguish what a user can > do. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > update for set or operations that mutate or modify. > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4582) add view and update permissions to augment the manage rbac for control resources
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4582: Summary: add view and update permissions to augment the manage rbac for control resources (was: add read and update permissions to augment the manage rbac for control resources) > add view and update permissions to augment the manage rbac for control > resources > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Priority: Major > > we have the manage permission that allows sending to the management address, > to access any control resource. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set (Update) > manage for aggregate operations list* and Create, Delete) also implying both > view & edit > > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4582) add read and update permissions to augment the manage rbac for control resources
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810460#comment-17810460 ] Gary Tully edited comment on ARTEMIS-4582 at 1/31/24 11:10 AM: --- The control resources are registered using prefixes, such that they are available for dynamic invocation, something like sever control is registered under "broker" using the management address as the root, permissions on activemq.management.control.broker would be used to configure permissions on the servercontrol etc. Where operations are on queuecontrol the actual queue name would be part of the key. was (Author: gtully): The control resources are registered using prefixes, such that they are available for dynamic invocation, something like sever control is registered under "broker" using the management address as the root, permissions on management.broker would be used to configure permissions on the servercontroll etc. Where operations are on queuecontroll the actual queue would be used. > add read and update permissions to augment the manage rbac for control > resources > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Priority: Major > > we have the manage permission that allows sending to the management address, > to access any control resource. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set (Update) > manage for aggregate operations list* and Create, Delete) also implying both > view & edit > > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4582) add read and update permissions to augment the manage rbac for control resources
[
https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810455#comment-17810455
]
Gary Tully edited comment on ARTEMIS-4582 at 1/31/24 11:08 AM:
---
existing permissions:
[https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses]
something like:
{{
}}
was (Author: gtully):
existing permissions:
[https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses]
something like:
{{
}}
> add read and update permissions to augment the manage rbac for control
> resources
>
>
> Key: ARTEMIS-4582
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4582
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration, JMX, Web Console
>Affects Versions: 2.31.0
>Reporter: Gary Tully
>Priority: Major
>
> we have the manage permission that allows sending to the management address,
> to access any control resource.
> We should segment control operations into categories: CRUD provides a basis
> view for get/is (Read)
> edit for set (Update)
> manage for aggregate operations list* and Create, Delete) also implying both
> view & edit
>
> We allow this sort of configuration via management.xml for jmx mbean access
> but using a different model based on object name.
> All of the mbeans delegate to the control resources.
>
> If we add these two additional permissions then we can have a single rbac
> model (that supports config reload) and more granularity on control resource
> access from the management address.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4582) add read and update permissions to augment the manage rbac for control resources
[
https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810455#comment-17810455
]
Gary Tully edited comment on ARTEMIS-4582 at 1/25/24 2:38 PM:
--
existing permissions:
[https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses]
something like:
{{
}}
was (Author: gtully):
existing permissions:
[https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses]
something like:
{{
}}
> add read and update permissions to augment the manage rbac for control
> resources
>
>
> Key: ARTEMIS-4582
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4582
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration, JMX, Web Console
>Affects Versions: 2.31.0
>Reporter: Gary Tully
>Priority: Major
>
> we have the manage permission that allows sending to the management address,
> to access any control resource.
> We should segment control operations into categories: CRUD provides a basis
> view for get/is (Read)
> edit for set (Update)
> manage for aggregate operations list* and Create, Delete) also implying both
> view & edit
>
> We allow this sort of configuration via management.xml for jmx mbean access
> but using a different model based on object name.
> All of the mbeans delegate to the control resources.
>
> If we add these two additional permissions then we can have a single rbac
> model (that supports config reload) and more granularity on control resource
> access from the management address.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4582) add read and update permissions to augment the manage rbac for control resources
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810460#comment-17810460 ] Gary Tully commented on ARTEMIS-4582: - The control resources are registered using prefixes, such that they are available for dynamic invocation, something like sever control is registered under "broker" using the management address as the root, permissions on management.broker would be used to configure permissions on the servercontroll etc. Where operations are on queuecontroll the actual queue would be used. > add read and update permissions to augment the manage rbac for control > resources > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Priority: Major > > we have the manage permission that allows sending to the management address, > to access any control resource. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set (Update) > manage for aggregate operations list* and Create, Delete) also implying both > view & edit > > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4582) add read and update permissions to augment the manage rbac for control resources
[
https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810455#comment-17810455
]
Gary Tully edited comment on ARTEMIS-4582 at 1/24/24 3:25 PM:
--
existing permissions:
[https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses]
something like:
{{
}}
was (Author: gtully):
existing permissions:
[https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses]
something like:
{{
}}
> add read and update permissions to augment the manage rbac for control
> resources
>
>
> Key: ARTEMIS-4582
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4582
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration, JMX, Web Console
>Affects Versions: 2.31.0
>Reporter: Gary Tully
>Priority: Major
>
> we have the manage permission that allows sending to the management address,
> to access any control resource.
> We should segment control operations into categories: CRUD provides a basis
> view for get/is (Read)
> edit for set (Update)
> manage for aggregate operations list* and Create, Delete) also implying both
> view & edit
>
> We allow this sort of configuration via management.xml for jmx mbean access
> but using a different model based on object name.
> All of the mbeans delegate to the control resources.
>
> If we add these two additional permissions then we can have a single rbac
> model (that supports config reload) and more granularity on control resource
> access from the management address.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4582) add read and update permissions to augment the manage rbac for control resources
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4582: Summary: add read and update permissions to augment the manage rbac for control resources (was: add view and edit permissions to augment the manage rbac for control resources) > add read and update permissions to augment the manage rbac for control > resources > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Priority: Major > > we have the manage permission that allows sending to the management address, > to access any control resource. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set (Update) > manage for aggregate operations list* and Create, Delete) also implying both > view & edit > > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4582) add view and edit permissions to augment the manage rbac for control resources
[
https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810455#comment-17810455
]
Gary Tully commented on ARTEMIS-4582:
-
existing permissions:
[https://activemq.apache.org/components/artemis/documentation/latest/security.html#role-based-security-for-addresses]
something like:
{{
}}
> add view and edit permissions to augment the manage rbac for control resources
> --
>
> Key: ARTEMIS-4582
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4582
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration, JMX, Web Console
>Affects Versions: 2.31.0
>Reporter: Gary Tully
>Priority: Major
>
> we have the manage permission that allows sending to the management address,
> to access any control resource.
> We should segment control operations into categories: CRUD provides a basis
> view for get/is (Read)
> edit for set (Update)
> manage for aggregate operations list* and Create, Delete) also implying both
> view & edit
>
> We allow this sort of configuration via management.xml for jmx mbean access
> but using a different model based on object name.
> All of the mbeans delegate to the control resources.
>
> If we add these two additional permissions then we can have a single rbac
> model (that supports config reload) and more granularity on control resource
> access from the management address.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4582) add view and edit permissions to augment the manage rbac for control resources
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4582: Description: we have the manage permission that allows sending to the management address, to access any control resource. We should segment control operations into categories: CRUD provides a basis view for get/is (Read) edit for set (Update) manage for aggregate operations list* and Create, Delete) also implying both view & edit We allow this sort of configuration via management.xml for jmx mbean access but using a different model based on object name. All of the mbeans delegate to the control resources. If we add these two additional permissions then we can have a single rbac model (that supports config reload) and more granularity on control resource access from the management address. was: we have the manage role that allows sending to the management address, to access any control resource. We should segment control operations into categories: CRUD provides a basis view for get/is (Read) edit for set (Update) manage for aggregate operations list* and Create, Delete) also implying both view & edit We allow this sort of configuration via management.xml for jmx mbean access but using a different model based on object name. All of the mbeans delegate to the control resources. If we add these two additional roles then we can have a single rbac model (that supports config reload) and more granularity on control resource access from the management address. > add view and edit permissions to augment the manage rbac for control resources > -- > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Priority: Major > > we have the manage permission that allows sending to the management address, > to access any control resource. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set (Update) > manage for aggregate operations list* and Create, Delete) also implying both > view & edit > > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > > If we add these two additional permissions then we can have a single rbac > model (that supports config reload) and more granularity on control resource > access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4582) add view and edit permissions to augment the manage rbac for control resources
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4582: Summary: add view and edit permissions to augment the manage rbac for control resources (was: add view and edit roles to augment the manage role for control resources) > add view and edit permissions to augment the manage rbac for control resources > -- > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Priority: Major > > we have the manage role that allows sending to the management address, to > access any control resource. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set (Update) > manage for aggregate operations list* and Create, Delete) also implying both > view & edit > > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > > If we add these two additional roles then we can have a single rbac model > (that supports config reload) and more granularity on control resource access > from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4582) add view and edit roles to augment the manage role for control resources
[ https://issues.apache.org/jira/browse/ARTEMIS-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4582: Description: we have the manage role that allows sending to the management address, to access any control resource. We should segment control operations into categories: CRUD provides a basis view for get/is (Read) edit for set (Update) manage for aggregate operations list* and Create, Delete) also implying both view & edit We allow this sort of configuration via management.xml for jmx mbean access but using a different model based on object name. All of the mbeans delegate to the control resources. If we add these two additional roles then we can have a single rbac model (that supports config reload) and more granularity on control resource access from the management address. was: we have the manage role that allows sending the the management address, to access any control resource. We should segment control operations into categories: CRUD provides a basis view for get/is (Read) edit for set (Update) manage for aggregate operations list* and Create, Delete) also implying both view & edit We allow this sort of configuration via management.xml for jmx mbean access but using a different model based on object name. All of the mbeans delegate to the control resources. If we add these two additional roles then we can have a single rbac model (that supports config reload) and more granularity on control resource access from the management address. > add view and edit roles to augment the manage role for control resources > > > Key: ARTEMIS-4582 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, JMX, Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Priority: Major > > we have the manage role that allows sending to the management address, to > access any control resource. > We should segment control operations into categories: CRUD provides a basis > view for get/is (Read) > edit for set (Update) > manage for aggregate operations list* and Create, Delete) also implying both > view & edit > > We allow this sort of configuration via management.xml for jmx mbean access > but using a different model based on object name. > All of the mbeans delegate to the control resources. > > If we add these two additional roles then we can have a single rbac model > (that supports config reload) and more granularity on control resource access > from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4582) add view and edit roles to augment the manage role for control resources
Gary Tully created ARTEMIS-4582: --- Summary: add view and edit roles to augment the manage role for control resources Key: ARTEMIS-4582 URL: https://issues.apache.org/jira/browse/ARTEMIS-4582 Project: ActiveMQ Artemis Issue Type: Improvement Components: Broker, Configuration, JMX, Web Console Affects Versions: 2.31.0 Reporter: Gary Tully we have the manage role that allows sending the the management address, to access any control resource. We should segment control operations into categories: CRUD provides a basis view for get/is (Read) edit for set (Update) manage for aggregate operations list* and Create, Delete) also implying both view & edit We allow this sort of configuration via management.xml for jmx mbean access but using a different model based on object name. All of the mbeans delegate to the control resources. If we add these two additional roles then we can have a single rbac model (that supports config reload) and more granularity on control resource access from the management address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4561) allow key and trust store type to be configured on the web component
[ https://issues.apache.org/jira/browse/ARTEMIS-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4561. - Resolution: Fixed > allow key and trust store type to be configured on the web component > > > Key: ARTEMIS-4561 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4561 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Following on from ARTEMIS-4528 > for the jetty engine configured from the web component, it is currently not > possible to configure the store type and configure the use of PEM. Without > this it is not possible to secure the web console with PEM format credentials -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4561) allow key and trust store type to be configured on the web component
Gary Tully created ARTEMIS-4561: --- Summary: allow key and trust store type to be configured on the web component Key: ARTEMIS-4561 URL: https://issues.apache.org/jira/browse/ARTEMIS-4561 Project: ActiveMQ Artemis Issue Type: Improvement Components: Web Console Affects Versions: 2.31.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.32.0 Following on from ARTEMIS-4528 for the jetty engine configured from the web component, it is currently not possible to configure the store type and configure the use of PEM. Without this it is not possible to secure the web console with PEM format credentials -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4545) Allow node ID to be configured
[ https://issues.apache.org/jira/browse/ARTEMIS-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798943#comment-17798943 ] Gary Tully commented on ARTEMIS-4545: - the peer activation allows the node id to be set, it is named as the correlation id but is actually the node id. see: [https://github.com/apache/activemq-artemis/blob/main/tests/smoke-tests/src/main/resources/servers/zkReplicationPrimaryPeerA/broker.xml#L42] not sure if that helps your use case, but a peer activation with a ha file lock, say on a shared volume with tight tolerance, could be a good approach. at the moment, I don't think the file lock can be on a different volume from the journal, but if it could, we could have a mostly reliable file lock on a shared directory, with only the locking taking the sync and reliable read/lock hit. > Allow node ID to be configured > -- > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4528) TLS support PEM format for key and trust store type
[ https://issues.apache.org/jira/browse/ARTEMIS-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4528. - Resolution: Fixed > TLS support PEM format for key and trust store type > --- > > Key: ARTEMIS-4528 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4528 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > Time Spent: 4.5h > Remaining Estimate: 0h > > managing key and trust store passwords when the credentials are securely > stored or managed by other means is a nuisance. > there is a nice PEM keystore provider at: > [https://github.com/ctron/pem-keystore] > This gives us an intuitive way to easily reference a simple cert or key > without a password as is the case with jsk or pkcs12 > name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.pem;keyStoreType=PEM > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4528) TLS support PEM format for key and trust store type
Gary Tully created ARTEMIS-4528: --- Summary: TLS support PEM format for key and trust store type Key: ARTEMIS-4528 URL: https://issues.apache.org/jira/browse/ARTEMIS-4528 Project: ActiveMQ Artemis Issue Type: Improvement Components: Configuration Affects Versions: 2.31.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.32.0 managing key and trust store passwords when the credentials are securely stored or managed by other means is a nuisance. there is a nice PEM keystore provider at: [https://github.com/ctron/pem-keystore] This gives us an intuitive way to easily reference a simple cert or key without a password as is the case with jsk or pkcs12 tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.pem;keyStoreType=PEM -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4517) rollback causes loss of message order if concurrent producers commit out of order
[ https://issues.apache.org/jira/browse/ARTEMIS-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4517. - Fix Version/s: 2.32.0 Resolution: Fixed > rollback causes loss of message order if concurrent producers commit out of > order > -- > > Key: ARTEMIS-4517 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4517 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.31.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > As part of ARTEMIS-2458, cancel puts messages back onto the queue on sequence > id order, but the sequence id is allocated to producers on message send (via > the message store) and can be unordered w.r.t to a queue view when producer > transactions overlap. > The queue has the correct initial producer order, with out of order > sequenceId. > When messages are cancelled back to the queue they go back in sqeuenceId > order in error, giving a consumer out of order messages on the second or > subsequent delivery attempts. > > each queue needs to retain its own sequence and apply to its reference, such > that messages can be cancelled back and retain the queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4517) rollback causes loss of message order if concurrent producers commit out of order
Gary Tully created ARTEMIS-4517: --- Summary: rollback causes loss of message order if concurrent producers commit out of order Key: ARTEMIS-4517 URL: https://issues.apache.org/jira/browse/ARTEMIS-4517 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 2.31.0 Reporter: Gary Tully Assignee: Gary Tully As part of ARTEMIS-2458, cancel puts messages back onto the queue on sequence id order, but the sequence id is allocated to producers on message send (via the message store) and can be unordered w.r.t to a queue view when producer transactions overlap. The queue has the correct initial producer order, with out of order sequenceId. When messages are cancelled back to the queue they go back in sqeuenceId order in error, giving a consumer out of order messages on the second or subsequent delivery attempts. each queue needs to retain its own sequence and apply to its reference, such that messages can be cancelled back and retain the queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4164) Auto reload acceptor SSL keystores on change
[ https://issues.apache.org/jira/browse/ARTEMIS-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4164: Description: In ARTEMIS-400 we added a jmx operation to reload ssl context configuration. It would make sense to trigger this automatically by default when a change is detected. We have the file watcher and can register an entry per keystore reference on acceptor creation. I think this should be the default but the jmx op has been the way to manually do this to date. Will make it an option, _*sslAutoReload*_ disabled by default. h1. was: In ARTEMIS-400 we added a jmx operation to reload ssl context configuration. It would make sense to trigger this automatically by default when a change is detected. We have the file watcher and can register an entry per keystore reference on acceptor creation. I think this should be the default but the jmx op has been the way to manually do this to date. Will make it an option, disabled by default. h1. > Auto reload acceptor SSL keystores on change > > > Key: ARTEMIS-4164 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4164 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.27.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Labels: Netty, TLS > Fix For: 2.32.0 > > Time Spent: 40m > Remaining Estimate: 0h > > In ARTEMIS-400 we added a jmx operation to reload ssl context configuration. > It would make sense to trigger this automatically by default when a change is > detected. We have the file watcher and can register an entry per keystore > reference on acceptor creation. > I think this should be the default but the jmx op has been the way to > manually do this to date. Will make it an option, _*sslAutoReload*_ disabled > by default. > h1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4164) Auto reload acceptor SSL keystores on change
[ https://issues.apache.org/jira/browse/ARTEMIS-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4164: Description: In ARTEMIS-400 we added a jmx operation to reload ssl context configuration. It would make sense to trigger this automatically by default when a change is detected. We have the file watcher and can register an entry per keystore reference on acceptor creation. I think this should be the default but the jmx op has been the way to manually do this to date. Will make it an option, disabled by default. h1. was: In ARTEMIS-400 we added a jmx operation to reload ssl context configuration. It would make sense to trigger this automatically by default when a change is detected. We have the file watcher and can register an entry per keystore reference on acceptor creation. I think this should be the default but we can have a autoReload config option to disable it but it may be sufficient to depend on the file watch period to disable this feature? h1. > Auto reload acceptor SSL keystores on change > > > Key: ARTEMIS-4164 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4164 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.27.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Labels: Netty, TLS > Fix For: 2.32.0 > > Time Spent: 40m > Remaining Estimate: 0h > > In ARTEMIS-400 we added a jmx operation to reload ssl context configuration. > It would make sense to trigger this automatically by default when a change is > detected. We have the file watcher and can register an entry per keystore > reference on acceptor creation. > I think this should be the default but the jmx op has been the way to > manually do this to date. Will make it an option, disabled by default. > h1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4164) Auto reload acceptor SSL keystores on change
[ https://issues.apache.org/jira/browse/ARTEMIS-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4164. - Fix Version/s: 2.32.0 Resolution: Fixed > Auto reload acceptor SSL keystores on change > > > Key: ARTEMIS-4164 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4164 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.27.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Labels: Netty, TLS > Fix For: 2.32.0 > > Time Spent: 40m > Remaining Estimate: 0h > > In ARTEMIS-400 we added a jmx operation to reload ssl context configuration. > It would make sense to trigger this automatically by default when a change is > detected. We have the file watcher and can register an entry per keystore > reference on acceptor creation. > I think this should be the default but we can have a autoReload config option > to disable it but it may be sufficient to depend on the file watch period to > disable this feature? > h1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4164) Auto reload acceptor SSL keystores on change
[ https://issues.apache.org/jira/browse/ARTEMIS-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully reassigned ARTEMIS-4164: --- Assignee: Gary Tully > Auto reload acceptor SSL keystores on change > > > Key: ARTEMIS-4164 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4164 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.27.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Labels: Netty, TLS > Time Spent: 0.5h > Remaining Estimate: 0h > > In ARTEMIS-400 we added a jmx operation to reload ssl context configuration. > It would make sense to trigger this automatically by default when a change is > detected. We have the file watcher and can register an entry per keystore > reference on acceptor creation. > I think this should be the default but we can have a autoReload config option > to disable it but it may be sufficient to depend on the file watch period to > disable this feature? > h1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4480) exclusiveConsumer release needs an operation context completion callbacks to ensure isolation for delivered and transacted messages
[ https://issues.apache.org/jira/browse/ARTEMIS-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4480. - Fix Version/s: 2.32.0 Resolution: Fixed > exclusiveConsumer release needs an operation context completion callbacks to > ensure isolation for delivered and transacted messages > --- > > Key: ARTEMIS-4480 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4480 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker, OpenWire >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > in order to see order on a queue from a consumer perspective, the consumer > must be exclusive. Any pending work for any previous consumer, delivered put > back on the queue or pending transaction completion rollback or commit or > close must have occurred before dispatch to a new consumer resumes. > The removal of the consumer must wait to release the exclusive consumer flag. > To do this it must be able to be sure that all previous completions on the > context are done. > This requires consistent use of the operation context to enforce sequential > completion. > This problem was visible with openwire which typically has a large prefetch, > resulting in many messages in the delivering list, moved there on rollback > from the acks list of a transaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4480) exclusiveConsumer release needs an operation context completion callbacks to ensure isolation for delivered and transacted messages
[ https://issues.apache.org/jira/browse/ARTEMIS-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4480: Description: in order to see order on a queue from a consumer perspective, the consumer must be exclusive. Any pending work for any previous consumer, delivered put back on the queue or pending transaction completion rollback or commit or close must have occurred before dispatch to a new consumer resumes. The removal of the consumer must wait to release the exclusive consumer flag. To do this it must be able to be sure that all previous completions on the context are done. This requires consistent use of the operation context to enforce sequential completion. This problem was visible with openwire which typically has a large prefetch, resulting in many messages in the delivering list, moved there on rollback from the acks list of a transaction. was: in order to see order on a queue from a consumer perspective, the consumer must be exclusive. Any pending work for any previous consumer, delivered put back on the queue or pending transaction completion rollback or commit or close must have occurred before dispatch to a new consumer resumes. The removal of the consumer must wait to release the exclusive consumer flag. To do this it must be able to be sure that all previous completions on the context are done. This requires some additions to our operation context to enforce sequential completion rather than the current sequential start. This problem was visible with openwire which typically has a large prefetch, resulting in many messages in the delivering list, moved there on rollback from the acks list. When contention on the opernwire connection was resolved, the operation context nondeterminism on completion callback order became visible. > exclusiveConsumer release needs an operation context completion callbacks to > ensure isolation for delivered and transacted messages > --- > > Key: ARTEMIS-4480 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4480 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker, OpenWire >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > in order to see order on a queue from a consumer perspective, the consumer > must be exclusive. Any pending work for any previous consumer, delivered put > back on the queue or pending transaction completion rollback or commit or > close must have occurred before dispatch to a new consumer resumes. > The removal of the consumer must wait to release the exclusive consumer flag. > To do this it must be able to be sure that all previous completions on the > context are done. > This requires consistent use of the operation context to enforce sequential > completion. > This problem was visible with openwire which typically has a large prefetch, > resulting in many messages in the delivering list, moved there on rollback > from the acks list of a transaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4480) exclusiveConsumer release needs an operation context completion callbacks to ensure isolation for delivered and transacted messages
[ https://issues.apache.org/jira/browse/ARTEMIS-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4480: Summary: exclusiveConsumer release needs an operation context completion callbacks to ensure isolation for delivered and transacted messages (was: exclusiveConsumer needs sequential operation context completion callbacks to ensure isolation for delivered and transacted messages) > exclusiveConsumer release needs an operation context completion callbacks to > ensure isolation for delivered and transacted messages > --- > > Key: ARTEMIS-4480 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4480 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker, OpenWire >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > in order to see order on a queue from a consumer perspective, the consumer > must be exclusive. Any pending work for any previous consumer, delivered put > back on the queue or pending transaction completion rollback or commit or > close must have occurred before dispatch to a new consumer resumes. > The removal of the consumer must wait to release the exclusive consumer flag. > To do this it must be able to be sure that all previous completions on the > context are done. > This requires some additions to our operation context to enforce sequential > completion rather than the current sequential start. > This problem was visible with openwire which typically has a large prefetch, > resulting in many messages in the delivering list, moved there on rollback > from the acks list. When contention on the opernwire connection was resolved, > the operation context nondeterminism on completion callback order became > visible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4480) exclusiveConsumer needs sequential operation context completion callbacks to ensure isolation for delivered and transacted messages
Gary Tully created ARTEMIS-4480: --- Summary: exclusiveConsumer needs sequential operation context completion callbacks to ensure isolation for delivered and transacted messages Key: ARTEMIS-4480 URL: https://issues.apache.org/jira/browse/ARTEMIS-4480 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker, OpenWire Reporter: Gary Tully Assignee: Gary Tully in order to see order on a queue from a consumer perspective, the consumer must be exclusive. Any pending work for any previous consumer, delivered put back on the queue or pending transaction completion rollback or commit or close must have occurred before dispatch to a new consumer resumes. The removal of the consumer must wait to release the exclusive consumer flag. To do this it must be able to be sure that all previous completions on the context are done. This requires some additions to our operation context to enforce sequential completion rather than the current sequential start. This problem was visible with openwire which typically has a large prefetch, resulting in many messages in the delivering list, moved there on rollback from the acks list. When contention on the opernwire connection was resolved, the operation context nondeterminism on completion callback order became visible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4443) properties config - support broker plugin - logging broker plugin
[
https://issues.apache.org/jira/browse/ARTEMIS-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved ARTEMIS-4443.
-
Resolution: Fixed
> properties config - support broker plugin - logging broker plugin
> -
>
> Key: ARTEMIS-4443
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4443
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration
>Affects Versions: 2.31.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.32.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> broker plugins require a way to add a new instance of a class to a collection
> via broker properties. Using the class name as the key can work nicely.
> In addition, the registration and configuration of broker plugins needs to be
> separated, currently they are handled in a single method call.
> {code}
> brokerPlugins.\"org.apache.activemq.artemis.core.server.plugin.impl.LoggingActiveMQServerPlugin.class\".init=LOG_ALL_EVENTS=false
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4443) properties config - support broker plugin - logging broker plugin
Gary Tully created ARTEMIS-4443:
---
Summary: properties config - support broker plugin - logging
broker plugin
Key: ARTEMIS-4443
URL: https://issues.apache.org/jira/browse/ARTEMIS-4443
Project: ActiveMQ Artemis
Issue Type: Improvement
Components: Broker, Configuration
Affects Versions: 2.31.0
Reporter: Gary Tully
Assignee: Gary Tully
Fix For: 2.32.0
broker plugins require a way to add a new instance of a class to a collection
via broker properties. Using the class name as the key can work nicely.
In addition, the registration and configuration of broker plugins needs to be
separated, currently they are handled in a single method call.
{code}
brokerPlugins.\"org.apache.activemq.artemis.core.server.plugin.impl.LoggingActiveMQServerPlugin.class\".init=LOG_ALL_EVENTS=false
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4432) openwire connection failure handling is bypassing the actor and ignoring the operation context leading to contention in error
[ https://issues.apache.org/jira/browse/ARTEMIS-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4432. - Fix Version/s: 2.32.0 Resolution: Fixed > openwire connection failure handling is bypassing the actor and ignoring the > operation context leading to contention in error > - > > Key: ARTEMIS-4432 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4432 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.32.0 > > > On a kill -9 test, for a transacted batch openwire consumer, it is possibly > for a batch to get stuck in delivery due to contention on the current > transaction. A restart is needed to have redeliver happen in this case. > The contention can be avoided by respecting the ordered actor and operation > context in the fail handling that originates from the netty handler when a > connection dies due to socket error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4432) openwire connection failure handling is bypassing the actor and ignoring the operation context leading to contention in error
[ https://issues.apache.org/jira/browse/ARTEMIS-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4432: Fix Version/s: (was: 2.31.0) > openwire connection failure handling is bypassing the actor and ignoring the > operation context leading to contention in error > - > > Key: ARTEMIS-4432 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4432 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > On a kill -9 test, for a transacted batch openwire consumer, it is possibly > for a batch to get stuck in delivery due to contention on the current > transaction. A restart is needed to have redeliver happen in this case. > The contention can be avoided by respecting the ordered actor and operation > context in the fail handling that originates from the netty handler when a > connection dies due to socket error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4432) openwire connection failure handling is bypassing the actor and ignoring the operation context leading to contention in error
Gary Tully created ARTEMIS-4432: --- Summary: openwire connection failure handling is bypassing the actor and ignoring the operation context leading to contention in error Key: ARTEMIS-4432 URL: https://issues.apache.org/jira/browse/ARTEMIS-4432 Project: ActiveMQ Artemis Issue Type: Bug Components: OpenWire Affects Versions: 2.30.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.31.0 On a kill -9 test, for a transacted batch openwire consumer, it is possibly for a batch to get stuck in delivery due to contention on the current transaction. A restart is needed to have redeliver happen in this case. The contention can be avoided by respecting the ordered actor and operation context in the fail handling that originates from the netty handler when a connection dies due to socket error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4418. - Fix Version/s: 2.31.0 Resolution: Fixed > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > 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 > > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > The root cause is the use of the persistence id, or store order, which is > itself loose. It would be better if the sequence id was directly related to > the consumer delivered list and independent of total queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762686#comment-17762686 ] Gary Tully commented on ARTEMIS-4418: - PR: https://github.com/apache/activemq-artemis/pull/4606 > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > The root cause is the use of the persistence id, or store order, which is > itself loose. It would be better if the sequence id was directly related to > the consumer delivered list and independent of total queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762685#comment-17762685 ] Gary Tully commented on ARTEMIS-4418: - for reference, the lastDeliveredSequenceId being used on the client: https://github.com/apache/activemq/blob/fc13d61714c1554433fd06becceed55dbe9ef8e5/activemq-client/src/main/java/org/apache/activemq/ActiveMQMessageConsumer.java#L932 > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > The root cause is the use of the persistence id, or store order, which is > itself loose. It would be better if the sequence id was directly related to > the consumer delivered list and independent of total queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4418: Description: Following up on ARTEMIS-4410, message order is necessary to make sense of the openwire consumer close lastDeliveredSequence id, when order is compromised the delivery count on prefetched messages can get incremented in error. The root cause is the use of the persistence id, or store order, which is itself loose. It would be better if the sequence id was directly related to the consumer delivered list and independent of total queue order. was: Following up on ARTEMIS-4410, message order is necessary to make sense of the openwire consumer close lastDeliveredSequence id, when order is compromised the delivery count on prefetched messages can get incremented in error. We should use the default (core) delivery semantics of treating credit or delivered or prefetched messages as not delivered on non exclusive queues. Only on an exclusive queue will we respect the lastDeliveredSequenceId > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > The root cause is the use of the persistence id, or store order, which is > itself loose. It would be better if the sequence id was directly related to > the consumer delivered list and independent of total queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4418: Summary: openwire lastDeliveredSequenceId depends on message order, it should not (was: openwire lastDeliveredSequenceId depends on message order, should only be respected on an exclusive queue) > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > We should use the default (core) delivery semantics of treating credit or > delivered or prefetched messages as not delivered on non exclusive queues. > Only on an exclusive queue will we respect the lastDeliveredSequenceId -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, should only be respected on an exclusive queue
Gary Tully created ARTEMIS-4418: --- Summary: openwire lastDeliveredSequenceId depends on message order, should only be respected on an exclusive queue Key: ARTEMIS-4418 URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 Project: ActiveMQ Artemis Issue Type: Bug Components: OpenWire Affects Versions: 2.30.0 Reporter: Gary Tully Assignee: Gary Tully Following up on ARTEMIS-4410, message order is necessary to make sense of the openwire consumer close lastDeliveredSequence id, when order is compromised the delivery count on prefetched messages can get incremented in error. We should use the default (core) delivery semantics of treating credit or delivered or prefetched messages as not delivered on non exclusive queues. Only on an exclusive queue will we respect the lastDeliveredSequenceId -- 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] [Created] (ARTEMIS-4410) Openwire prefetched messages can be out of order after failover to an exclusive queue
Gary Tully created ARTEMIS-4410: --- Summary: 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 Fix For: 2.31.0 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] [Resolved] (ARTEMIS-4378) Federation, ignore address policy when using pull consumer connection
[ https://issues.apache.org/jira/browse/ARTEMIS-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4378. - Fix Version/s: 2.31.0 Assignee: Gary Tully Resolution: Fixed > Federation, ignore address policy when using pull consumer connection > -- > > Key: ARTEMIS-4378 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4378 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Minor > Fix For: 2.31.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Using the batching pull consumer from ARTEMIS-4314 is only applicable to > queue Federation but both policies can be configured in the same federation. > If consumer window size of zero is configured any address policy should be > ignored. With address federation there is no local queue to gauge capacity > and messages will just accumate in the upstream. The concept of a pull > consumer for address federation does not make any sense. > This strategy is already adopted for queue Federation configured for > multicast addresses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4378) Federation, ignore address policy when using pull consumer connection
Gary Tully created ARTEMIS-4378: --- Summary: Federation, ignore address policy when using pull consumer connection Key: ARTEMIS-4378 URL: https://issues.apache.org/jira/browse/ARTEMIS-4378 Project: ActiveMQ Artemis Issue Type: Improvement Components: Federation Affects Versions: 2.29.0 Reporter: Gary Tully Using the batching pull consumer from ARTEMIS-4314 is only applicable to queue Federation but both policies can be configured in the same federation. If consumer window size of zero is configured any address policy should be ignored. With address federation there is no local queue to gauge capacity and messages will just accumate in the upstream. The concept of a pull consumer for address federation does not make any sense. This strategy is already adopted for queue Federation configured for multicast addresses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4314) Queue Federation, support consumerWindowSize zero and federate in batches only when the local queue is has excess capacity
[ https://issues.apache.org/jira/browse/ARTEMIS-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully closed ARTEMIS-4314. --- Resolution: Fixed > Queue Federation, support consumerWindowSize zero and federate in batches > only when the local queue is has excess capacity > -- > > Key: ARTEMIS-4314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4314 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.30.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Dual queue federation, where clusters federate in both direction can suffer > from message flip flopping once the priority adjustment kicks in. > If there is a large backlog, the lower priority federation consumer is in > play once all of the local consumer credit is exhausted and the backlog can > drain to the other cluster. > If demand is low there, the process can repeat. limiting the rate of the > federation consumer can help but it is not ideal b/c when there is no local > demand, we want to have a high rate of migration. > > A possible solution is to have the federation consumer manage its own credit > and only flow messages when the local queue has capacity. Then flow a batch > of messages, and await again that the local queue has capacity. In this way, > there is no thundering herd effect, but there is also fast migration of > messages once there is demand. > the consumerWindowSize=0 is already in play for consumer.receive calls and > there is already a defaultConsumerWindowSize for an address. These can be > combined to realise batchFederationOnCapacity semantics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4314) Queue Federation, support consumerWindowSize zero and federate in batches only when the local queue is has excess capacity
[ https://issues.apache.org/jira/browse/ARTEMIS-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4314: Summary: Queue Federation, support consumerWindowSize zero and federate in batches only when the local queue is has excess capacity (was: Federation, support consumerWindowSize zero and federate in batches only when the local queue is has excess capacity) > Queue Federation, support consumerWindowSize zero and federate in batches > only when the local queue is has excess capacity > -- > > Key: ARTEMIS-4314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4314 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.30.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Dual queue federation, where clusters federate in both direction can suffer > from message flip flopping once the priority adjustment kicks in. > If there is a large backlog, the lower priority federation consumer is in > play once all of the local consumer credit is exhausted and the backlog can > drain to the other cluster. > If demand is low there, the process can repeat. limiting the rate of the > federation consumer can help but it is not ideal b/c when there is no local > demand, we want to have a high rate of migration. > > A possible solution is to have the federation consumer manage its own credit > and only flow messages when the local queue has capacity. Then flow a batch > of messages, and await again that the local queue has capacity. In this way, > there is no thundering herd effect, but there is also fast migration of > messages once there is demand. > the consumerWindowSize=0 is already in play for consumer.receive calls and > there is already a defaultConsumerWindowSize for an address. These can be > combined to realise batchFederationOnCapacity semantics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (ARTEMIS-4314) Federation, support consumerWindowSize zero and federate in batches only when the local queue is has excess capacity
[ https://issues.apache.org/jira/browse/ARTEMIS-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully reopened ARTEMIS-4314: - > Federation, support consumerWindowSize zero and federate in batches only when > the local queue is has excess capacity > > > Key: ARTEMIS-4314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4314 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.30.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Dual queue federation, where clusters federate in both direction can suffer > from message flip flopping once the priority adjustment kicks in. > If there is a large backlog, the lower priority federation consumer is in > play once all of the local consumer credit is exhausted and the backlog can > drain to the other cluster. > If demand is low there, the process can repeat. limiting the rate of the > federation consumer can help but it is not ideal b/c when there is no local > demand, we want to have a high rate of migration. > > A possible solution is to have the federation consumer manage its own credit > and only flow messages when the local queue has capacity. Then flow a batch > of messages, and await again that the local queue has capacity. In this way, > there is no thundering herd effect, but there is also fast migration of > messages once there is demand. > the consumerWindowSize=0 is already in play for consumer.receive calls and > there is already a defaultConsumerWindowSize for an address. These can be > combined to realise batchFederationOnCapacity semantics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4368) ensure predictable order of subjects for accurate logging
[ https://issues.apache.org/jira/browse/ARTEMIS-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4368. - Resolution: Fixed > ensure predictable order of subjects for accurate logging > - > > Key: ARTEMIS-4368 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4368 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JAAS >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.30.0 > > > all our login modules that apply role and user principals need to use ordered > sets to populate the ordered sets of the subject. This ensure that the first > principal is the user principal, which is useful when we log. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4368) ensure predictable order of subjects for accurate logging
Gary Tully created ARTEMIS-4368: --- Summary: ensure predictable order of subjects for accurate logging Key: ARTEMIS-4368 URL: https://issues.apache.org/jira/browse/ARTEMIS-4368 Project: ActiveMQ Artemis Issue Type: Improvement Components: JAAS Affects Versions: 2.29.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.30.0 all our login modules that apply role and user principals need to use ordered sets to populate the ordered sets of the subject. This ensure that the first principal is the user principal, which is useful when we log. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4367) Split server logger codes into advice and info category and by logger
[ https://issues.apache.org/jira/browse/ARTEMIS-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4367: Description: We have server logger that uses AMQXXX codes for log messages. all is good. We have a class of log message that is advice... * address X does not a DLQ registered * address X does not an expiry address registered These advice are info or warn trying to help users but often times the config is by design and this advice is just noise. Users want to disable, but not all of the server logger infor or warn messages. log4j allows to filter, but that is expensive. If we split out these advice messages into a separate class and use a nested logger per code, it would be simple to suppress advice that is noise for a given scenario There was an new advice in ARTEMIS-4362 that suggests we do have a class of advices/warns that would benefit from a simple way to suppress. was: We have server logger that uses AMQXXX codes for log messages. all is good. We have a class of log message that is advice... * address X does not a DLQ registered * address X does not an expiry address registered These advice are info or warn trying to help users but often times the config is by design and this advice is just noise. Users want to disable, but not all of the server logger infor or warn messages. log4j allows to filter, but that is expensive. If we split out these advice messages into a separate class and use a nested logger per code, it would be simple to suppress advice that is noise for a given scenario There was an new advice in AMQ-6854 that suggests we do have a class of advices/warns that would benefit from a simple way to suppress. > Split server logger codes into advice and info category and by logger > - > > Key: ARTEMIS-4367 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4367 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.29.0 >Reporter: Gary Tully >Priority: Major > > We have server logger that uses AMQXXX codes for log messages. all is good. > We have a class of log message that is advice... > * address X does not a DLQ registered > * address X does not an expiry address registered > These advice are info or warn trying to help users but often times the config > is by design and this advice is just noise. Users want to disable, but not > all of the server logger infor or warn messages. > log4j allows to filter, but that is expensive. > If we split out these advice messages into a separate class and use a nested > logger per code, it would be simple to suppress advice that is noise for a > given scenario > There was an new advice in ARTEMIS-4362 that suggests we do have a class of > advices/warns that would benefit from a simple way to suppress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4367) Split server logger codes into advice and info category and by logger
[ https://issues.apache.org/jira/browse/ARTEMIS-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744266#comment-17744266 ] Gary Tully commented on ARTEMIS-4367: - an example of filtering from [~jbertram] # Console appender appender.console.type=Console appender.console.name=console appender.console.layout.type=PatternLayout appender.console.layout.pattern=%d %-5level [%logger] %msg%n appender.console.filter.no_dla_or_expiry_warns.type=RegexFilter appender.console.filter.no_dla_or_expiry_warns.regex=.*AMQ222165.*|.*AMQ222166.* appender.console.filter.no_dla_or_expiry_warns.onMatch=DENY appender.console.filter.no_dla_or_expiry_warns.onMismatch=ACCEPT > Split server logger codes into advice and info category and by logger > - > > Key: ARTEMIS-4367 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4367 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.29.0 >Reporter: Gary Tully >Priority: Major > > We have server logger that uses AMQXXX codes for log messages. all is good. > We have a class of log message that is advice... > * address X does not a DLQ registered > * address X does not an expiry address registered > These advice are info or warn trying to help users but often times the config > is by design and this advice is just noise. Users want to disable, but not > all of the server logger infor or warn messages. > log4j allows to filter, but that is expensive. > If we split out these advice messages into a separate class and use a nested > logger per code, it would be simple to suppress advice that is noise for a > given scenario > There was an new advice in AMQ-6854 that suggests we do have a class of > advices/warns that would benefit from a simple way to suppress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4367) Split server logger codes into advice and info category and by logger
[ https://issues.apache.org/jira/browse/ARTEMIS-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4367: Issue Type: Improvement (was: Bug) > Split server logger codes into advice and info category and by logger > - > > Key: ARTEMIS-4367 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4367 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.29.0 >Reporter: Gary Tully >Priority: Major > > We have server logger that uses AMQXXX codes for log messages. all is good. > We have a class of log message that is advice... > * address X does not a DLQ registered > * address X does not an expiry address registered > These advice are info or warn trying to help users but often times the config > is by design and this advice is just noise. Users want to disable, but not > all of the server logger infor or warn messages. > log4j allows to filter, but that is expensive. > If we split out these advice messages into a separate class and use a nested > logger per code, it would be simple to suppress advice that is noise for a > given scenario > There was an new advice in AMQ-6854 that suggests we do have a class of > advices/warns that would benefit from a simple way to suppress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4367) Split server logger codes into advice and info category and by logger
[ https://issues.apache.org/jira/browse/ARTEMIS-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4367: Summary: Split server logger codes into advice and info category and by logger (was: Split server logger codes into advice and info and by logger) > Split server logger codes into advice and info category and by logger > - > > Key: ARTEMIS-4367 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4367 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.29.0 >Reporter: Gary Tully >Priority: Major > > We have server logger that uses AMQXXX codes for log messages. all is good. > We have a class of log message that is advice... > * address X does not a DLQ registered > * address X does not an expiry address registered > These advice are info or warn trying to help users but often times the config > is by design and this advice is just noise. Users want to disable, but not > all of the server logger infor or warn messages. > log4j allows to filter, but that is expensive. > If we split out these advice messages into a separate class and use a nested > logger per code, it would be simple to suppress advice that is noise for a > given scenario > There was an new advice in AMQ-6854 that suggests we do have a class of > advices/warns that would benefit from a simple way to suppress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4367) Split server logger codes into advice and info and by logger
Gary Tully created ARTEMIS-4367: --- Summary: Split server logger codes into advice and info and by logger Key: ARTEMIS-4367 URL: https://issues.apache.org/jira/browse/ARTEMIS-4367 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Affects Versions: 2.29.0 Reporter: Gary Tully We have server logger that uses AMQXXX codes for log messages. all is good. We have a class of log message that is advice... * address X does not a DLQ registered * address X does not an expiry address registered These advice are info or warn trying to help users but often times the config is by design and this advice is just noise. Users want to disable, but not all of the server logger infor or warn messages. log4j allows to filter, but that is expensive. If we split out these advice messages into a separate class and use a nested logger per code, it would be simple to suppress advice that is noise for a given scenario There was an new advice in AMQ-6854 that suggests we do have a class of advices/warns that would benefit from a simple way to suppress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4356) address match with wildcards seems to be broken
[
https://issues.apache.org/jira/browse/ARTEMIS-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved ARTEMIS-4356.
-
Resolution: Fixed
> address match with wildcards seems to be broken
> ---
>
> Key: ARTEMIS-4356
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4356
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.29.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.30.0
>
> Attachments: MatchTest.java
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Using a wildcard address include match in federation, include test.# is too
> lenient which points to a bug in the address settings matcher that is in play.
>
> the attached test shows the problem.
> {{final Match underTest = new Match<>("test.#", null, new
> WildcardConfiguration());}}
> {{Predicate predicate = underTest.getPattern().asPredicate();}}
> {{assertTrue(predicate.test("test.A"));}}
> {{assertFalse(predicate.test("testing.A"));}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4356) address match with wildcards seems to be broken
[
https://issues.apache.org/jira/browse/ARTEMIS-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742030#comment-17742030
]
Gary Tully commented on ARTEMIS-4356:
-
the regexp needs a full match, that sorts the problem. direct=true, [~jbertram]
for the mqtt use case, that may need some investigation to see if it is what is
expected. I added a little direct=true variant to the test.
> address match with wildcards seems to be broken
> ---
>
> Key: ARTEMIS-4356
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4356
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.29.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.30.0
>
> Attachments: MatchTest.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Using a wildcard address include match in federation, include test.# is too
> lenient which points to a bug in the address settings matcher that is in play.
>
> the attached test shows the problem.
> {{final Match underTest = new Match<>("test.#", null, new
> WildcardConfiguration());}}
> {{Predicate predicate = underTest.getPattern().asPredicate();}}
> {{assertTrue(predicate.test("test.A"));}}
> {{assertFalse(predicate.test("testing.A"));}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4356) address match with wildcards seems to be broken
[
https://issues.apache.org/jira/browse/ARTEMIS-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully reassigned ARTEMIS-4356:
---
Assignee: Gary Tully
> address match with wildcards seems to be broken
> ---
>
> Key: ARTEMIS-4356
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4356
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.29.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.30.0
>
> Attachments: MatchTest.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Using a wildcard address include match in federation, include test.# is too
> lenient which points to a bug in the address settings matcher that is in play.
>
> the attached test shows the problem.
> {{final Match underTest = new Match<>("test.#", null, new
> WildcardConfiguration());}}
> {{Predicate predicate = underTest.getPattern().asPredicate();}}
> {{assertTrue(predicate.test("test.A"));}}
> {{assertFalse(predicate.test("testing.A"));}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4356) address match with wildcards seems to be broken
[
https://issues.apache.org/jira/browse/ARTEMIS-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741708#comment-17741708
]
Gary Tully edited comment on ARTEMIS-4356 at 7/10/23 5:19 PM:
--
@[michaelandrepearce|https://github.com/apache/activemq-artemis/commits?author=michaelandrepearce]
any chance you have memory of 2017, it looks like the .* [1] regexp is a
little greedy. Note the little test in the description of this issue, does it
ring any bell as to expectations?
from what I know, test.# should match "test" and "test.a" but not "testing.a" ?
there seems to be some history here.
[1]
[https://github.com/apache/activemq-artemis/commit/e9eaa7d#diff-c080f58d1810937d61cced308ce9782b479b27bb3a3a20a6cc4e78b4b31f674bR33]
was (Author: gtully):
@[michaelandrepearce|https://github.com/apache/activemq-artemis/commits?author=michaelandrepearce]
any chance you have memory of 2017, it looks like the .* regexp is a little
greedy. Note the little test in the description of this issue, does it ring any
bell as to expectations?
from what I know, test.# should match "test" and "test.a" but not "testing.a" ?
there seems to be some history here.
https://github.com/apache/activemq-artemis/commit/e9eaa7d#diff-c080f58d1810937d61cced308ce9782b479b27bb3a3a20a6cc4e78b4b31f674bR33
> address match with wildcards seems to be broken
> ---
>
> Key: ARTEMIS-4356
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4356
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.29.0
>Reporter: Gary Tully
>Priority: Major
> Fix For: 2.30.0
>
> Attachments: MatchTest.java
>
>
> Using a wildcard address include match in federation, include test.# is too
> lenient which points to a bug in the address settings matcher that is in play.
>
> the attached test shows the problem.
> {{final Match underTest = new Match<>("test.#", null, new
> WildcardConfiguration());}}
> {{Predicate predicate = underTest.getPattern().asPredicate();}}
> {{assertTrue(predicate.test("test.A"));}}
> {{assertFalse(predicate.test("testing.A"));}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4356) address match with wildcards seems to be broken
[
https://issues.apache.org/jira/browse/ARTEMIS-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741708#comment-17741708
]
Gary Tully commented on ARTEMIS-4356:
-
@[michaelandrepearce|https://github.com/apache/activemq-artemis/commits?author=michaelandrepearce]
any chance you have memory of 2017, it looks like the .* regexp is a little
greedy. Note the little test in the description of this issue, does it ring any
bell as to expectations?
from what I know, test.# should match "test" and "test.a" but not "testing.a" ?
there seems to be some history here.
https://github.com/apache/activemq-artemis/commit/e9eaa7d#diff-c080f58d1810937d61cced308ce9782b479b27bb3a3a20a6cc4e78b4b31f674bR33
> address match with wildcards seems to be broken
> ---
>
> Key: ARTEMIS-4356
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4356
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.29.0
>Reporter: Gary Tully
>Priority: Major
> Fix For: 2.30.0
>
> Attachments: MatchTest.java
>
>
> Using a wildcard address include match in federation, include test.# is too
> lenient which points to a bug in the address settings matcher that is in play.
>
> the attached test shows the problem.
> {{final Match underTest = new Match<>("test.#", null, new
> WildcardConfiguration());}}
> {{Predicate predicate = underTest.getPattern().asPredicate();}}
> {{assertTrue(predicate.test("test.A"));}}
> {{assertFalse(predicate.test("testing.A"));}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4356) address match with wildcards seems to be broken
[
https://issues.apache.org/jira/browse/ARTEMIS-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741643#comment-17741643
]
Gary Tully edited comment on ARTEMIS-4356 at 7/10/23 4:04 PM:
--
It looks like the related to https://issues.apache.org/jira/browse/ARTEMIS-1422
was (Author: gtully):
It looks like the related changes come from
https://issues.apache.org/jira/browse/ARTEMIS-3638
> address match with wildcards seems to be broken
> ---
>
> Key: ARTEMIS-4356
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4356
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.29.0
>Reporter: Gary Tully
>Priority: Major
> Fix For: 2.30.0
>
> Attachments: MatchTest.java
>
>
> Using a wildcard address include match in federation, include test.# is too
> lenient which points to a bug in the address settings matcher that is in play.
>
> the attached test shows the problem.
> {{final Match underTest = new Match<>("test.#", null, new
> WildcardConfiguration());}}
> {{Predicate predicate = underTest.getPattern().asPredicate();}}
> {{assertTrue(predicate.test("test.A"));}}
> {{assertFalse(predicate.test("testing.A"));}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4356) address match with wildcards seems to be broken
[
https://issues.apache.org/jira/browse/ARTEMIS-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741643#comment-17741643
]
Gary Tully commented on ARTEMIS-4356:
-
It looks like the related changes come from
https://issues.apache.org/jira/browse/ARTEMIS-3638
> address match with wildcards seems to be broken
> ---
>
> Key: ARTEMIS-4356
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4356
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.29.0
>Reporter: Gary Tully
>Priority: Major
> Fix For: 2.30.0
>
> Attachments: MatchTest.java
>
>
> Using a wildcard address include match in federation, include test.# is too
> lenient which points to a bug in the address settings matcher that is in play.
>
> the attached test shows the problem.
> {{final Match underTest = new Match<>("test.#", null, new
> WildcardConfiguration());}}
> {{Predicate predicate = underTest.getPattern().asPredicate();}}
> {{assertTrue(predicate.test("test.A"));}}
> {{assertFalse(predicate.test("testing.A"));}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4356) address match with wildcards seems to be broken
Gary Tully created ARTEMIS-4356:
---
Summary: address match with wildcards seems to be broken
Key: ARTEMIS-4356
URL: https://issues.apache.org/jira/browse/ARTEMIS-4356
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.29.0
Reporter: Gary Tully
Fix For: 2.30.0
Attachments: MatchTest.java
Using a wildcard address include match in federation, include test.# is too
lenient which points to a bug in the address settings matcher that is in play.
the attached test shows the problem.
{{final Match underTest = new Match<>("test.#", null, new
WildcardConfiguration());}}
{{Predicate predicate = underTest.getPattern().asPredicate();}}
{{assertTrue(predicate.test("test.A"));}}
{{assertFalse(predicate.test("testing.A"));}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4351) unnecessary web console logging on impatient jolokia client
[
https://issues.apache.org/jira/browse/ARTEMIS-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved ARTEMIS-4351.
-
Resolution: Fixed
> unnecessary web console logging on impatient jolokia client
> ---
>
> Key: ARTEMIS-4351
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4351
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.29.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.30.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If a client is impatient and gives up by closing its connection, the info
> logging of the authenticator is way too verbose. We should suppress this info
> level log message:
> {code:java}
> Doing authentication and authorization for path /jolokia
> doAuthenticate[realm=console, role=admin,
> rolePrincipalClasses=org.apache.activemq.artemis.spi.core.security.jaas.RolePrincipal,
> configuration=null, username=, password=**] Failed to invoke action
> /read/org.apache.activemq.artemis:broker="broker"/Status due to:
> java.security.PrivilegedActionException: null at
> java.security.AccessController.doPrivileged(AccessController.java:716) ~[?:?]
> at javax.security.auth.Subject.doAs(Subject.java:439) ~[?:?] at
> io.hawt.web.auth.AuthenticationFilter.executeAs(AuthenticationFilter.java:104)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> io.hawt.web.auth.AuthenticationFilter.lambda$doFilter$0(AuthenticationFilter.java:80)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> io.hawt.system.Authenticator.authenticate(Authenticator.java:158)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> io.hawt.web.auth.AuthenticationFilter.doFilter(AuthenticationFilter.java:79)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
> ~[hawtio-system-2.15.0.jar:2.15.0] at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.15.jar:10.0.15] at
> io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
> ~[hawtio-system-2.15.0.jar:2.15.0]
[jira] [Created] (ARTEMIS-4351) unnecessary web console logging on impatient jolokia client
Gary Tully created ARTEMIS-4351:
---
Summary: unnecessary web console logging on impatient jolokia
client
Key: ARTEMIS-4351
URL: https://issues.apache.org/jira/browse/ARTEMIS-4351
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Web Console
Affects Versions: 2.29.0
Reporter: Gary Tully
Assignee: Gary Tully
Fix For: 2.30.0
If a client is impatient and gives up by closing its connection, the info
logging of the authenticator is way too verbose. We should suppress this info
level log message:
{code:java}
Doing authentication and authorization for path /jolokia
doAuthenticate[realm=console, role=admin,
rolePrincipalClasses=org.apache.activemq.artemis.spi.core.security.jaas.RolePrincipal,
configuration=null, username=, password=**] Failed to invoke action
/read/org.apache.activemq.artemis:broker="broker"/Status due to:
java.security.PrivilegedActionException: null at
java.security.AccessController.doPrivileged(AccessController.java:716) ~[?:?]
at javax.security.auth.Subject.doAs(Subject.java:439) ~[?:?] at
io.hawt.web.auth.AuthenticationFilter.executeAs(AuthenticationFilter.java:104)
~[hawtio-system-2.15.0.jar:2.15.0] at
io.hawt.web.auth.AuthenticationFilter.lambda$doFilter$0(AuthenticationFilter.java:80)
~[hawtio-system-2.15.0.jar:2.15.0] at
io.hawt.system.Authenticator.authenticate(Authenticator.java:158)
~[hawtio-system-2.15.0.jar:2.15.0] at
io.hawt.web.auth.AuthenticationFilter.doFilter(AuthenticationFilter.java:79)
~[hawtio-system-2.15.0.jar:2.15.0] at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.15.jar:10.0.15] at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.15.jar:10.0.15] at
io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
~[hawtio-system-2.15.0.jar:2.15.0] at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.15.jar:10.0.15] at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.15.jar:10.0.15] at
io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
~[hawtio-system-2.15.0.jar:2.15.0] at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.15.jar:10.0.15] at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.15.jar:10.0.15] at
io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
~[hawtio-system-2.15.0.jar:2.15.0] at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.15.jar:10.0.15] at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.15.jar:10.0.15] at
io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
~[hawtio-system-2.15.0.jar:2.15.0] at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.15.jar:10.0.15] at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.15.jar:10.0.15] at
io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
~[hawtio-system-2.15.0.jar:2.15.0] at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.15.jar:10.0.15] at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.15.jar:10.0.15] at
io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
~[hawtio-system-2.15.0.jar:2.15.0] at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.15.jar:10.0.15] at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.15.jar:10.0.15] at
io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
~[hawtio-system-2.15.0.jar:2.15.0] at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.15.jar:10.0.15] at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.15.jar:10.0.15] at
io.hawt.web.filters.HttpHeaderFilter.doFilter(HttpHeaderFilter.java:43)
~[hawtio-system-2.15.0.jar:2.15.0] at
org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202)
~[jetty-servlet-10.0.15.jar:10.0.15] at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
~[jetty-servlet-10.0.15.jar:10.0.15] at
io.hawt.web.auth.SessionExpiryFilter.process(SessionExpiryFilter.java:107)
~[hawtio-system-2.15.0.jar:2.15.0] at
[jira] [Commented] (ARTEMIS-4314) Federation, support consumerWindowSize zero and federate in batches only when the local queue is has excess capacity
[ https://issues.apache.org/jira/browse/ARTEMIS-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736168#comment-17736168 ] Gary Tully commented on ARTEMIS-4314: - [~clebertsuconic] I reverted your tweak, there is contention on the pendingcount check which shows up in the test failing intermittently. Put it in a loop in idea and it will fail quite quickly. without it, all is good. see: at org.apache.activemq.artemis.tests.integration.federation.FederatedQueuePullConsumerTest.testFederatedQueuePullFromUpstream(FederatedQueuePullConsumerTest.java:189) > Federation, support consumerWindowSize zero and federate in batches only when > the local queue is has excess capacity > > > Key: ARTEMIS-4314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4314 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.30.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Dual queue federation, where clusters federate in both direction can suffer > from message flip flopping once the priority adjustment kicks in. > If there is a large backlog, the lower priority federation consumer is in > play once all of the local consumer credit is exhausted and the backlog can > drain to the other cluster. > If demand is low there, the process can repeat. limiting the rate of the > federation consumer can help but it is not ideal b/c when there is no local > demand, we want to have a high rate of migration. > > A possible solution is to have the federation consumer manage its own credit > and only flow messages when the local queue has capacity. Then flow a batch > of messages, and await again that the local queue has capacity. In this way, > there is no thundering herd effect, but there is also fast migration of > messages once there is demand. > the consumerWindowSize=0 is already in play for consumer.receive calls and > there is already a defaultConsumerWindowSize for an address. These can be > combined to realise batchFederationOnCapacity semantics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4324) extensible OCI image tar for the broker; java -jar with properties files and optional base xml config
[ https://issues.apache.org/jira/browse/ARTEMIS-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully closed ARTEMIS-4324. --- > extensible OCI image tar for the broker; java -jar with properties files and > optional base xml config > -- > > Key: ARTEMIS-4324 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4324 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, image >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > > Provide the ability to build a simple usable but extensible base image of the > embedded broker. > java -jar Broker with its defaults and a mount point for property files that > can augment configuration. > This is an OCI tar image that can be built from source and loaded into any > container registry. > For a image, that is extensible and configurable, but ultimately idempotent, > there is no need for a build or install or artemis create, we can just use > the java jar dependencies and run a simple java app with full control of env, > classpath and configuration via mount points. > The properties config in the broker is at the point where 90% of the xml > configuration is possible via property files. We can add the last 10% as the > need arises. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4324) extensible OCI image tar for the broker; java -jar with properties files and optional base xml config
[ https://issues.apache.org/jira/browse/ARTEMIS-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4324. - Resolution: Fixed > extensible OCI image tar for the broker; java -jar with properties files and > optional base xml config > -- > > Key: ARTEMIS-4324 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4324 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, image >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > > Provide the ability to build a simple usable but extensible base image of the > embedded broker. > java -jar Broker with its defaults and a mount point for property files that > can augment configuration. > This is an OCI tar image that can be built from source and loaded into any > container registry. > For a image, that is extensible and configurable, but ultimately idempotent, > there is no need for a build or install or artemis create, we can just use > the java jar dependencies and run a simple java app with full control of env, > classpath and configuration via mount points. > The properties config in the broker is at the point where 90% of the xml > configuration is possible via property files. We can add the last 10% as the > need arises. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4324) extensible OCI image tar for the broker; java -jar with properties files and optional base xml config
[ https://issues.apache.org/jira/browse/ARTEMIS-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736049#comment-17736049 ] Gary Tully commented on ARTEMIS-4324: - podman and docker are interchangeable for the purpose of the [README.md|https://github.com/apache/activemq-artemis/blob/587ffb223cd2461a9da5c53e5ac189b9aa24640c/artemis-image/README.md], the project creates an OCI image.tar that can be published or loaded into a registry. In the [README.md|https://github.com/apache/activemq-artemis/blob/587ffb223cd2461a9da5c53e5ac189b9aa24640c/artemis-image/README.md] for comprehension - s/podman/docker/ Why a java main line? - for simplicity - the intent is to present the broker as a java app and expose that, so that the JVM is visible and configurable etc. artemis run and the distro scripts are focused on bare metal where it has to coexist and be update-able etc... none of that is relevant for an immutable image. In addition, as the JVM becomes more container aware w.r.t to container limits, less and less of the bare metal defaults make sense. The main wraps the current embedded broker (which is well proven and tested) and waits for it to exit (like ArtemisRun). I think there is a case to be made for a single entry point, and maybe I can replace the Main with the ArtemisRun wrapper, or extract out the relevant bits and reuse, but I don't want to expose any unnecessary options, just the necessary ones. I also want properties to be the mechanism for customisation. ie a broker is a Broker 'bean' and a few property files that tweak the defaults. A derived broker adds some more custom.properties and that is it. > extensible OCI image tar for the broker; java -jar with properties files and > optional base xml config > -- > > Key: ARTEMIS-4324 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4324 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, image >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > > Provide the ability to build a simple usable but extensible base image of the > embedded broker. > java -jar Broker with its defaults and a mount point for property files that > can augment configuration. > This is an OCI tar image that can be built from source and loaded into any > container registry. > For a image, that is extensible and configurable, but ultimately idempotent, > there is no need for a build or install or artemis create, we can just use > the java jar dependencies and run a simple java app with full control of env, > classpath and configuration via mount points. > The properties config in the broker is at the point where 90% of the xml > configuration is possible via property files. We can add the last 10% as the > need arises. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (ARTEMIS-4324) extensible OCI image tar for the broker; java -jar with properties files and optional base xml config
[ https://issues.apache.org/jira/browse/ARTEMIS-4324 ] Gary Tully deleted comment on ARTEMIS-4324: - was (Author: gtully): PR > extensible OCI image tar for the broker; java -jar with properties files and > optional base xml config > -- > > Key: ARTEMIS-4324 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4324 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, image >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > > Provide the ability to build a simple usable but extensible base image of the > embedded broker. > java -jar Broker with its defaults and a mount point for property files that > can augment configuration. > This is an OCI tar image that can be built from source and loaded into any > container registry. > For a image, that is extensible and configurable, but ultimately idempotent, > there is no need for a build or install or artemis create, we can just use > the java jar dependencies and run a simple java app with full control of env, > classpath and configuration via mount points. > The properties config in the broker is at the point where 90% of the xml > configuration is possible via property files. We can add the last 10% as the > need arises. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4324) extensible OCI image tar for the broker; java -jar with properties files and optional base xml config
[ https://issues.apache.org/jira/browse/ARTEMIS-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736047#comment-17736047 ] Gary Tully commented on ARTEMIS-4324: - PR > extensible OCI image tar for the broker; java -jar with properties files and > optional base xml config > -- > > Key: ARTEMIS-4324 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4324 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, image >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > > Provide the ability to build a simple usable but extensible base image of the > embedded broker. > java -jar Broker with its defaults and a mount point for property files that > can augment configuration. > This is an OCI tar image that can be built from source and loaded into any > container registry. > For a image, that is extensible and configurable, but ultimately idempotent, > there is no need for a build or install or artemis create, we can just use > the java jar dependencies and run a simple java app with full control of env, > classpath and configuration via mount points. > The properties config in the broker is at the point where 90% of the xml > configuration is possible via property files. We can add the last 10% as the > need arises. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4324) extensible OCI image tar for the broker; java -jar with properties files and optional base xml config
[ https://issues.apache.org/jira/browse/ARTEMIS-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736046#comment-17736046 ] Gary Tully commented on ARTEMIS-4324: - Commit 587ffb223cd2461a9da5c53e5ac189b9aa24640c in activemq-artemis's branch refs/heads/main from Gary Tully [ [https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=587ffb223c] ] ARTEMIS-3042 simple properties based, extensible broker image > extensible OCI image tar for the broker; java -jar with properties files and > optional base xml config > -- > > Key: ARTEMIS-4324 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4324 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, image >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > > Provide the ability to build a simple usable but extensible base image of the > embedded broker. > java -jar Broker with its defaults and a mount point for property files that > can augment configuration. > This is an OCI tar image that can be built from source and loaded into any > container registry. > For a image, that is extensible and configurable, but ultimately idempotent, > there is no need for a build or install or artemis create, we can just use > the java jar dependencies and run a simple java app with full control of env, > classpath and configuration via mount points. > The properties config in the broker is at the point where 90% of the xml > configuration is possible via property files. We can add the last 10% as the > need arises. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4324) extensible OCI image tar for the broker; java -jar with properties files and optional base xml config
[ https://issues.apache.org/jira/browse/ARTEMIS-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736044#comment-17736044 ] Gary Tully commented on ARTEMIS-4324: - This OCI image tar of the embedded broker is inspired by some of the commentary on the complexity of the docker images in ARTEMIS-3042 > extensible OCI image tar for the broker; java -jar with properties files and > optional base xml config > -- > > Key: ARTEMIS-4324 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4324 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration, image >Affects Versions: 2.29.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > > Provide the ability to build a simple usable but extensible base image of the > embedded broker. > java -jar Broker with its defaults and a mount point for property files that > can augment configuration. > This is an OCI tar image that can be built from source and loaded into any > container registry. > For a image, that is extensible and configurable, but ultimately idempotent, > there is no need for a build or install or artemis create, we can just use > the java jar dependencies and run a simple java app with full control of env, > classpath and configuration via mount points. > The properties config in the broker is at the point where 90% of the xml > configuration is possible via property files. We can add the last 10% as the > need arises. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4324) extensible OCI image tar for the broker; java -jar with properties files and optional base xml config
Gary Tully created ARTEMIS-4324: --- Summary: extensible OCI image tar for the broker; java -jar with properties files and optional base xml config Key: ARTEMIS-4324 URL: https://issues.apache.org/jira/browse/ARTEMIS-4324 Project: ActiveMQ Artemis Issue Type: Improvement Components: image, Broker, Configuration Affects Versions: 2.29.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.29.0 Provide the ability to build a simple usable but extensible base image of the embedded broker. java -jar Broker with its defaults and a mount point for property files that can augment configuration. This is an OCI tar image that can be built from source and loaded into any container registry. For a image, that is extensible and configurable, but ultimately idempotent, there is no need for a build or install or artemis create, we can just use the java jar dependencies and run a simple java app with full control of env, classpath and configuration via mount points. The properties config in the broker is at the point where 90% of the xml configuration is possible via property files. We can add the last 10% as the need arises. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4314) Federation, support consumerWindowSize zero and federate in batches only when the local queue is has excess capacity
[ https://issues.apache.org/jira/browse/ARTEMIS-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4314. - Resolution: Fixed > Federation, support consumerWindowSize zero and federate in batches only when > the local queue is has excess capacity > > > Key: ARTEMIS-4314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4314 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Dual queue federation, where clusters federate in both direction can suffer > from message flip flopping once the priority adjustment kicks in. > If there is a large backlog, the lower priority federation consumer is in > play once all of the local consumer credit is exhausted and the backlog can > drain to the other cluster. > If demand is low there, the process can repeat. limiting the rate of the > federation consumer can help but it is not ideal b/c when there is no local > demand, we want to have a high rate of migration. > > A possible solution is to have the federation consumer manage its own credit > and only flow messages when the local queue has capacity. Then flow a batch > of messages, and await again that the local queue has capacity. In this way, > there is no thundering herd effect, but there is also fast migration of > messages once there is demand. > the consumerWindowSize=0 is already in play for consumer.receive calls and > there is already a defaultConsumerWindowSize for an address. These can be > combined to realise batchFederationOnCapacity semantics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4314) Federation, support consumerWindowSize zero and federate in batches only when the local queue is has excess capacity
[ https://issues.apache.org/jira/browse/ARTEMIS-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4314: Description: Dual queue federation, where clusters federate in both direction can suffer from message flip flopping once the priority adjustment kicks in. If there is a large backlog, the lower priority federation consumer is in play once all of the local consumer credit is exhausted and the backlog can drain to the other cluster. If demand is low there, the process can repeat. limiting the rate of the federation consumer can help but it is not ideal b/c when there is no local demand, we want to have a high rate of migration. A possible solution is to have the federation consumer manage its own credit and only flow messages when the local queue has capacity. Then flow a batch of messages, and await again that the local queue has capacity. In this way, there is no thundering herd effect, but there is also fast migration of messages once there is demand. the consumerWindowSize=0 is already in play for consumer.receive calls and there is already a defaultConsumerWindowSize for an address. These can be combined to realise batchFederationOnCapacity semantics. was: Dual queue federation, where clusters federate in both direction can suffer from message flip flopping once the priority adjustment kicks in. If there is a large backlog, the lower priority federation consumer is in play once all of the local consumer credit is exhausted and the backlog can drain to the other cluster. If demand is low there, the process can repeat. limiting the rate of the federation consumer can help but it is not ideal b/c when there is no local demand, we want to have a high rate of migration. A possible solution is to have the federation consumer manage its own credit and only flow messages when the local queue is empty. Then flow a batch of messages, and await again that the local queue is empty. In this way, there is no thundering heard effect, but there is also fast migration of messages once there is demand. the consumerWindowSize=0 is already in play for consumer.receive calls and there is already a defaultConsumerWindowSize for an address. These can be combined to realise batchFederationOnEmpty semantics. > Federation, support consumerWindowSize zero and federate in batches only when > the local queue is has excess capacity > > > Key: ARTEMIS-4314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4314 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Dual queue federation, where clusters federate in both direction can suffer > from message flip flopping once the priority adjustment kicks in. > If there is a large backlog, the lower priority federation consumer is in > play once all of the local consumer credit is exhausted and the backlog can > drain to the other cluster. > If demand is low there, the process can repeat. limiting the rate of the > federation consumer can help but it is not ideal b/c when there is no local > demand, we want to have a high rate of migration. > > A possible solution is to have the federation consumer manage its own credit > and only flow messages when the local queue has capacity. Then flow a batch > of messages, and await again that the local queue has capacity. In this way, > there is no thundering herd effect, but there is also fast migration of > messages once there is demand. > the consumerWindowSize=0 is already in play for consumer.receive calls and > there is already a defaultConsumerWindowSize for an address. These can be > combined to realise batchFederationOnCapacity semantics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4314) Federation, support consumerWindowSize zero and federate in batches only when the local queue is has excess capacity
[ https://issues.apache.org/jira/browse/ARTEMIS-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4314: Summary: Federation, support consumerWindowSize zero and federate in batches only when the local queue is has excess capacity (was: Federation, support consumerWindowSize zero and federate in batches only when the local queue is empty) > Federation, support consumerWindowSize zero and federate in batches only when > the local queue is has excess capacity > > > Key: ARTEMIS-4314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4314 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Dual queue federation, where clusters federate in both direction can suffer > from message flip flopping once the priority adjustment kicks in. > If there is a large backlog, the lower priority federation consumer is in > play once all of the local consumer credit is exhausted and the backlog can > drain to the other cluster. > If demand is low there, the process can repeat. limiting the rate of the > federation consumer can help but it is not ideal b/c when there is no local > demand, we want to have a high rate of migration. > > A possible solution is to have the federation consumer manage its own credit > and only flow messages when the local queue is empty. Then flow a batch of > messages, and await again that the local queue is empty. In this way, there > is no thundering heard effect, but there is also fast migration of messages > once there is demand. > the consumerWindowSize=0 is already in play for consumer.receive calls and > there is already a defaultConsumerWindowSize for an address. These can be > combined to realise batchFederationOnEmpty semantics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4314) Federation, support consumerWindowSize zero and federate in batches only when the local queue is empty
[ https://issues.apache.org/jira/browse/ARTEMIS-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733204#comment-17733204 ] Gary Tully commented on ARTEMIS-4314: - [~tabish] had a great observation to suggest that with local producers keeping local consumers busy, messages on the upstream will be stranded b/c the local queue will never be empty. That is fair, and I think a solution is to replace the check for empty with a check for pendingMessageCount == 0, such that if we have spare capacity, we pull a batch. If local producers are keeping us full, we will still leave the messages stranded, but in that case we are already at capacity. I think that is a better match. thoughts? > Federation, support consumerWindowSize zero and federate in batches only when > the local queue is empty > -- > > Key: ARTEMIS-4314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4314 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Dual queue federation, where clusters federate in both direction can suffer > from message flip flopping once the priority adjustment kicks in. > If there is a large backlog, the lower priority federation consumer is in > play once all of the local consumer credit is exhausted and the backlog can > drain to the other cluster. > If demand is low there, the process can repeat. limiting the rate of the > federation consumer can help but it is not ideal b/c when there is no local > demand, we want to have a high rate of migration. > > A possible solution is to have the federation consumer manage its own credit > and only flow messages when the local queue is empty. Then flow a batch of > messages, and await again that the local queue is empty. In this way, there > is no thundering heard effect, but there is also fast migration of messages > once there is demand. > the consumerWindowSize=0 is already in play for consumer.receive calls and > there is already a defaultConsumerWindowSize for an address. These can be > combined to realise batchFederationOnEmpty semantics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4314) Federation, support consumerWindowSize zero and federate in batches only when the local queue is empty
Gary Tully created ARTEMIS-4314: --- Summary: Federation, support consumerWindowSize zero and federate in batches only when the local queue is empty Key: ARTEMIS-4314 URL: https://issues.apache.org/jira/browse/ARTEMIS-4314 Project: ActiveMQ Artemis Issue Type: Improvement Components: Federation Affects Versions: 2.28.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.29.0 Dual queue federation, where clusters federate in both direction can suffer from message flip flopping once the priority adjustment kicks in. If there is a large backlog, the lower priority federation consumer is in play once all of the local consumer credit is exhausted and the backlog can drain to the other cluster. If demand is low there, the process can repeat. limiting the rate of the federation consumer can help but it is not ideal b/c when there is no local demand, we want to have a high rate of migration. A possible solution is to have the federation consumer manage its own credit and only flow messages when the local queue is empty. Then flow a batch of messages, and await again that the local queue is empty. In this way, there is no thundering heard effect, but there is also fast migration of messages once there is demand. the consumerWindowSize=0 is already in play for consumer.receive calls and there is already a defaultConsumerWindowSize for an address. These can be combined to realise batchFederationOnEmpty semantics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4257) artemis run - allow isolation class loader to be extended
[ https://issues.apache.org/jira/browse/ARTEMIS-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730104#comment-17730104 ] Gary Tully edited comment on ARTEMIS-4257 at 6/12/23 2:12 PM: -- -it may be easier to invert the problem and provide a way to extend the isolation class loader, with a system property that is a list of file urls to append to the classpath.- -in that way the burden of creating the classpath remains with artemis run, but it is extensible for use by an agent or for some third party jar.- --Disolation.classloader.ext=/app/vol/agent.jar,/app/lib- not a flyer, the root problem is the different classloader, to have an agent booted from the classpath see artemis, the isloation classloader needs to be disabled. was (Author: gtully): it may be easier to invert the problem and provide a way to extend the isolation class loader, with a system property that is a list of file urls to append to the classpath. in that way the burden of creating the classpath remains with artemis run, but it is extensible for use by an agent or for some third party jar. -Disolation.classloader.ext=/app/vol/agent.jar,/app/lib > artemis run - allow isolation class loader to be extended > - > > Key: ARTEMIS-4257 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4257 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.28.0 >Reporter: Gary Tully >Priority: Major > > When using artemis with a jvm agent that needs to interact with the broker, > the broker api classes need to be on the jvm classpath. > At the moment, the Artemis run command always executes the broker main with > an isolating classloader that only peeks at the lib and lib/extra dirs. The > only entry on the classpath is the boot jar. This makes sense in a shared > environment, isolation is good. > > In a container, where there is full control of the env, it makes sense to be > able to trust the classpath, and a single classloader allows any agent > dependencies to easily found/resolved. > > The underlying use case is the jolokia jvm agent integrated with the artemis > jaas callback handler, such that the agent can properly integrate with broker > auth/authz > > the ask is for a simple way to disable or extend the isolation classloader, > either a system property of command line option. The system property may be > the simplest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4257) artemis run - allow isolation class loader to be disabled
[ https://issues.apache.org/jira/browse/ARTEMIS-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4257: Summary: artemis run - allow isolation class loader to be disabled (was: artemis run - allow isolation class loader to be extended) > artemis run - allow isolation class loader to be disabled > - > > Key: ARTEMIS-4257 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4257 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.28.0 >Reporter: Gary Tully >Priority: Major > > When using artemis with a jvm agent that needs to interact with the broker, > the broker api classes need to be on the jvm classpath. > At the moment, the Artemis run command always executes the broker main with > an isolating classloader that only peeks at the lib and lib/extra dirs. The > only entry on the classpath is the boot jar. This makes sense in a shared > environment, isolation is good. > > In a container, where there is full control of the env, it makes sense to be > able to trust the classpath, and a single classloader allows any agent > dependencies to easily found/resolved. > > The underlying use case is the jolokia jvm agent integrated with the artemis > jaas callback handler, such that the agent can properly integrate with broker > auth/authz > > the ask is for a simple way to disable or extend the isolation classloader, > either a system property of command line option. The system property may be > the simplest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4257) artemis run - allow isolation class loader to be extended
[ https://issues.apache.org/jira/browse/ARTEMIS-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4257: Description: When using artemis with a jvm agent that needs to interact with the broker, the broker api classes need to be on the jvm classpath. At the moment, the Artemis run command always executes the broker main with an isolating classloader that only peeks at the lib and lib/extra dirs. The only entry on the classpath is the boot jar. This makes sense in a shared environment, isolation is good. In a container, where there is full control of the env, it makes sense to be able to trust the classpath, and a single classloader allows any agent dependencies to easily found/resolved. The underlying use case is the jolokia jvm agent integrated with the artemis jaas callback handler, such that the agent can properly integrate with broker auth/authz the ask is for a simple way to disable or extend the isolation classloader, either a system property of command line option. The system property may be the simplest. was: When using artemis with a jvm agent that needs to interact with the broker, the broker api classes need to be on the jvm classpath. At the moment, the Artemis run command always executes the broker main with an isolating classloader that only peeks at the lib and lib/extra dirs. The only entry on the classpath is the boot jar. This makes sense in a shared environment, isolation is good. In a container, where there is full control of the env, it makes sense to be able to trust the classpath, and a single classloader allows any agent dependencies to easily found/resolved. The underlying use case is the jolokia jvm agent integrated with the artemis jaas callback handler, such that the agent can properly integrate with broker auth/authz the ask is for a simple way to disable the isolation classloader, either a system property of command line option. The system property may be the simplest. > artemis run - allow isolation class loader to be extended > - > > Key: ARTEMIS-4257 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4257 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.28.0 >Reporter: Gary Tully >Priority: Major > > When using artemis with a jvm agent that needs to interact with the broker, > the broker api classes need to be on the jvm classpath. > At the moment, the Artemis run command always executes the broker main with > an isolating classloader that only peeks at the lib and lib/extra dirs. The > only entry on the classpath is the boot jar. This makes sense in a shared > environment, isolation is good. > > In a container, where there is full control of the env, it makes sense to be > able to trust the classpath, and a single classloader allows any agent > dependencies to easily found/resolved. > > The underlying use case is the jolokia jvm agent integrated with the artemis > jaas callback handler, such that the agent can properly integrate with broker > auth/authz > > the ask is for a simple way to disable or extend the isolation classloader, > either a system property of command line option. The system property may be > the simplest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4257) artemis run - allow isolation class loader to be extended
[ https://issues.apache.org/jira/browse/ARTEMIS-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4257: Summary: artemis run - allow isolation class loader to be extended (was: artemis run - allow isolation class loader to be disabled) > artemis run - allow isolation class loader to be extended > - > > Key: ARTEMIS-4257 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4257 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.28.0 >Reporter: Gary Tully >Priority: Major > > When using artemis with a jvm agent that needs to interact with the broker, > the broker api classes need to be on the jvm classpath. > At the moment, the Artemis run command always executes the broker main with > an isolating classloader that only peeks at the lib and lib/extra dirs. The > only entry on the classpath is the boot jar. This makes sense in a shared > environment, isolation is good. > > In a container, where there is full control of the env, it makes sense to be > able to trust the classpath, and a single classloader allows any agent > dependencies to easily found/resolved. > > The underlying use case is the jolokia jvm agent integrated with the artemis > jaas callback handler, such that the agent can properly integrate with broker > auth/authz > > the ask is for a simple way to disable the isolation classloader, either a > system property of command line option. The system property may be the > simplest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4257) artemis run - allow isolation class loader to be disabled
[ https://issues.apache.org/jira/browse/ARTEMIS-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730104#comment-17730104 ] Gary Tully commented on ARTEMIS-4257: - it may be easier to invert the problem and provide a way to extend the isolation class loader, with a system property that is a list of file urls to append to the classpath. in that way the burden of creating the classpath remains with artemis run, but it is extensible for use by an agent or for some third party jar. -Disolation.classloader.ext=/app/vol/agent.jar,/app/lib > artemis run - allow isolation class loader to be disabled > - > > Key: ARTEMIS-4257 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4257 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.28.0 >Reporter: Gary Tully >Priority: Major > > When using artemis with a jvm agent that needs to interact with the broker, > the broker api classes need to be on the jvm classpath. > At the moment, the Artemis run command always executes the broker main with > an isolating classloader that only peeks at the lib and lib/extra dirs. The > only entry on the classpath is the boot jar. This makes sense in a shared > environment, isolation is good. > > In a container, where there is full control of the env, it makes sense to be > able to trust the classpath, and a single classloader allows any agent > dependencies to easily found/resolved. > > The underlying use case is the jolokia jvm agent integrated with the artemis > jaas callback handler, such that the agent can properly integrate with broker > auth/authz > > the ask is for a simple way to disable the isolation classloader, either a > system property of command line option. The system property may be the > simplest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4284) Openwire prefetched messages can be out of order for a single consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4284: Description: It is an anti pattern, but a new consumer per message loop can fail with openwire. the remove is non blocking, so a new consumer can co exist with the async cancel/add sorted of the previpous consumer. This breaks ordering that is required for the delivery count logic around unconsumed prefetched messages. the workaround is to use prefetch=1 but the underlying problem is real, in 5.x the cancel/add_sorted is done in the same thread as remove. In artemis, the storage manager handles this async. A fix is to wait for the operation context complete on handling the removeConsumer command. was: It is an anti pattern, but a new consumer per message loop can fail with openwire. the remove is non blocking, so a new consumer can co exist with the async cancel/add sorted of the previpous consumer. This breaks ordering that is required for the delivery count logic around unconsumed prefetched messages. the workaround is to use prefetch=1 but the underlying problem is real, in 5.x the cancel/add_sorted is done in the same thread as remove. In artemis, the storage manager handles this async. A potential fix is to wait for the operation context complete on handling the removeConsumer command. > Openwire prefetched messages can be out of order for a single consumer > -- > > Key: ARTEMIS-4284 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4284 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: OpenWire >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > > It is an anti pattern, but a new consumer per message loop can fail with > openwire. the remove is non blocking, so a new consumer can co exist with the > async cancel/add sorted of the previpous consumer. This breaks ordering that > is required for the delivery count logic around unconsumed prefetched > messages. > the workaround is to use prefetch=1 but the underlying problem is real, in > 5.x the cancel/add_sorted is done in the same thread as remove. In artemis, > the storage manager handles this async. > A fix is to wait for the operation context complete on handling the > removeConsumer command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4285) Disable Redelivery Persistence for new broker installations.
[ https://issues.apache.org/jira/browse/ARTEMIS-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724202#comment-17724202 ] Gary Tully commented on ARTEMIS-4285: - It may make sense to do this just on the increment from 0->1 to support a persistent redelivery flag. That is what we did in 5.x to avoid too much overhead but still be usefull. see: https://issues.apache.org/jira/browse/AMQ-5068?focusedCommentId=13947821=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13947821 > Disable Redelivery Persistence for new broker installations. > > > Key: ARTEMIS-4285 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4285 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > > We should allow disabling persisted redelivery on messages. > Every time a message is redelivery, and scheduled redelivery is used, an > update record is stored in the broker. > This may add a big burden in the journal or jdbc journal. > We will keep this as true by default (in java) however new broker.xml > configuration will have this as false, so we will keep current users' > expectation while setting this to false for any new broker installation. > This is a borderline between bug and improvement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4284) Openwire prefetched messages can be out of order for a single consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-4284. - Resolution: Fixed > Openwire prefetched messages can be out of order for a single consumer > -- > > Key: ARTEMIS-4284 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4284 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: OpenWire >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > > It is an anti pattern, but a new consumer per message loop can fail with > openwire. the remove is non blocking, so a new consumer can co exist with the > async cancel/add sorted of the previpous consumer. This breaks ordering that > is required for the delivery count logic around unconsumed prefetched > messages. > the workaround is to use prefetch=1 but the underlying problem is real, in > 5.x the cancel/add_sorted is done in the same thread as remove. In artemis, > the storage manager handles this async. > A potential fix is to wait for the operation context complete on handling the > removeConsumer command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4284) Openwire prefetched messages can be out of order for a single consumer
Gary Tully created ARTEMIS-4284: --- Summary: Openwire prefetched messages can be out of order for a single consumer Key: ARTEMIS-4284 URL: https://issues.apache.org/jira/browse/ARTEMIS-4284 Project: ActiveMQ Artemis Issue Type: Improvement Components: OpenWire Affects Versions: 2.28.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.29.0 It is an anti pattern, but a new consumer per message loop can fail with openwire. the remove is non blocking, so a new consumer can co exist with the async cancel/add sorted of the previpous consumer. This breaks ordering that is required for the delivery count logic around unconsumed prefetched messages. the workaround is to use prefetch=1 but the underlying problem is real, in 5.x the cancel/add_sorted is done in the same thread as remove. In artemis, the storage manager handles this async. A potential fix is to wait for the operation context complete on handling the removeConsumer command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
