[jira] [Created] (AMQ-9473) Client SSL Socket configuration fails while settings parameters
Jukka Aalto created AMQ-9473:
Summary: Client SSL Socket configuration fails while settings
parameters
Key: AMQ-9473
URL: https://issues.apache.org/jira/browse/AMQ-9473
Project: ActiveMQ Classic
Issue Type: Bug
Affects Versions: 6.0.1
Environment: Windows and Java 21
Reporter: Jukka Aalto
Client connection creation fails when setting socket parameters.
Exception was thrown, when I tried to set enabledProtocols parameter using url:
ssl://127.0.0.1:12345?socket.enabledProtocols=TLSv1.3
Exception is also thrown, when using tcpNoDelay parameter. It is thrown
probably with most of the parameters related to sockets.
Here is the exception thrown:
{code:java}
java.lang.reflect.InaccessibleObjectException: Unable to make public void
sun.security.ssl.SSLSocketImpl.setEnabledProtocols(java.lang.String[])
accessible: module java.base does not "exports sun.security.ssl" to unnamed
module @48f2bd5b
13:22:43.976 [main] ERROR org.apache.activemq.util.IntrospectionSupport - Could
not set property enabledProtocols on SSLSocket[hostname=127.0.0.1, port=12345,
Session(...)]
at
java.lang.reflect.AccessibleObject.throwInaccessibleObjectException(AccessibleObject.java:391)
~[?:?]
at
java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:367)
~[?:?]
at
java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:315)
~[?:?]
at java.lang.reflect.Method.checkCanSetAccessible(Method.java:203)
~[?:?]
at java.lang.reflect.Method.setAccessible(Method.java:197) ~[?:?]
at
org.apache.activemq.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:184)
[test/:6.0.1]
at
org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:155)
[test/:6.0.1]
at
org.apache.activemq.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:140)
[test/:6.0.1]
at
org.apache.activemq.transport.tcp.TcpTransport.initialiseSocket(TcpTransport.java:449)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.transport.tcp.SslTransport.initialiseSocket(SslTransport.java:137)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.transport.tcp.TcpTransport.connect(TcpTransport.java:542)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.transport.tcp.TcpTransport.doStart(TcpTransport.java:488)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.transport.AbstractInactivityMonitor.start(AbstractInactivityMonitor.java:172)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.transport.InactivityMonitor.start(InactivityMonitor.java:52)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:72)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:399)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:349)
[activemq-client-6.0.1.jar:6.0.1]
at
org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:245)
[activemq-client-6.0.1.jar:6.0.1]
at
test.ActiveMQClientSSLSocketParameter.main(ActiveMQClientSSLSocketParameter.java:25)
[test/:?]
{code}
Here is example to reproduce issue:
{code:java}
package test;
import java.io.IOException;
import java.net.ServerSocket;
import org.apache.activemq.ActiveMQSslConnectionFactory;
public class ActiveMQClientSSLSocketParameter {
public static void main(String[] args) throws Exception{
// Dummy server
ServerSocket server = new ServerSocket(12345);
new Thread(() -> {
try {
var client = server.accept();
client.close();
}catch(Exception e) {
e.printStackTrace();
}
}).start();
var factory = new
ActiveMQSslConnectionFactory("ssl://127.0.0.1:12345?socket.enabledProtocols=TLSv1.3");
// or socket.enabledCipherSuites=TLS_AES_256_GCM_SHA384
try(var connection = factory.createConnection()){
//NOP
} finally {
[jira] [Updated] (ARTEMIS-4715) Consuming from wildcard queues stopped working with 2.33.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-4715: --- Issue Type: Bug (was: Task) > Consuming from wildcard queues stopped working with 2.33.0 > -- > > Key: ARTEMIS-4715 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4715 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Otavio Rodolfo Piske >Priority: Major > Attachments: camel-activemq-test-artemis-2.32.log, > camel-activemq-test-artemis-2.33.log > > > One of our > [tests|https://github.com/apache/camel/blob/main/components/camel-activemq/src/test/java/org/apache/camel/component/activemq/ActiveMQRouteIT.java#L66-L71] > that [consumes data from a wildcard > queue|https://github.com/apache/camel/blob/main/components/camel-activemq/src/test/java/org/apache/camel/component/activemq/ActiveMQRouteIT.java#L111-L113] > has stopped working after migrating to Artemis 2.33.0. > > This test works without problems when using Artemis 2.32.0. I attached the > logs from executing the test with 2.32 and 2.33. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4715) Consuming from wildcard queues stopped working with 2.33.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-4715: --- Issue Type: Task (was: Bug) > Consuming from wildcard queues stopped working with 2.33.0 > -- > > Key: ARTEMIS-4715 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4715 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.33.0 >Reporter: Otavio Rodolfo Piske >Priority: Major > Attachments: camel-activemq-test-artemis-2.32.log, > camel-activemq-test-artemis-2.33.log > > > One of our > [tests|https://github.com/apache/camel/blob/main/components/camel-activemq/src/test/java/org/apache/camel/component/activemq/ActiveMQRouteIT.java#L66-L71] > that [consumes data from a wildcard > queue|https://github.com/apache/camel/blob/main/components/camel-activemq/src/test/java/org/apache/camel/component/activemq/ActiveMQRouteIT.java#L111-L113] > has stopped working after migrating to Artemis 2.33.0. > > This test works without problems when using Artemis 2.32.0. I attached the > logs from executing the test with 2.32 and 2.33. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9472) Wildcard publisher auto-creates wildcard topic and breaks authorization
[ https://issues.apache.org/jira/browse/AMQ-9472?focusedWorklogId=913540=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913540 ] ASF GitHub Bot logged work on AMQ-9472: --- Author: ASF GitHub Bot Created on: 08/Apr/24 23:46 Start Date: 08/Apr/24 23:46 Worklog Time Spent: 10m Work Description: mattrpav commented on PR #1198: URL: https://github.com/apache/activemq/pull/1198#issuecomment-2043874595 I think that the behavior should match the destination policy. 1. Wildcard 2. Fully qualified name (authoritative) I agree, it should be a new flag since we would not want to change behavior on existing users. Issue Time Tracking --- Worklog Id: (was: 913540) Time Spent: 1h (was: 50m) > Wildcard publisher auto-creates wildcard topic and breaks authorization > --- > > Key: AMQ-9472 > URL: https://issues.apache.org/jira/browse/AMQ-9472 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Reporter: Albertas Vyšniauskas >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Hi, > after publishing a message to wildcard topic, a wildcard topic is > auto-created and interacts poorly with authorization rules. > Suppose that authorization map contains the following entries: > > > Admin creates "A.B" topic and publishes a message to "A.>" causing > auto-creation of "A.>" topic. > User attempts to consume "A.B" topic, but receives "User user is not > authorized to read from: topic://A.>" error. > I asked on user mailing list if wildcard publishing is supposed to work at > all, as I could not find any documentation about that. Unfortunately I did > not receive any response, so I have to assume that it does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (AMQ-9472) Wildcard publisher auto-creates wildcard topic and breaks authorization
[ https://issues.apache.org/jira/browse/AMQ-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835076#comment-17835076 ] Christopher L. Shannon edited comment on AMQ-9472 at 4/8/24 11:38 PM: -- I think this issue should be closed as "Not a Problem" or 'Won't Fix" and I explained why on the PR: [https://github.com/apache/activemq/pull/1198|https://github.com/apache/activemq/pull/1198#issuecomment-2043752900] The reason is that we are not going to change how consumers work with regards to adding multiple subscriptions if it matches a wildcard *Edit:* I think if we wanted to do anything here it would be more considered a new feature or improvement and not a bug fix and need to be configurable as explained in: https://github.com/apache/activemq/pull/1198#issuecomment-2043856614 was (Author: christopher.l.shannon): I think this issue should be closed as "Not a Problem" or 'Won't Fix" and I explained why on the PR: [https://github.com/apache/activemq/pull/1198|https://github.com/apache/activemq/pull/1198#issuecomment-2043752900] The reason is that we are not going to change how consumers work with regards to adding multiple subscriptions if it matches a wildcard > Wildcard publisher auto-creates wildcard topic and breaks authorization > --- > > Key: AMQ-9472 > URL: https://issues.apache.org/jira/browse/AMQ-9472 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Reporter: Albertas Vyšniauskas >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Hi, > after publishing a message to wildcard topic, a wildcard topic is > auto-created and interacts poorly with authorization rules. > Suppose that authorization map contains the following entries: > > > Admin creates "A.B" topic and publishes a message to "A.>" causing > auto-creation of "A.>" topic. > User attempts to consume "A.B" topic, but receives "User user is not > authorized to read from: topic://A.>" error. > I asked on user mailing list if wildcard publishing is supposed to work at > all, as I could not find any documentation about that. Unfortunately I did > not receive any response, so I have to assume that it does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9472) Wildcard publisher auto-creates wildcard topic and breaks authorization
[ https://issues.apache.org/jira/browse/AMQ-9472?focusedWorklogId=913539=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913539 ] ASF GitHub Bot logged work on AMQ-9472: --- Author: ASF GitHub Bot Created on: 08/Apr/24 23:37 Start Date: 08/Apr/24 23:37 Worklog Time Spent: 10m Work Description: cshannon commented on PR #1198: URL: https://github.com/apache/activemq/pull/1198#issuecomment-2043856614 The only other thing i can think of is we could technically change the behavior of the authorization broker plugin because you could make an argument that any matching wildcard should implicitly be authorized if it matches a topic. In this case by publishing to a wildcard the intent is anything that matches gets it so should be authorized. However, the problem with changing that would be a change in the current authorization behavior which is not good for existing users not expecting it. So I think that we'd need to have a config option or an extension to prevent unintended consequences since it's been like this for a long time. So I would view any changes here more as an enhancement or improvement. If we made it configurable I think it would need to be something where the config would be described as "implicitly grant matching wildcard destinations" or something like that and probably a new feature and not a bug fix release. Subscribing to a wildcard destination would also need to be explored as well. Issue Time Tracking --- Worklog Id: (was: 913539) Time Spent: 50m (was: 40m) > Wildcard publisher auto-creates wildcard topic and breaks authorization > --- > > Key: AMQ-9472 > URL: https://issues.apache.org/jira/browse/AMQ-9472 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Reporter: Albertas Vyšniauskas >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Hi, > after publishing a message to wildcard topic, a wildcard topic is > auto-created and interacts poorly with authorization rules. > Suppose that authorization map contains the following entries: > > > Admin creates "A.B" topic and publishes a message to "A.>" causing > auto-creation of "A.>" topic. > User attempts to consume "A.B" topic, but receives "User user is not > authorized to read from: topic://A.>" error. > I asked on user mailing list if wildcard publishing is supposed to work at > all, as I could not find any documentation about that. Unfortunately I did > not receive any response, so I have to assume that it does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9472) Wildcard publisher auto-creates wildcard topic and breaks authorization
[ https://issues.apache.org/jira/browse/AMQ-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835076#comment-17835076 ] Christopher L. Shannon commented on AMQ-9472: - I think this issue should be closed as "Not a Problem" or 'Won't Fix" and I explained why on the PR: [https://github.com/apache/activemq/pull/1198|https://github.com/apache/activemq/pull/1198#issuecomment-2043752900] The reason is that we are not going to change how consumers work with regards to adding multiple subscriptions if it matches a wildcard > Wildcard publisher auto-creates wildcard topic and breaks authorization > --- > > Key: AMQ-9472 > URL: https://issues.apache.org/jira/browse/AMQ-9472 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Reporter: Albertas Vyšniauskas >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Hi, > after publishing a message to wildcard topic, a wildcard topic is > auto-created and interacts poorly with authorization rules. > Suppose that authorization map contains the following entries: > > > Admin creates "A.B" topic and publishes a message to "A.>" causing > auto-creation of "A.>" topic. > User attempts to consume "A.B" topic, but receives "User user is not > authorized to read from: topic://A.>" error. > I asked on user mailing list if wildcard publishing is supposed to work at > all, as I could not find any documentation about that. Unfortunately I did > not receive any response, so I have to assume that it does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9472) Wildcard publisher auto-creates wildcard topic and breaks authorization
[ https://issues.apache.org/jira/browse/AMQ-9472?focusedWorklogId=913536=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913536 ] ASF GitHub Bot logged work on AMQ-9472: --- Author: ASF GitHub Bot Created on: 08/Apr/24 23:09 Start Date: 08/Apr/24 23:09 Worklog Time Spent: 10m Work Description: cshannon commented on PR #1198: URL: https://github.com/apache/activemq/pull/1198#issuecomment-2043790765 In terms of working around this, the options are pretty much: 1. If you are going to create topics then you need to make sure you have proper ACLs set up for those topics (including matching subscriptions on wildcards) that consumers might subscribe to. In this case you could add read ACLs for A.> for the users group. 2. You could always customize the authorization logic by implementing your own plugin or overriding/extending the `AuthorizationBroker` and `AuthorizationDestinationInterceptor` Issue Time Tracking --- Worklog Id: (was: 913536) Time Spent: 40m (was: 0.5h) > Wildcard publisher auto-creates wildcard topic and breaks authorization > --- > > Key: AMQ-9472 > URL: https://issues.apache.org/jira/browse/AMQ-9472 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Reporter: Albertas Vyšniauskas >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Hi, > after publishing a message to wildcard topic, a wildcard topic is > auto-created and interacts poorly with authorization rules. > Suppose that authorization map contains the following entries: > > > Admin creates "A.B" topic and publishes a message to "A.>" causing > auto-creation of "A.>" topic. > User attempts to consume "A.B" topic, but receives "User user is not > authorized to read from: topic://A.>" error. > I asked on user mailing list if wildcard publishing is supposed to work at > all, as I could not find any documentation about that. Unfortunately I did > not receive any response, so I have to assume that it does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (AMQ-9472) Wildcard publisher auto-creates wildcard topic and breaks authorization
[ https://issues.apache.org/jira/browse/AMQ-9472?focusedWorklogId=913534=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913534 ] ASF GitHub Bot logged work on AMQ-9472: --- Author: ASF GitHub Bot Created on: 08/Apr/24 22:36 Start Date: 08/Apr/24 22:36 Worklog Time Spent: 10m Work Description: cshannon commented on PR #1198: URL: https://github.com/apache/activemq/pull/1198#issuecomment-2043752900 This is not really a bug to me, it's a side effect of how wild card subscriptions work in the broker. The issue here is not with the authorization plugin or logic but with how subscriptions currently work. When consumers are created, subscriptions get added for all matching destinations. In this case, there are 2 matching destinations because of the wildcard destination that was auto created. When creating a consumer on Topic A.B, first the new consumer is [authorized](https://github.com/apache/activemq/blob/e025e443e65d4bd3c2c27f11d6caa7bfbd2c9626/activemq-broker/src/main/java/org/apache/activemq/security/AuthorizationBroker.java#L148) on that destination and that passes. But then later on the addSubscription() is called for both destinations to add two subscriptions for the new consumer...one on A.B which is properly [authorized](https://github.com/apache/activemq/blob/e025e443e65d4bd3c2c27f11d6caa7bfbd2c9626/activemq-broker/src/main/java/org/apache/activemq/security/AuthorizationDestinationFilter.java#L40) and then another on A.> which is not authorized because there's no proper ACLs for "users" when adding the subscription for A.> So this is just how the broker currently works to handle wildcard subscriptions, since you are publishing to a wildcard topic then any subscription that matches needs to also subscribe tot he wildcard to get that message. Issue Time Tracking --- Worklog Id: (was: 913534) Time Spent: 0.5h (was: 20m) > Wildcard publisher auto-creates wildcard topic and breaks authorization > --- > > Key: AMQ-9472 > URL: https://issues.apache.org/jira/browse/AMQ-9472 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Reporter: Albertas Vyšniauskas >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Hi, > after publishing a message to wildcard topic, a wildcard topic is > auto-created and interacts poorly with authorization rules. > Suppose that authorization map contains the following entries: > > > Admin creates "A.B" topic and publishes a message to "A.>" causing > auto-creation of "A.>" topic. > User attempts to consume "A.B" topic, but receives "User user is not > authorized to read from: topic://A.>" error. > I asked on user mailing list if wildcard publishing is supposed to work at > all, as I could not find any documentation about that. Unfortunately I did > not receive any response, so I have to assume that it does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-5130) If a STOMP listener attempts to connect to an OpenWire transport connector the broker dies
[
https://issues.apache.org/jira/browse/AMQ-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835050#comment-17835050
]
Christopher L. Shannon commented on AMQ-5130:
-
I'm unassigning target versions for this because this Issue has been open for
10 years and continuously moved to the next version and ignored. I think at
this point it needs to be re-evaluated to see if it's still a problem and if it
is then decide if it will actually be fixed or not, or otherwise we should
close the issue.
> If a STOMP listener attempts to connect to an OpenWire transport connector
> the broker dies
> --
>
> Key: AMQ-5130
> URL: https://issues.apache.org/jira/browse/AMQ-5130
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.13
> Environment: Linux Centos 6.4 Apache ActiveMQ 5.9.0, Apache ActiveMQ
> demo STOMP listener
>Reporter: Matthew Western
>Assignee: Matt Pavlovich
>Priority: Major
> Attachments: AMQ5130.patch
>
>
> If a STOMP listener attempts to connect to the broker with an NIO OpenWire
> transport connector URI the broker dies (The JVM terminates with an out of
> memory error).
> I have consistently reproduced this using the test STOMP listener provided
> with 5.9.0. I have not checked to see what happens with the STOMP publisher
> but I imagine the results would be the same.
> I discovered this due to accidentally using the wrong URI with my STOMP
> client.
> I think this is a serious issue as it could be exploited as a DOS attack on
> known broker URIs.
> My configuration file is as follows:
> {code:xml}
> http://activemq.apache.org/schema/core; brokerName="broker2"
> dataDirectory="${activemq.data}" networkConnectorStartAsync="true"
> advisorySupport="true">
>
>
>
>
> advisoryForConsumed="true" advisoryForDelivery="true">
>
> useQueueForQueueMessages="true" />
>
>
> advisoryForConsumed="true" advisoryForDelivery="true">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"
> />
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"
> />
>
>
>
>
> {code}
> The listener terminates immediately upon starting with:
> {noformat}
> cannot sysread(): Connection reset by peer{noformat}
> And the broker JVM dies with the following hs_errpid*.log error:
> {noformat}
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (malloc) failed to allocate 693723136 bytes for
> committing reserved memory.
> # Possible reasons:
> # The system is out of physical RAM or swap space
> # In 32 bit mode, the process size limit was hit
> # Possible solutions:
> # Reduce memory load on the system
> # Increase physical memory or swap space
> # Check if swap backing store is full
> # Use 64 bit Java on a 64 bit OS
> # Decrease Java heap size (-Xmx/-Xms)
> # Decrease number of Java threads
> # Decrease Java thread stack sizes (-Xss)
> # Set larger code cache with -XX:ReservedCodeCacheSize=
> # This output file may be truncated or incomplete.
> #
> # Out of Memory Error (os_linux.cpp:2718), pid=8783, tid=140478943950592
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
> 1.7.0_45-b18)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
> linux-amd64 compressed oops)
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> --- T H R E A D ---
> Current thread (0x7fc3c8086000): VMThread [stack:
> 0x7fc3cd7d7000,0x7fc3cd8d8000] [id=8785]
> Stack: [0x7fc3cd7d7000,0x7fc3cd8d8000], sp=0x7fc3cd8d62d0, free
> space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0x992c8a] VMError::report_and_die()+0x2ea
> V [libjvm.so+0x49319b] report_vm_out_of_memory(char const*, int, unsigned
> long, char const*)+0x9b
> V [libjvm.so+0x81310e] os::Linux::commit_memory_impl(char*, unsigned long,
> bool)+0xfe
> V [libjvm.so+0x8135bf] os::Linux::commit_memory_impl(char*, unsigned long,
> unsigned long, bool)+0x4f
> V [libjvm.so+0x81377c] os::pd_commit_memory(char*, unsigned long, unsigned
> long, bool)+0xc
> V [libjvm.so+0x80d86a] os::commit_memory(char*, unsigned long, unsigned long,
> bool)+0x2a
> V [libjvm.so+0x98e5d9] VirtualSpace::expand_by(unsigned long, bool)+0x1c9
> V [libjvm.so+0x571725] OneContigSpaceCardGeneration::grow_by(unsigned
> long)+0x25
> V [libjvm.so+0x571b3e]
[jira] [Updated] (AMQ-5130) If a STOMP listener attempts to connect to an OpenWire transport connector the broker dies
[
https://issues.apache.org/jira/browse/AMQ-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-5130:
Fix Version/s: (was: 6.2.0)
(was: 5.18.5)
> If a STOMP listener attempts to connect to an OpenWire transport connector
> the broker dies
> --
>
> Key: AMQ-5130
> URL: https://issues.apache.org/jira/browse/AMQ-5130
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.13
> Environment: Linux Centos 6.4 Apache ActiveMQ 5.9.0, Apache ActiveMQ
> demo STOMP listener
>Reporter: Matthew Western
>Assignee: Matt Pavlovich
>Priority: Major
> Attachments: AMQ5130.patch
>
>
> If a STOMP listener attempts to connect to the broker with an NIO OpenWire
> transport connector URI the broker dies (The JVM terminates with an out of
> memory error).
> I have consistently reproduced this using the test STOMP listener provided
> with 5.9.0. I have not checked to see what happens with the STOMP publisher
> but I imagine the results would be the same.
> I discovered this due to accidentally using the wrong URI with my STOMP
> client.
> I think this is a serious issue as it could be exploited as a DOS attack on
> known broker URIs.
> My configuration file is as follows:
> {code:xml}
> http://activemq.apache.org/schema/core; brokerName="broker2"
> dataDirectory="${activemq.data}" networkConnectorStartAsync="true"
> advisorySupport="true">
>
>
>
>
> advisoryForConsumed="true" advisoryForDelivery="true">
>
> useQueueForQueueMessages="true" />
>
>
> advisoryForConsumed="true" advisoryForDelivery="true">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"
> />
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"
> />
>
>
>
>
> {code}
> The listener terminates immediately upon starting with:
> {noformat}
> cannot sysread(): Connection reset by peer{noformat}
> And the broker JVM dies with the following hs_errpid*.log error:
> {noformat}
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (malloc) failed to allocate 693723136 bytes for
> committing reserved memory.
> # Possible reasons:
> # The system is out of physical RAM or swap space
> # In 32 bit mode, the process size limit was hit
> # Possible solutions:
> # Reduce memory load on the system
> # Increase physical memory or swap space
> # Check if swap backing store is full
> # Use 64 bit Java on a 64 bit OS
> # Decrease Java heap size (-Xmx/-Xms)
> # Decrease number of Java threads
> # Decrease Java thread stack sizes (-Xss)
> # Set larger code cache with -XX:ReservedCodeCacheSize=
> # This output file may be truncated or incomplete.
> #
> # Out of Memory Error (os_linux.cpp:2718), pid=8783, tid=140478943950592
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
> 1.7.0_45-b18)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
> linux-amd64 compressed oops)
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> --- T H R E A D ---
> Current thread (0x7fc3c8086000): VMThread [stack:
> 0x7fc3cd7d7000,0x7fc3cd8d8000] [id=8785]
> Stack: [0x7fc3cd7d7000,0x7fc3cd8d8000], sp=0x7fc3cd8d62d0, free
> space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0x992c8a] VMError::report_and_die()+0x2ea
> V [libjvm.so+0x49319b] report_vm_out_of_memory(char const*, int, unsigned
> long, char const*)+0x9b
> V [libjvm.so+0x81310e] os::Linux::commit_memory_impl(char*, unsigned long,
> bool)+0xfe
> V [libjvm.so+0x8135bf] os::Linux::commit_memory_impl(char*, unsigned long,
> unsigned long, bool)+0x4f
> V [libjvm.so+0x81377c] os::pd_commit_memory(char*, unsigned long, unsigned
> long, bool)+0xc
> V [libjvm.so+0x80d86a] os::commit_memory(char*, unsigned long, unsigned long,
> bool)+0x2a
> V [libjvm.so+0x98e5d9] VirtualSpace::expand_by(unsigned long, bool)+0x1c9
> V [libjvm.so+0x571725] OneContigSpaceCardGeneration::grow_by(unsigned
> long)+0x25
> V [libjvm.so+0x571b3e] OneContigSpaceCardGeneration::expand(unsigned long,
> unsigned long)+0x3e
> V [libjvm.so+0x571878]
> OneContigSpaceCardGeneration::expand_and_allocate(unsigned long, bool,
> bool)+0xc8
> V [libjvm.so+0x4270e4] GenCollectorPolicy::expand_heap_and_allocate(unsigned
> long, bool)+0xa4
> V [libjvm.so+0x428122]
[jira] [Work logged] (ARTEMIS-4498) Enable management for internal addresses & queues
[ https://issues.apache.org/jira/browse/ARTEMIS-4498?focusedWorklogId=913524=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913524 ] ASF GitHub Bot logged work on ARTEMIS-4498: --- Author: ASF GitHub Bot Created on: 08/Apr/24 20:53 Start Date: 08/Apr/24 20:53 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4856: URL: https://github.com/apache/activemq-artemis/pull/4856#issuecomment-2043625204 @AntonRoskvist , @andytaylor can we settle with these changes? I added the "internal attribute" to the AddressControl as well. @andytaylor if you could take a look at the changes made to the web console here please? Issue Time Tracking --- Worklog Id: (was: 913524) Time Spent: 6h 50m (was: 6h 40m) > Enable management for internal addresses & queues > - > > Key: ARTEMIS-4498 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4498 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 6h 50m > Remaining Estimate: 0h > > Originally "internal" addresses and queues weren't meant to be exposed via > management. However, due to a bug where the "internal" attribute of a queue > was not persisted properly such queues have been exposed to management for a > long time. This was fixed via ARTEMIS-4396, but users still want the ability > to manage internal queues because it is extremely helpful when trying to > troubleshoot issues. Therefore, this functionality should be configurable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4717) Upgrade commons-configuration2 to 2.10.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835018#comment-17835018 ] ASF subversion and git services commented on ARTEMIS-4717: -- Commit 9583f844c17ff3463327f5e0ae209ef10cfa4c0f in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=9583f844c1 ] ARTEMIS-4717 Upgrade commons-configuration2 to 2.10.1 > Upgrade commons-configuration2 to 2.10.1 > > > Key: ARTEMIS-4717 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4717 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4717) Upgrade commons-configuration2 to 2.10.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4717?focusedWorklogId=913504=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913504 ] ASF GitHub Bot logged work on ARTEMIS-4717: --- Author: ASF GitHub Bot Created on: 08/Apr/24 19:01 Start Date: 08/Apr/24 19:01 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4877: URL: https://github.com/apache/activemq-artemis/pull/4877 Issue Time Tracking --- Worklog Id: (was: 913504) Time Spent: 20m (was: 10m) > Upgrade commons-configuration2 to 2.10.1 > > > Key: ARTEMIS-4717 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4717 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4510) Add auto-create-destination logic to diverts
[ https://issues.apache.org/jira/browse/ARTEMIS-4510?focusedWorklogId=913505=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913505 ] ASF GitHub Bot logged work on ARTEMIS-4510: --- Author: ASF GitHub Bot Created on: 08/Apr/24 19:01 Start Date: 08/Apr/24 19:01 Worklog Time Spent: 10m Work Description: clebertsuconic closed pull request #4681: ARTEMIS-4510 - Add auto-create-destination logic to diverts URL: https://github.com/apache/activemq-artemis/pull/4681 Issue Time Tracking --- Worklog Id: (was: 913505) Time Spent: 5h 20m (was: 5h 10m) > Add auto-create-destination logic to diverts > > > Key: ARTEMIS-4510 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4510 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 5h 20m > Remaining Estimate: 0h > > This enables the use of dynamic routing decisions within the transformer by > setting the message address. It also covers for a rare problem where if any > of the forwarding addresses are removed during runtime, such as from > auto-delete, the message would get silently dropped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARTEMIS-4718) Diverted messages are not properly routed on cluster remote bindings
[ https://issues.apache.org/jira/browse/ARTEMIS-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-4718. Resolution: Fixed this was fixed by anton.roskvist > Diverted messages are not properly routed on cluster remote bindings > > > Key: ARTEMIS-4718 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4718 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4718) Diverted messages are not properly routed on cluster remote bindings
[ https://issues.apache.org/jira/browse/ARTEMIS-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835016#comment-17835016 ] ASF subversion and git services commented on ARTEMIS-4718: -- Commit a723f634a28938b85326079efb4cdc02550be428 in activemq-artemis's branch refs/heads/main from AntonRoskvist [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a723f634a2 ] ARTEMIS-4718 Diverted messages are not propertly routed on cluster remote bindings > Diverted messages are not properly routed on cluster remote bindings > > > Key: ARTEMIS-4718 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4718 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4510) Add auto-create-destination logic to diverts
[ https://issues.apache.org/jira/browse/ARTEMIS-4510?focusedWorklogId=913502=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913502 ] ASF GitHub Bot logged work on ARTEMIS-4510: --- Author: ASF GitHub Bot Created on: 08/Apr/24 18:57 Start Date: 08/Apr/24 18:57 Worklog Time Spent: 10m Work Description: clebertsuconic closed pull request #4867: ARTEMIS-4510 - Add auto-create-destination logic to diverts URL: https://github.com/apache/activemq-artemis/pull/4867 Issue Time Tracking --- Worklog Id: (was: 913502) Time Spent: 5h (was: 4h 50m) > Add auto-create-destination logic to diverts > > > Key: ARTEMIS-4510 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4510 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 5h > Remaining Estimate: 0h > > This enables the use of dynamic routing decisions within the transformer by > setting the message address. It also covers for a rare problem where if any > of the forwarding addresses are removed during runtime, such as from > auto-delete, the message would get silently dropped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4510) Add auto-create-destination logic to diverts
[ https://issues.apache.org/jira/browse/ARTEMIS-4510?focusedWorklogId=913503=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913503 ] ASF GitHub Bot logged work on ARTEMIS-4510: --- Author: ASF GitHub Bot Created on: 08/Apr/24 18:57 Start Date: 08/Apr/24 18:57 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4867: URL: https://github.com/apache/activemq-artemis/pull/4867#issuecomment-2043460610 actually.. I pushed a commit Issue Time Tracking --- Worklog Id: (was: 913503) Time Spent: 5h 10m (was: 5h) > Add auto-create-destination logic to diverts > > > Key: ARTEMIS-4510 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4510 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 5h 10m > Remaining Estimate: 0h > > This enables the use of dynamic routing decisions within the transformer by > setting the message address. It also covers for a rare problem where if any > of the forwarding addresses are removed during runtime, such as from > auto-delete, the message would get silently dropped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4718) Diverted messages are not properly routed on cluster remote bindings
Clebert Suconic created ARTEMIS-4718: Summary: Diverted messages are not properly routed on cluster remote bindings Key: ARTEMIS-4718 URL: https://issues.apache.org/jira/browse/ARTEMIS-4718 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Clebert Suconic Assignee: Clebert Suconic -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARTEMIS-4717) Upgrade commons-configuration2 to 2.10.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino reassigned ARTEMIS-4717: Assignee: Domenico Francesco Bruscino > Upgrade commons-configuration2 to 2.10.1 > > > Key: ARTEMIS-4717 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4717 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4717) Upgrade commons-configuration2 to 2.10.1
[ https://issues.apache.org/jira/browse/ARTEMIS-4717?focusedWorklogId=913497=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913497 ] ASF GitHub Bot logged work on ARTEMIS-4717: --- Author: ASF GitHub Bot Created on: 08/Apr/24 17:55 Start Date: 08/Apr/24 17:55 Worklog Time Spent: 10m Work Description: brusdev opened a new pull request, #4877: URL: https://github.com/apache/activemq-artemis/pull/4877 (no comment) Issue Time Tracking --- Worklog Id: (was: 913497) Remaining Estimate: 0h Time Spent: 10m > Upgrade commons-configuration2 to 2.10.1 > > > Key: ARTEMIS-4717 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4717 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4717) Upgrade commons-configuration2 to 2.10.1
Domenico Francesco Bruscino created ARTEMIS-4717: Summary: Upgrade commons-configuration2 to 2.10.1 Key: ARTEMIS-4717 URL: https://issues.apache.org/jira/browse/ARTEMIS-4717 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Domenico Francesco Bruscino -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4716) Improve Jakarta Messaging / JMS documentation
[
https://issues.apache.org/jira/browse/ARTEMIS-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Martin updated ARTEMIS-4716:
---
Description:
I'm struggling to understand the instructions to use Artemis in the context of
Jakarta Messaging found at
[https://activemq.apache.org/components/artemis/documentation/latest/using-jms.html],
which perhaps could be updated / simplified / improved.
At the moment, I'm depending on {{artemis-jakarta-client}} and manually
instantiating {{{}ActiveMQConnectionFactory{}}}. While investigating a memory
leak that may come from my usage of ActiveMQ, I wanted to simplify this part
and rely on dependency injection instead. However, I don't begin to understand
how to do such thing.
My expectation was to be able to use the {{@Inject}} annotation to get a
reference to a {{{}ConnectionFactory{}}}, {{JMSContext}} or similar, and being
able to provide configuration such as broker address and credentials
{_}somewhere{_}, as to end up with a reference to a {{{}Connection{}}}, which
is ultimately what I need. Is this possible? What's the recommended way? Is
there any (working) reference examples?
was:
I'm struggling to understand the instructions to use Artemis in the context of
Jakarta Messaging found at
[https://activemq.apache.org/components/artemis/documentation/latest/using-jms.html],
which perhaps could be updated / simplified / improved.
At the moment, I'm depending on {{artemis-jakarta-client}} and manually
instantiating {{{}ActiveMQConnectionFactory{}}}. While investigating a memory
leak that may come from my usage of ActiveMQ, I wanted to simplify this part
and rely on dependency injection instead. However, I don't begin to understand
how to do such thing.
My expectation was to be able to use the {{@Inject}} annotation to get a
reference to a
{{{}ConnectionFactory{}}}, {{JMSContext}} or similar, and being able to provide
configuration such as broker address and credentials {_}somewhere{_}, as to end
up with a reference to a {{{}Connection{}}}, which is ultimately what I need.
Is this possible? What's the recommended way? Is there any (working) reference
examples?
> Improve Jakarta Messaging / JMS documentation
> -
>
> Key: ARTEMIS-4716
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4716
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: JMS
>Affects Versions: 2.33.0
>Reporter: Daniel Martin
>Priority: Minor
>
> I'm struggling to understand the instructions to use Artemis in the context
> of Jakarta Messaging found at
> [https://activemq.apache.org/components/artemis/documentation/latest/using-jms.html],
> which perhaps could be updated / simplified / improved.
> At the moment, I'm depending on {{artemis-jakarta-client}} and manually
> instantiating {{{}ActiveMQConnectionFactory{}}}. While investigating a memory
> leak that may come from my usage of ActiveMQ, I wanted to simplify this part
> and rely on dependency injection instead. However, I don't begin to
> understand how to do such thing.
> My expectation was to be able to use the {{@Inject}} annotation to get a
> reference to a {{{}ConnectionFactory{}}}, {{JMSContext}} or similar, and
> being able to provide configuration such as broker address and credentials
> {_}somewhere{_}, as to end up with a reference to a {{{}Connection{}}}, which
> is ultimately what I need. Is this possible? What's the recommended way? Is
> there any (working) reference examples?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4716) Improve Jakarta Messaging / JMS documentation
Daniel Martin created ARTEMIS-4716:
--
Summary: Improve Jakarta Messaging / JMS documentation
Key: ARTEMIS-4716
URL: https://issues.apache.org/jira/browse/ARTEMIS-4716
Project: ActiveMQ Artemis
Issue Type: Improvement
Components: JMS
Affects Versions: 2.33.0
Reporter: Daniel Martin
I'm struggling to understand the instructions to use Artemis in the context of
Jakarta Messaging found at
[https://activemq.apache.org/components/artemis/documentation/latest/using-jms.html],
which perhaps could be updated / simplified / improved.
At the moment, I'm depending on {{artemis-jakarta-client}} and manually
instantiating {{{}ActiveMQConnectionFactory{}}}. While investigating a memory
leak that may come from my usage of ActiveMQ, I wanted to simplify this part
and rely on dependency injection instead. However, I don't begin to understand
how to do such thing.
My expectation was to be able to use the {{@Inject}} annotation to get a
reference to a
{{{}ConnectionFactory{}}}, {{JMSContext}} or similar, and being able to provide
configuration such as broker address and credentials {_}somewhere{_}, as to end
up with a reference to a {{{}Connection{}}}, which is ultimately what I need.
Is this possible? What's the recommended way? Is there any (working) reference
examples?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4510) Add auto-create-destination logic to diverts
[ https://issues.apache.org/jira/browse/ARTEMIS-4510?focusedWorklogId=913484=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913484 ] ASF GitHub Bot logged work on ARTEMIS-4510: --- Author: ASF GitHub Bot Created on: 08/Apr/24 15:00 Start Date: 08/Apr/24 15:00 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4867: URL: https://github.com/apache/activemq-artemis/pull/4867#issuecomment-2042993128 @AntonRoskvist I pulled your changes, removed all the docs and stuff and pushed on main (I pushed as you). now you have to give a JIRA to your other change. it's probably easier if you cherry-pick that issue on main than rebasing as you now have conflicts. I don't mind if you keep this very same PR but you will need to push -f with just that change now. if you can't do it I will do those things myself.. let me know if you want / can do it. Thank you. Issue Time Tracking --- Worklog Id: (was: 913484) Time Spent: 4h 50m (was: 4h 40m) > Add auto-create-destination logic to diverts > > > Key: ARTEMIS-4510 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4510 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 4h 50m > Remaining Estimate: 0h > > This enables the use of dynamic routing decisions within the transformer by > setting the message address. It also covers for a rare problem where if any > of the forwarding addresses are removed during runtime, such as from > auto-delete, the message would get silently dropped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4510) Add auto-create-destination logic to diverts
[ https://issues.apache.org/jira/browse/ARTEMIS-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834955#comment-17834955 ] ASF subversion and git services commented on ARTEMIS-4510: -- Commit 6c02950db386b0dcb7b9539a0f63f20fa5be00cd in activemq-artemis's branch refs/heads/main from AntonRoskvist [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=6c02950db3 ] ARTEMIS-4510 Add auto-create-destination logic to diverts > Add auto-create-destination logic to diverts > > > Key: ARTEMIS-4510 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4510 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 4h 40m > Remaining Estimate: 0h > > This enables the use of dynamic routing decisions within the transformer by > setting the message address. It also covers for a rare problem where if any > of the forwarding addresses are removed during runtime, such as from > auto-delete, the message would get silently dropped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4715) Consuming from wildcard queues stopped working with 2.33.0
[
https://issues.apache.org/jira/browse/ARTEMIS-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834944#comment-17834944
]
Otavio Rodolfo Piske commented on ARTEMIS-4715:
---
The problem can be reproduced by downloading the latest upstream code from
github/apache/camel and running the following:
1. Build camel (the code hasn't been deployed to ASF Snapshots yet, but this
step can be ignored after April 9th):
{noformat}
mvn -Dquickly clean install {noformat}
2. Go the camel-activemq directory:
{noformat}
cd components/camel-activemq{noformat}
3. Run the test:
{noformat}
mvn
-Dartemis.container=quay.io/artemiscloud/activemq-artemis-broker:artemis.2.33.0
-Dit.test=ActiveMQRouteIT#testPrefixWildcard verify{noformat}
> Consuming from wildcard queues stopped working with 2.33.0
> --
>
> Key: ARTEMIS-4715
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4715
> Project: ActiveMQ Artemis
> Issue Type: Task
>Affects Versions: 2.33.0
>Reporter: Otavio Rodolfo Piske
>Priority: Major
> Attachments: camel-activemq-test-artemis-2.32.log,
> camel-activemq-test-artemis-2.33.log
>
>
> One of our
> [tests|https://github.com/apache/camel/blob/main/components/camel-activemq/src/test/java/org/apache/camel/component/activemq/ActiveMQRouteIT.java#L66-L71]
> that [consumes data from a wildcard
> queue|https://github.com/apache/camel/blob/main/components/camel-activemq/src/test/java/org/apache/camel/component/activemq/ActiveMQRouteIT.java#L111-L113]
> has stopped working after migrating to Artemis 2.33.0.
>
> This test works without problems when using Artemis 2.32.0. I attached the
> logs from executing the test with 2.32 and 2.33.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (AMQ-9472) Wildcard publisher auto-creates wildcard topic and breaks authorization
[ https://issues.apache.org/jira/browse/AMQ-9472?focusedWorklogId=913473=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913473 ] ASF GitHub Bot logged work on AMQ-9472: --- Author: ASF GitHub Bot Created on: 08/Apr/24 14:10 Start Date: 08/Apr/24 14:10 Worklog Time Spent: 10m Work Description: mattrpav commented on PR #1198: URL: https://github.com/apache/activemq/pull/1198#issuecomment-2042861290 I was able to reproduce using a stock Apache v6.1.1 build. This appears to be a 'does not permit' issue and not a 'does not restrict' issue. Issue Time Tracking --- Worklog Id: (was: 913473) Time Spent: 20m (was: 10m) > Wildcard publisher auto-creates wildcard topic and breaks authorization > --- > > Key: AMQ-9472 > URL: https://issues.apache.org/jira/browse/AMQ-9472 > Project: ActiveMQ Classic > Issue Type: Bug > Components: Broker >Reporter: Albertas Vyšniauskas >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Hi, > after publishing a message to wildcard topic, a wildcard topic is > auto-created and interacts poorly with authorization rules. > Suppose that authorization map contains the following entries: > > > Admin creates "A.B" topic and publishes a message to "A.>" causing > auto-creation of "A.>" topic. > User attempts to consume "A.B" topic, but receives "User user is not > authorized to read from: topic://A.>" error. > I asked on user mailing list if wildcard publishing is supposed to work at > all, as I could not find any documentation about that. Unfortunately I did > not receive any response, so I have to assume that it does. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ARTEMIS-4562) Limit messages per queue based on size/count
[
https://issues.apache.org/jira/browse/ARTEMIS-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834422#comment-17834422
]
Subhidh Agarwal edited comment on ARTEMIS-4562 at 4/8/24 1:17 PM:
--
Hey
I need some help in implementing this, probably with some logic because I am
not aware of most implementations. Any heads-up will be appreciated. Thanks.
> Limit messages per queue based on size/count
>
>
> Key: ARTEMIS-4562
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4562
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Reporter: Subhidh Agarwal
>Priority: Major
>
> I need to limit the number of large messages per queue by message size &
> count just like paged messages are limited by {{page-limit-bytes}} &
> {{page-limit-messages}} respectively.
> Why is it required? If a consumer is down for some queue(s), or not picking
> up large messages, the {{max-disk-usage}} will be reached, impacting the
> whole broker. Having a limit per queue for large-messages will prevent a
> single queue from filling the disk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4715) Consuming from wildcard queues stopped working with 2.33.0
[ https://issues.apache.org/jira/browse/ARTEMIS-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834910#comment-17834910 ] Otavio Rodolfo Piske commented on ARTEMIS-4715: --- Obs.: I'll share an easy way to reproduce this soon. > Consuming from wildcard queues stopped working with 2.33.0 > -- > > Key: ARTEMIS-4715 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4715 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.33.0 >Reporter: Otavio Rodolfo Piske >Priority: Major > Attachments: camel-activemq-test-artemis-2.32.log, > camel-activemq-test-artemis-2.33.log > > > One of our > [tests|https://github.com/apache/camel/blob/main/components/camel-activemq/src/test/java/org/apache/camel/component/activemq/ActiveMQRouteIT.java#L66-L71] > that [consumes data from a wildcard > queue|https://github.com/apache/camel/blob/main/components/camel-activemq/src/test/java/org/apache/camel/component/activemq/ActiveMQRouteIT.java#L111-L113] > has stopped working after migrating to Artemis 2.33.0. > > This test works without problems when using Artemis 2.32.0. I attached the > logs from executing the test with 2.32 and 2.33. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-4715) Consuming from wildcard queues stopped working with 2.33.0
Otavio Rodolfo Piske created ARTEMIS-4715: - Summary: Consuming from wildcard queues stopped working with 2.33.0 Key: ARTEMIS-4715 URL: https://issues.apache.org/jira/browse/ARTEMIS-4715 Project: ActiveMQ Artemis Issue Type: Task Affects Versions: 2.33.0 Reporter: Otavio Rodolfo Piske Attachments: camel-activemq-test-artemis-2.32.log, camel-activemq-test-artemis-2.33.log One of our [tests|https://github.com/apache/camel/blob/main/components/camel-activemq/src/test/java/org/apache/camel/component/activemq/ActiveMQRouteIT.java#L66-L71] that [consumes data from a wildcard queue|https://github.com/apache/camel/blob/main/components/camel-activemq/src/test/java/org/apache/camel/component/activemq/ActiveMQRouteIT.java#L111-L113] has stopped working after migrating to Artemis 2.33.0. This test works without problems when using Artemis 2.32.0. I attached the logs from executing the test with 2.32 and 2.33. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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=17834884#comment-17834884 ] ASF subversion and git services commented on ARTEMIS-4582: -- Commit 4d6fc39560d0d26fdbecea14de74eee35f2941f9 in activemq-artemis's branch refs/heads/main from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4d6fc39560 ] ARTEMIS-4582 doc update to make need to remove auth section of management.xml more clear > 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] [Work logged] (ARTEMIS-4510) Add auto-create-destination logic to diverts
[ https://issues.apache.org/jira/browse/ARTEMIS-4510?focusedWorklogId=913437=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913437 ] ASF GitHub Bot logged work on ARTEMIS-4510: --- Author: ASF GitHub Bot Created on: 08/Apr/24 09:49 Start Date: 08/Apr/24 09:49 Worklog Time Spent: 10m Work Description: AntonRoskvist commented on PR #4867: URL: https://github.com/apache/activemq-artemis/pull/4867#issuecomment-2042323454 @clebertsuconic Sounds great, thanks! I went ahead and separated the changes. Let me know when/if you are happy with your testing (removing the config option and always reusing the session) and I'll go ahead and remove the config option as well as some documentation from this PR. Issue Time Tracking --- Worklog Id: (was: 913437) Time Spent: 4h 40m (was: 4.5h) > Add auto-create-destination logic to diverts > > > Key: ARTEMIS-4510 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4510 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Anton Roskvist >Priority: Major > Time Spent: 4h 40m > Remaining Estimate: 0h > > This enables the use of dynamic routing decisions within the transformer by > setting the message address. It also covers for a rare problem where if any > of the forwarding addresses are removed during runtime, such as from > auto-delete, the message would get silently dropped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
