[jira] [Commented] (ARTEMIS-4780) Artemis web console does not ever set 'artemisJmxDomain' in localStorage
[
https://issues.apache.org/jira/browse/ARTEMIS-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850905#comment-17850905
]
Justin Bertram commented on ARTEMIS-4780:
-
This may be moot with the impending move to the [new
console|https://github.com/apache/activemq-artemis-console]. Can you test your
use-case with the new console?
> Artemis web console does not ever set 'artemisJmxDomain' in localStorage
>
>
> Key: ARTEMIS-4780
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4780
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.32.0
>Reporter: Josh Byster
>Priority: Minor
>
> We relocate our artemis packages as part of our shading process.
> I did set up:
>
> {code:java}
> aActiveMQServer.getConfiguration().setJMXDomain("com.abc.shaded.org.apache.activemq.artemis");
> {code}
> However the web console does not show up. I noticed in the code it's because
> we try to read in localStorage['artemisJmxDomain'] but never actually set it
> as far as I can tell. Thus we always default to org.apache.activemq.artemis.
> Everything works properly when setting localStorage['artemisJmxDomain'] =
> "com.abc.shaded.org.apache.activemq.artemis"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4789) Page.destroy race with cleanup
[ https://issues.apache.org/jira/browse/ARTEMIS-4789?focusedWorklogId=921465&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921465 ] ASF GitHub Bot logged work on ARTEMIS-4789: --- Author: ASF GitHub Bot Created on: 31/May/24 02:07 Start Date: 31/May/24 02:07 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request, #4950: URL: https://github.com/apache/activemq-artemis/pull/4950 this is fixing PagingTest::testPagingStoreDestroyed(db=derby) (or any other DB). This could eventually also fail on journal. The cleanup could act on a destroyed folder, and issue an IOException stopping the server with this race. You would need the server active cleaning messages while the queue is being removed. Issue Time Tracking --- Worklog Id: (was: 921465) Remaining Estimate: 0h Time Spent: 10m > Page.destroy race with cleanup > -- > > Key: ARTEMIS-4789 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4789 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.33.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.34.0 > > Time Spent: 10m > Remaining Estimate: 0h > > There's a rare race between Queue.destroy and cleanup. > if the cleanup is called while depaging is still happening you might endup > with a Critical IO exception as the storage folder is removed. > This is the reason why testPagingStoreDestroyed(derby) was eventually failing. > testPagingStoreDestroyed serves as the verification for this issue, as this > is intended as the test fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-4789) Page.destroy race with cleanup
Clebert Suconic created ARTEMIS-4789: Summary: Page.destroy race with cleanup Key: ARTEMIS-4789 URL: https://issues.apache.org/jira/browse/ARTEMIS-4789 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.33.0 Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.34.0 There's a rare race between Queue.destroy and cleanup. if the cleanup is called while depaging is still happening you might endup with a Critical IO exception as the storage folder is removed. This is the reason why testPagingStoreDestroyed(derby) was eventually failing. testPagingStoreDestroyed serves as the verification for this issue, as this is intended as the test fix. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-3957) Check for Subject on RemotingConnection before auth cache
[
https://issues.apache.org/jira/browse/ARTEMIS-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850884#comment-17850884
]
Mike Artz commented on ARTEMIS-3957:
Oh nevermind thats my mistake sorry
> Check for Subject on RemotingConnection before auth cache
> -
>
> Key: ARTEMIS-3957
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3957
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Authenticated users automatically have their {{Subject}} set on their
> {{RemotingConnection}}. The {{SecurityStore}} should check for this
> {{Subject}} during authorization before checking its cache or attempting
> re-authentication. This will avoid unnecessary traffic to the underlying
> security repository (e.g. LDAP) in cases where the cache times out or is
> disabled completely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4788) AMQP Federation Broker connection can deadlock broker shutdown
[ https://issues.apache.org/jira/browse/ARTEMIS-4788?focusedWorklogId=921461&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921461 ] ASF GitHub Bot logged work on ARTEMIS-4788: --- Author: ASF GitHub Bot Created on: 30/May/24 23:44 Start Date: 30/May/24 23:44 Worklog Time Spent: 10m Work Description: clebertsuconic commented on PR #4949: URL: https://github.com/apache/activemq-artemis/pull/4949#issuecomment-2141010191 LGTM Issue Time Tracking --- Worklog Id: (was: 921461) Time Spent: 20m (was: 10m) > AMQP Federation Broker connection can deadlock broker shutdown > -- > > Key: ARTEMIS-4788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.33.0, 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > In a rare race between broker shutdown and create of federation consumer the > broker connection federation manager can deadlock and hang the shutdown of > the broker. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4788) AMQP Federation Broker connection can deadlock broker shutdown
[ https://issues.apache.org/jira/browse/ARTEMIS-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850881#comment-17850881 ] ASF subversion and git services commented on ARTEMIS-4788: -- Commit 892c1225b09cad90b1cbbb24654f6fcaa10512ae in activemq-artemis's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=892c1225b0 ] ARTEMIS-4788 Fix a rare race on broker shutdown in AMQP federation Race on consumer create and broker shutdown could lead to a deadlocak trying to access configuration from the policy manager while the federation instance is trying to shutdown the policy manager. > AMQP Federation Broker connection can deadlock broker shutdown > -- > > Key: ARTEMIS-4788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.33.0, 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > In a rare race between broker shutdown and create of federation consumer the > broker connection federation manager can deadlock and hang the shutdown of > the broker. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4788) AMQP Federation Broker connection can deadlock broker shutdown
[ https://issues.apache.org/jira/browse/ARTEMIS-4788?focusedWorklogId=921462&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921462 ] ASF GitHub Bot logged work on ARTEMIS-4788: --- Author: ASF GitHub Bot Created on: 30/May/24 23:44 Start Date: 30/May/24 23:44 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4949: URL: https://github.com/apache/activemq-artemis/pull/4949 Issue Time Tracking --- Worklog Id: (was: 921462) Time Spent: 0.5h (was: 20m) > AMQP Federation Broker connection can deadlock broker shutdown > -- > > Key: ARTEMIS-4788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.33.0, 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > In a rare race between broker shutdown and create of federation consumer the > broker connection federation manager can deadlock and hang the shutdown of > the broker. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4788) AMQP Federation Broker connection can deadlock broker shutdown
[ https://issues.apache.org/jira/browse/ARTEMIS-4788?focusedWorklogId=921451&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921451 ] ASF GitHub Bot logged work on ARTEMIS-4788: --- Author: ASF GitHub Bot Created on: 30/May/24 22:15 Start Date: 30/May/24 22:15 Worklog Time Spent: 10m Work Description: tabish121 opened a new pull request, #4949: URL: https://github.com/apache/activemq-artemis/pull/4949 Race on consumer create and broker shutdown could lead to a deadlocak trying to access configuration from the policy manager while the federation instance is trying to shutdown the policy manager. Issue Time Tracking --- Worklog Id: (was: 921451) Remaining Estimate: 0h Time Spent: 10m > AMQP Federation Broker connection can deadlock broker shutdown > -- > > Key: ARTEMIS-4788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.33.0, 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > In a rare race between broker shutdown and create of federation consumer the > broker connection federation manager can deadlock and hang the shutdown of > the broker. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4788) AMQP Federation Broker connection can deadlock broker shutdown
[ https://issues.apache.org/jira/browse/ARTEMIS-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated ARTEMIS-4788: - Affects Version/s: 2.34.0 > AMQP Federation Broker connection can deadlock broker shutdown > -- > > Key: ARTEMIS-4788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.33.0, 2.34.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > > In a rare race between broker shutdown and create of federation consumer the > broker connection federation manager can deadlock and hang the shutdown of > the broker. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-4788) AMQP Federation Broker connection can deadlock broker shutdown
Timothy A. Bish created ARTEMIS-4788: Summary: AMQP Federation Broker connection can deadlock broker shutdown Key: ARTEMIS-4788 URL: https://issues.apache.org/jira/browse/ARTEMIS-4788 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.33.0 Reporter: Timothy A. Bish Assignee: Timothy A. Bish In a rare race between broker shutdown and create of federation consumer the broker connection federation manager can deadlock and hang the shutdown of the broker. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4787) Anycast queue does not auto-create if already multicast queue on same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850847#comment-17850847
]
Justin Bertram commented on ARTEMIS-4787:
-
The {{multicastPrefix}} and {{anycastPrefix}} settings are used to deduce the
routing type based on the prefix already in use by the clients. For example,
clients using names {{topic/foo}} and {{queue/bar}} will get multicast or
anycast semantics respectively when using {{multicastPrefix=topic/}} and
{{anycastPrefix=queue/}}. It won't _add_ a prefix as required for your use-case.
Off the top of my head, the only way I can think of to do something like this
is with a [broker
plugin|https://activemq.apache.org/components/artemis/documentation/latest/broker-plugins.html#plugin-support],
specifically an [address
plugin|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/plugin/ActiveMQServerAddressPlugin.java]
and/or a [queue
plugin|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/plugin/ActiveMQServerQueuePlugin.java].
I'm not familiar with the details of your use-case so I'm not 100% sure it
will do what you need, but it's my best guess at this point.
> Anycast queue does not auto-create if already multicast queue on same address
> -
>
> Key: ARTEMIS-4787
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4787
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Josh Byster
>Priority: Major
>
> As a preface, I am aware that creating both anycast and multicast queues on
> the same address is an anti-pattern and not recommended. However, this is
> causing difficulties migrating over legacy clients from using Classic to
> Artemis.
> If one creates a JMS topic on an address, and then tries to create a JMS
> queue, it fails to create. However, if the order is flipped (creating a
> queue, then a topic), there is no exception.
> It seems like the issue is in this area of ServerSessionImpl:
> {code:java}
> Bindings bindings =
> server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
> if (bindings != null && bindings.hasLocalBinding() &&
> !queueConfig.isFqqn()) {
>// The address has another queue with a different name, which
> is fine. Just ignore it.
>result = AutoCreateResult.EXISTED;
> {code}
> Please see test below to reproduce, which throws the exception immediately as
> seen in production.
> {code:java}
> package org.apache.activemq.artemis.tests.integration;
> import org.apache.activemq.artemis.api.core.client.ClientSession;
> import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
> import org.apache.activemq.artemis.api.core.client.ServerLocator;
> import org.apache.activemq.artemis.core.server.ActiveMQServer;
> import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
> import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
> import org.junit.Before;
> import org.junit.Test;
> import javax.jms.Connection;
> import javax.jms.ConnectionFactory;
> import javax.jms.MessageConsumer;
> import javax.jms.Queue;
> import javax.jms.Session;
> import javax.jms.Topic;
> import java.util.HashMap;
> public class QueueTopicSameNameTest extends ActiveMQTestBase {
> protected ActiveMQServer server;
> protected ClientSession session;
> protected ClientSessionFactory sf;
> protected ServerLocator locator;
> @Override
> @Before
> public void setUp() throws Exception {
> super.setUp();
> server = createServer(true, createDefaultNettyConfig(),
> AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES,
> -1, -1, new HashMap<>());
> server.start();
> locator = createInVMNonHALocator();
> sf = createSessionFactory(locator);
> session = addClientSession(sf.createSession(false, true, true));
> }
> @Test
> public void testTopicThenQueueCreate() throws Exception {
> String myAddr = "TEST";
> ConnectionFactory cf = new
> org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
> Connection c = cf.createConnection();
> Session s = c.createSession();
> Topic t = s.createTopic(myAddr);
> MessageConsumer consumer = s.createConsumer(t);
> Queue q = s.createQueue(myAddr);
> MessageConsumer otherConsumer = s.createConsumer(q);
> c.close();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@act
[jira] [Comment Edited] (ARTEMIS-4787) Anycast queue does not auto-create if already multicast queue on same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850838#comment-17850838
]
Josh Byster edited comment on ARTEMIS-4787 at 5/30/24 7:17 PM:
---
[~jbertram] I have confirmed the intended functionality is to treat them
completely separate, i.e. that they could be named completely different things
but they aren'tso ideally I would almost want a prefix to be appended to
all addresses if they're auto-created as multicast and for all anycast
addresses. It doesn't seem like `multicastPrefix` will auto-append like this
for us, any thoughts on how to accomplish (OpenWire)?
was (Author: josh b):
[~jbertram] I have confirmed the intended functionality is to treat them
completely separate, i.e. that they could be named completely different things
but they aren'tso ideally I would almost want a prefix to be appended to
all addresses if they're auto-created as multicast and for all anycast
addresses. It doesn't seem like `multicastPrefix` will auto-append like this
for us, any thoughts on how to accomplish?
> Anycast queue does not auto-create if already multicast queue on same address
> -
>
> Key: ARTEMIS-4787
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4787
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Josh Byster
>Priority: Major
>
> As a preface, I am aware that creating both anycast and multicast queues on
> the same address is an anti-pattern and not recommended. However, this is
> causing difficulties migrating over legacy clients from using Classic to
> Artemis.
> If one creates a JMS topic on an address, and then tries to create a JMS
> queue, it fails to create. However, if the order is flipped (creating a
> queue, then a topic), there is no exception.
> It seems like the issue is in this area of ServerSessionImpl:
> {code:java}
> Bindings bindings =
> server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
> if (bindings != null && bindings.hasLocalBinding() &&
> !queueConfig.isFqqn()) {
>// The address has another queue with a different name, which
> is fine. Just ignore it.
>result = AutoCreateResult.EXISTED;
> {code}
> Please see test below to reproduce, which throws the exception immediately as
> seen in production.
> {code:java}
> package org.apache.activemq.artemis.tests.integration;
> import org.apache.activemq.artemis.api.core.client.ClientSession;
> import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
> import org.apache.activemq.artemis.api.core.client.ServerLocator;
> import org.apache.activemq.artemis.core.server.ActiveMQServer;
> import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
> import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
> import org.junit.Before;
> import org.junit.Test;
> import javax.jms.Connection;
> import javax.jms.ConnectionFactory;
> import javax.jms.MessageConsumer;
> import javax.jms.Queue;
> import javax.jms.Session;
> import javax.jms.Topic;
> import java.util.HashMap;
> public class QueueTopicSameNameTest extends ActiveMQTestBase {
> protected ActiveMQServer server;
> protected ClientSession session;
> protected ClientSessionFactory sf;
> protected ServerLocator locator;
> @Override
> @Before
> public void setUp() throws Exception {
> super.setUp();
> server = createServer(true, createDefaultNettyConfig(),
> AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES,
> -1, -1, new HashMap<>());
> server.start();
> locator = createInVMNonHALocator();
> sf = createSessionFactory(locator);
> session = addClientSession(sf.createSession(false, true, true));
> }
> @Test
> public void testTopicThenQueueCreate() throws Exception {
> String myAddr = "TEST";
> ConnectionFactory cf = new
> org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
> Connection c = cf.createConnection();
> Session s = c.createSession();
> Topic t = s.createTopic(myAddr);
> MessageConsumer consumer = s.createConsumer(t);
> Queue q = s.createQueue(myAddr);
> MessageConsumer otherConsumer = s.createConsumer(q);
> c.close();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4787) Anycast queue does not auto-create if already multicast queue on same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850838#comment-17850838
]
Josh Byster commented on ARTEMIS-4787:
--
[~jbertram] I have confirmed the intended functionality is to treat them
completely separate, i.e. that they could be named completely different things
but they aren'tso ideally I would almost want a prefix to be appended to
all addresses if they're auto-created as multicast and for all anycast
addresses. It doesn't seem like `multicastPrefix` will auto-append like this
for us, any thoughts on how to accomplish?
> Anycast queue does not auto-create if already multicast queue on same address
> -
>
> Key: ARTEMIS-4787
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4787
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Josh Byster
>Priority: Major
>
> As a preface, I am aware that creating both anycast and multicast queues on
> the same address is an anti-pattern and not recommended. However, this is
> causing difficulties migrating over legacy clients from using Classic to
> Artemis.
> If one creates a JMS topic on an address, and then tries to create a JMS
> queue, it fails to create. However, if the order is flipped (creating a
> queue, then a topic), there is no exception.
> It seems like the issue is in this area of ServerSessionImpl:
> {code:java}
> Bindings bindings =
> server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
> if (bindings != null && bindings.hasLocalBinding() &&
> !queueConfig.isFqqn()) {
>// The address has another queue with a different name, which
> is fine. Just ignore it.
>result = AutoCreateResult.EXISTED;
> {code}
> Please see test below to reproduce, which throws the exception immediately as
> seen in production.
> {code:java}
> package org.apache.activemq.artemis.tests.integration;
> import org.apache.activemq.artemis.api.core.client.ClientSession;
> import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
> import org.apache.activemq.artemis.api.core.client.ServerLocator;
> import org.apache.activemq.artemis.core.server.ActiveMQServer;
> import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
> import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
> import org.junit.Before;
> import org.junit.Test;
> import javax.jms.Connection;
> import javax.jms.ConnectionFactory;
> import javax.jms.MessageConsumer;
> import javax.jms.Queue;
> import javax.jms.Session;
> import javax.jms.Topic;
> import java.util.HashMap;
> public class QueueTopicSameNameTest extends ActiveMQTestBase {
> protected ActiveMQServer server;
> protected ClientSession session;
> protected ClientSessionFactory sf;
> protected ServerLocator locator;
> @Override
> @Before
> public void setUp() throws Exception {
> super.setUp();
> server = createServer(true, createDefaultNettyConfig(),
> AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES,
> -1, -1, new HashMap<>());
> server.start();
> locator = createInVMNonHALocator();
> sf = createSessionFactory(locator);
> session = addClientSession(sf.createSession(false, true, true));
> }
> @Test
> public void testTopicThenQueueCreate() throws Exception {
> String myAddr = "TEST";
> ConnectionFactory cf = new
> org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
> Connection c = cf.createConnection();
> Session s = c.createSession();
> Topic t = s.createTopic(myAddr);
> MessageConsumer consumer = s.createConsumer(t);
> Queue q = s.createQueue(myAddr);
> MessageConsumer otherConsumer = s.createConsumer(q);
> c.close();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Comment Edited] (ARTEMIS-4787) Anycast queue does not auto-create if already multicast queue on same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850829#comment-17850829
]
Josh Byster edited comment on ARTEMIS-4787 at 5/30/24 6:18 PM:
---
[~jbertram] I have to clarify with the author what the intended functionality
was here, since I am under the impression this is potentially a
misconfiguration (I don't know what the intended behavior was for creating a
JMS topic and queue). These are not names we can hardcode since the names are
suffixed with information only known at runtime, so they can't be defined in
the XML.
I think we can probably change the client code to correct for the intended
behavior here to work around, assuming we can preserve what semantics the
original author intended. So in summary, I'm not sure what the intended use
case is yet, I just saw logs being spammed with errors when switching from a
classic to Artemis broker on these address names.
was (Author: josh b):
[~jbertram] I have to clarify with the author what the intended functionality
was here, since I am under the impression this is potentially a
misconfiguration (I don't know what the intended behavior was for creating a
JMS topic and queue). These are not names we can hardcode since the names are
suffixed with information only known at runtime, so they can't be defined in
the XML.
I think we can probably change the client code to correct for the intended
behavior here to work around, assuming we can preserve what semantics the
original author intended.
> Anycast queue does not auto-create if already multicast queue on same address
> -
>
> Key: ARTEMIS-4787
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4787
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Josh Byster
>Priority: Major
>
> As a preface, I am aware that creating both anycast and multicast queues on
> the same address is an anti-pattern and not recommended. However, this is
> causing difficulties migrating over legacy clients from using Classic to
> Artemis.
> If one creates a JMS topic on an address, and then tries to create a JMS
> queue, it fails to create. However, if the order is flipped (creating a
> queue, then a topic), there is no exception.
> It seems like the issue is in this area of ServerSessionImpl:
> {code:java}
> Bindings bindings =
> server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
> if (bindings != null && bindings.hasLocalBinding() &&
> !queueConfig.isFqqn()) {
>// The address has another queue with a different name, which
> is fine. Just ignore it.
>result = AutoCreateResult.EXISTED;
> {code}
> Please see test below to reproduce, which throws the exception immediately as
> seen in production.
> {code:java}
> package org.apache.activemq.artemis.tests.integration;
> import org.apache.activemq.artemis.api.core.client.ClientSession;
> import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
> import org.apache.activemq.artemis.api.core.client.ServerLocator;
> import org.apache.activemq.artemis.core.server.ActiveMQServer;
> import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
> import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
> import org.junit.Before;
> import org.junit.Test;
> import javax.jms.Connection;
> import javax.jms.ConnectionFactory;
> import javax.jms.MessageConsumer;
> import javax.jms.Queue;
> import javax.jms.Session;
> import javax.jms.Topic;
> import java.util.HashMap;
> public class QueueTopicSameNameTest extends ActiveMQTestBase {
> protected ActiveMQServer server;
> protected ClientSession session;
> protected ClientSessionFactory sf;
> protected ServerLocator locator;
> @Override
> @Before
> public void setUp() throws Exception {
> super.setUp();
> server = createServer(true, createDefaultNettyConfig(),
> AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES,
> -1, -1, new HashMap<>());
> server.start();
> locator = createInVMNonHALocator();
> sf = createSessionFactory(locator);
> session = addClientSession(sf.createSession(false, true, true));
> }
> @Test
> public void testTopicThenQueueCreate() throws Exception {
> String myAddr = "TEST";
> ConnectionFactory cf = new
> org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
> Connection c = cf.createConnection();
> Session s = c.createSession();
> Topic t = s.createTopic(myAddr);
> MessageConsumer consumer = s.createConsumer(t);
> Queue q = s.createQueue(myAddr);
> MessageConsumer ot
[jira] [Commented] (ARTEMIS-4787) Anycast queue does not auto-create if already multicast queue on same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850829#comment-17850829
]
Josh Byster commented on ARTEMIS-4787:
--
[~jbertram] I have to clarify with the author what the intended functionality
was here, since I am under the impression this is potentially a
misconfiguration (I don't know what the intended behavior was for creating a
JMS topic and queue). These are not names we can hardcode since the names are
suffixed with information only known at runtime, so they can't be defined in
the XML.
I think we can probably change the client code to correct for the intended
behavior here to work around, assuming we can preserve what semantics the
original author intended.
> Anycast queue does not auto-create if already multicast queue on same address
> -
>
> Key: ARTEMIS-4787
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4787
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Josh Byster
>Priority: Major
>
> As a preface, I am aware that creating both anycast and multicast queues on
> the same address is an anti-pattern and not recommended. However, this is
> causing difficulties migrating over legacy clients from using Classic to
> Artemis.
> If one creates a JMS topic on an address, and then tries to create a JMS
> queue, it fails to create. However, if the order is flipped (creating a
> queue, then a topic), there is no exception.
> It seems like the issue is in this area of ServerSessionImpl:
> {code:java}
> Bindings bindings =
> server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
> if (bindings != null && bindings.hasLocalBinding() &&
> !queueConfig.isFqqn()) {
>// The address has another queue with a different name, which
> is fine. Just ignore it.
>result = AutoCreateResult.EXISTED;
> {code}
> Please see test below to reproduce, which throws the exception immediately as
> seen in production.
> {code:java}
> package org.apache.activemq.artemis.tests.integration;
> import org.apache.activemq.artemis.api.core.client.ClientSession;
> import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
> import org.apache.activemq.artemis.api.core.client.ServerLocator;
> import org.apache.activemq.artemis.core.server.ActiveMQServer;
> import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
> import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
> import org.junit.Before;
> import org.junit.Test;
> import javax.jms.Connection;
> import javax.jms.ConnectionFactory;
> import javax.jms.MessageConsumer;
> import javax.jms.Queue;
> import javax.jms.Session;
> import javax.jms.Topic;
> import java.util.HashMap;
> public class QueueTopicSameNameTest extends ActiveMQTestBase {
> protected ActiveMQServer server;
> protected ClientSession session;
> protected ClientSessionFactory sf;
> protected ServerLocator locator;
> @Override
> @Before
> public void setUp() throws Exception {
> super.setUp();
> server = createServer(true, createDefaultNettyConfig(),
> AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES,
> -1, -1, new HashMap<>());
> server.start();
> locator = createInVMNonHALocator();
> sf = createSessionFactory(locator);
> session = addClientSession(sf.createSession(false, true, true));
> }
> @Test
> public void testTopicThenQueueCreate() throws Exception {
> String myAddr = "TEST";
> ConnectionFactory cf = new
> org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
> Connection c = cf.createConnection();
> Session s = c.createSession();
> Topic t = s.createTopic(myAddr);
> MessageConsumer consumer = s.createConsumer(t);
> Queue q = s.createQueue(myAddr);
> MessageConsumer otherConsumer = s.createConsumer(q);
> c.close();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4787) Anycast queue does not auto-create if already multicast queue on same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850823#comment-17850823
]
Justin Bertram commented on ARTEMIS-4787:
-
Out of curiosity, can you elaborate on the underlying use-case here?
> Anycast queue does not auto-create if already multicast queue on same address
> -
>
> Key: ARTEMIS-4787
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4787
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Josh Byster
>Priority: Major
>
> As a preface, I am aware that creating both anycast and multicast queues on
> the same address is an anti-pattern and not recommended. However, this is
> causing difficulties migrating over legacy clients from using Classic to
> Artemis.
> If one creates a JMS topic on an address, and then tries to create a JMS
> queue, it fails to create. However, if the order is flipped (creating a
> queue, then a topic), there is no exception.
> It seems like the issue is in this area of ServerSessionImpl:
> {code:java}
> Bindings bindings =
> server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
> if (bindings != null && bindings.hasLocalBinding() &&
> !queueConfig.isFqqn()) {
>// The address has another queue with a different name, which
> is fine. Just ignore it.
>result = AutoCreateResult.EXISTED;
> {code}
> Please see test below to reproduce, which throws the exception immediately as
> seen in production.
> {code:java}
> package org.apache.activemq.artemis.tests.integration;
> import org.apache.activemq.artemis.api.core.client.ClientSession;
> import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
> import org.apache.activemq.artemis.api.core.client.ServerLocator;
> import org.apache.activemq.artemis.core.server.ActiveMQServer;
> import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
> import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
> import org.junit.Before;
> import org.junit.Test;
> import javax.jms.Connection;
> import javax.jms.ConnectionFactory;
> import javax.jms.MessageConsumer;
> import javax.jms.Queue;
> import javax.jms.Session;
> import javax.jms.Topic;
> import java.util.HashMap;
> public class QueueTopicSameNameTest extends ActiveMQTestBase {
> protected ActiveMQServer server;
> protected ClientSession session;
> protected ClientSessionFactory sf;
> protected ServerLocator locator;
> @Override
> @Before
> public void setUp() throws Exception {
> super.setUp();
> server = createServer(true, createDefaultNettyConfig(),
> AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES,
> -1, -1, new HashMap<>());
> server.start();
> locator = createInVMNonHALocator();
> sf = createSessionFactory(locator);
> session = addClientSession(sf.createSession(false, true, true));
> }
> @Test
> public void testTopicThenQueueCreate() throws Exception {
> String myAddr = "TEST";
> ConnectionFactory cf = new
> org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
> Connection c = cf.createConnection();
> Session s = c.createSession();
> Topic t = s.createTopic(myAddr);
> MessageConsumer consumer = s.createConsumer(t);
> Queue q = s.createQueue(myAddr);
> MessageConsumer otherConsumer = s.createConsumer(q);
> c.close();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4787) Anycast queue does not auto-create if already multicast queue on same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850824#comment-17850824
]
Justin Bertram commented on ARTEMIS-4787:
-
As a work-around have you considered statically creating the address/queue
configuration you need in {{broker.xml}}?
> Anycast queue does not auto-create if already multicast queue on same address
> -
>
> Key: ARTEMIS-4787
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4787
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Josh Byster
>Priority: Major
>
> As a preface, I am aware that creating both anycast and multicast queues on
> the same address is an anti-pattern and not recommended. However, this is
> causing difficulties migrating over legacy clients from using Classic to
> Artemis.
> If one creates a JMS topic on an address, and then tries to create a JMS
> queue, it fails to create. However, if the order is flipped (creating a
> queue, then a topic), there is no exception.
> It seems like the issue is in this area of ServerSessionImpl:
> {code:java}
> Bindings bindings =
> server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
> if (bindings != null && bindings.hasLocalBinding() &&
> !queueConfig.isFqqn()) {
>// The address has another queue with a different name, which
> is fine. Just ignore it.
>result = AutoCreateResult.EXISTED;
> {code}
> Please see test below to reproduce, which throws the exception immediately as
> seen in production.
> {code:java}
> package org.apache.activemq.artemis.tests.integration;
> import org.apache.activemq.artemis.api.core.client.ClientSession;
> import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
> import org.apache.activemq.artemis.api.core.client.ServerLocator;
> import org.apache.activemq.artemis.core.server.ActiveMQServer;
> import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
> import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
> import org.junit.Before;
> import org.junit.Test;
> import javax.jms.Connection;
> import javax.jms.ConnectionFactory;
> import javax.jms.MessageConsumer;
> import javax.jms.Queue;
> import javax.jms.Session;
> import javax.jms.Topic;
> import java.util.HashMap;
> public class QueueTopicSameNameTest extends ActiveMQTestBase {
> protected ActiveMQServer server;
> protected ClientSession session;
> protected ClientSessionFactory sf;
> protected ServerLocator locator;
> @Override
> @Before
> public void setUp() throws Exception {
> super.setUp();
> server = createServer(true, createDefaultNettyConfig(),
> AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES,
> -1, -1, new HashMap<>());
> server.start();
> locator = createInVMNonHALocator();
> sf = createSessionFactory(locator);
> session = addClientSession(sf.createSession(false, true, true));
> }
> @Test
> public void testTopicThenQueueCreate() throws Exception {
> String myAddr = "TEST";
> ConnectionFactory cf = new
> org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
> Connection c = cf.createConnection();
> Session s = c.createSession();
> Topic t = s.createTopic(myAddr);
> MessageConsumer consumer = s.createConsumer(t);
> Queue q = s.createQueue(myAddr);
> MessageConsumer otherConsumer = s.createConsumer(q);
> c.close();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (ARTEMIS-4787) Anycast queue does not auto-create if already multicast queue on same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Byster updated ARTEMIS-4787:
-
Description:
As a preface, I am aware that creating both anycast and multicast queues on the
same address is an anti-pattern and not recommended. However, this is causing
difficulties migrating over legacy clients from using Classic to Artemis.
If one creates a JMS topic on an address, and then tries to create a JMS queue,
it fails to create. However, if the order is flipped (creating a queue, then a
topic), there is no exception.
It seems like the issue is in this area of ServerSessionImpl:
{code:java}
Bindings bindings =
server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
if (bindings != null && bindings.hasLocalBinding() &&
!queueConfig.isFqqn()) {
// The address has another queue with a different name, which is
fine. Just ignore it.
result = AutoCreateResult.EXISTED;
{code}
Please see test below to reproduce, which throws the exception immediately as
seen in production.
{code:java}
package org.apache.activemq.artemis.tests.integration;
import org.apache.activemq.artemis.api.core.client.ClientSession;
import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
import org.apache.activemq.artemis.api.core.client.ServerLocator;
import org.apache.activemq.artemis.core.server.ActiveMQServer;
import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
import org.junit.Before;
import org.junit.Test;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.MessageConsumer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.Topic;
import java.util.HashMap;
public class QueueTopicSameNameTest extends ActiveMQTestBase {
protected ActiveMQServer server;
protected ClientSession session;
protected ClientSessionFactory sf;
protected ServerLocator locator;
@Override
@Before
public void setUp() throws Exception {
super.setUp();
server = createServer(true, createDefaultNettyConfig(),
AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES, -1,
-1, new HashMap<>());
server.start();
locator = createInVMNonHALocator();
sf = createSessionFactory(locator);
session = addClientSession(sf.createSession(false, true, true));
}
@Test
public void testTopicThenQueueCreate() throws Exception {
String myAddr = "TEST";
ConnectionFactory cf = new
org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
Connection c = cf.createConnection();
Session s = c.createSession();
Topic t = s.createTopic(myAddr);
MessageConsumer consumer = s.createConsumer(t);
Queue q = s.createQueue(myAddr);
MessageConsumer otherConsumer = s.createConsumer(q);
c.close();
}
}
{code}
was:
As a preface, I am aware that creating both anycast and multicast queues on the
same address are an anti-pattern and not recommended. However, this is causing
difficulties migrating over legacy clients from using Classic to Artemis.
If one creates a JMS topic on an address, and then tries to create a JMS queue,
it fails to create. However, if the order is flipped (creating a queue, then a
topic), there is no exception.
It seems like the issue is in this area of ServerSessionImpl:
{code:java}
Bindings bindings =
server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
if (bindings != null && bindings.hasLocalBinding() &&
!queueConfig.isFqqn()) {
// The address has another queue with a different name, which is
fine. Just ignore it.
result = AutoCreateResult.EXISTED;
{code}
Please see test below to reproduce, which throws the exception immediately as
seen in production.
{code:java}
package org.apache.activemq.artemis.tests.integration;
import org.apache.activemq.artemis.api.core.client.ClientSession;
import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
import org.apache.activemq.artemis.api.core.client.ServerLocator;
import org.apache.activemq.artemis.core.server.ActiveMQServer;
import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
import org.junit.Before;
import org.junit.Test;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.MessageConsumer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.Topic;
import java.util.HashMap;
public class QueueTopicSameNameTest extends ActiveMQTestBase {
protected ActiveMQServer server;
protected ClientSession session;
protected ClientSessionFactory sf;
protected ServerLocator locator;
[jira] [Updated] (ARTEMIS-4787) Anycast queue does not auto-create if already multicast queue on same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Byster updated ARTEMIS-4787:
-
Description:
As a preface, I am aware that creating both anycast and multicast queues on the
same address are an anti-pattern and not recommended. However, this is causing
difficulties migrating over legacy clients from using Classic to Artemis.
If one creates a JMS topic on an address, and then tries to create a JMS queue,
it fails to create. However, if the order is flipped (creating a queue, then a
topic), there is no exception.
It seems like the issue is in this area of ServerSessionImpl:
{code:java}
Bindings bindings =
server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
if (bindings != null && bindings.hasLocalBinding() &&
!queueConfig.isFqqn()) {
// The address has another queue with a different name, which is
fine. Just ignore it.
result = AutoCreateResult.EXISTED;
{code}
Please see test below to reproduce, which throws the exception immediately as
seen in production.
{code:java}
package org.apache.activemq.artemis.tests.integration;
import org.apache.activemq.artemis.api.core.client.ClientSession;
import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
import org.apache.activemq.artemis.api.core.client.ServerLocator;
import org.apache.activemq.artemis.core.server.ActiveMQServer;
import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
import org.junit.Before;
import org.junit.Test;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.MessageConsumer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.Topic;
import java.util.HashMap;
public class QueueTopicSameNameTest extends ActiveMQTestBase {
protected ActiveMQServer server;
protected ClientSession session;
protected ClientSessionFactory sf;
protected ServerLocator locator;
@Override
@Before
public void setUp() throws Exception {
super.setUp();
server = createServer(true, createDefaultNettyConfig(),
AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES, -1,
-1, new HashMap<>());
server.start();
locator = createInVMNonHALocator();
sf = createSessionFactory(locator);
session = addClientSession(sf.createSession(false, true, true));
}
@Test
public void testTopicThenQueueCreate() throws Exception {
String myAddr = "TEST";
ConnectionFactory cf = new
org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
Connection c = cf.createConnection();
Session s = c.createSession();
Topic t = s.createTopic(myAddr);
MessageConsumer consumer = s.createConsumer(t);
Queue q = s.createQueue(myAddr);
MessageConsumer otherConsumer = s.createConsumer(q);
c.close();
}
}
{code}
was:
As a preface, I am aware that creating both anycast and multicast queues on the
same address are an anti-pattern and not recommended. However, this is causing
difficulties migrating over legacy clients from using Classic to Artemis.
If one creates a JMS topic on an address, and then tries to create a JMS queue,
it fails to create. However, if the order is flipped (creating a queue, then a
topic), there is no exception.
It seems like the issue is in this area of ServerSessionImpl:
{code:java}
Bindings bindings =
server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
if (bindings != null && bindings.hasLocalBinding() &&
!queueConfig.isFqqn()) {
// The address has another queue with a different name, which is
fine. Just ignore it.
result = AutoCreateResult.EXISTED;
{code}
Please see test below to reproduce, which throws the exception immediately as
seen in production.
{code:java}
package org.apache.activemq.artemis.tests.integration;
import org.apache.activemq.artemis.api.core.client.ClientSession;
import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
import org.apache.activemq.artemis.api.core.client.ServerLocator;
import org.apache.activemq.artemis.core.server.ActiveMQServer;
import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
import org.junit.Before;
import org.junit.Test;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.MessageConsumer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.Topic;
import java.util.HashMap;
public class QueueTopicSameNameTest extends ActiveMQTestBase {
protected ActiveMQServer server;
protected ClientSession session;
protected ClientSessionFactory sf;
protected ServerLocator locator;
[jira] [Updated] (ARTEMIS-4787) Anycast queue does not auto-create if already multicast queue on same address
[
https://issues.apache.org/jira/browse/ARTEMIS-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Byster updated ARTEMIS-4787:
-
Summary: Anycast queue does not auto-create if already multicast queue on
same address (was: Queue does not auto-create if already topic on same name)
> Anycast queue does not auto-create if already multicast queue on same address
> -
>
> Key: ARTEMIS-4787
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4787
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Josh Byster
>Priority: Major
>
> As a preface, I am aware that creating both anycast and multicast queues on
> the same address are an anti-pattern and not recommended. However, this is
> causing difficulties migrating over legacy clients from using Classic to
> Artemis.
> If one creates a JMS topic on an address, and then tries to create a JMS
> queue, it fails to create. However, if the order is flipped (creating a
> queue, then a topic), there is no exception.
> It seems like the issue is in this area of ServerSessionImpl:
> {code:java}
> Bindings bindings =
> server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
> if (bindings != null && bindings.hasLocalBinding() &&
> !queueConfig.isFqqn()) {
>// The address has another queue with a different name, which
> is fine. Just ignore it.
>result = AutoCreateResult.EXISTED;
> {code}
> Please see test below to reproduce, which throws the exception immediately as
> seen in production.
> {code:java}
> package org.apache.activemq.artemis.tests.integration;
> import org.apache.activemq.artemis.api.core.client.ClientSession;
> import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
> import org.apache.activemq.artemis.api.core.client.ServerLocator;
> import org.apache.activemq.artemis.core.server.ActiveMQServer;
> import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
> import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
> import org.junit.Before;
> import org.junit.Test;
> import javax.jms.Connection;
> import javax.jms.ConnectionFactory;
> import javax.jms.MessageConsumer;
> import javax.jms.Queue;
> import javax.jms.Session;
> import javax.jms.Topic;
> import java.util.HashMap;
> public class QueueTopicSameNameTest extends ActiveMQTestBase {
> protected ActiveMQServer server;
> protected ClientSession session;
> protected ClientSessionFactory sf;
> protected ServerLocator locator;
> @Override
> @Before
> public void setUp() throws Exception {
> super.setUp();
> server = createServer(true, createDefaultNettyConfig(),
> AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES,
> -1, -1, new HashMap<>());
> server.start();
> locator = createInVMNonHALocator();
> sf = createSessionFactory(locator);
> session = addClientSession(sf.createSession(false, true, true));
> }
> @Test
> public void testConsumerKick() throws Exception {
> String myAddr = "TEST";
> ConnectionFactory cf = new
> org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
> Connection c = cf.createConnection();
> Session s = c.createSession();
> Topic t = s.createTopic(myAddr);
> MessageConsumer consumer = s.createConsumer(t);
> Queue q = s.createQueue(myAddr);
> MessageConsumer otherConsumer = s.createConsumer(q);
> c.close();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (ARTEMIS-4787) Queue does not auto-create if already topic on same name
Josh Byster created ARTEMIS-4787:
Summary: Queue does not auto-create if already topic on same name
Key: ARTEMIS-4787
URL: https://issues.apache.org/jira/browse/ARTEMIS-4787
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Reporter: Josh Byster
As a preface, I am aware that creating both anycast and multicast queues on the
same address are an anti-pattern and not recommended. However, this is causing
difficulties migrating over legacy clients from using Classic to Artemis.
If one creates a JMS topic on an address, and then tries to create a JMS queue,
it fails to create. However, if the order is flipped (creating a queue, then a
topic), there is no exception.
It seems like the issue is in this area of ServerSessionImpl:
{code:java}
Bindings bindings =
server.getPostOffice().lookupBindingsForAddress(unPrefixedAddress);
if (bindings != null && bindings.hasLocalBinding() &&
!queueConfig.isFqqn()) {
// The address has another queue with a different name, which is
fine. Just ignore it.
result = AutoCreateResult.EXISTED;
{code}
Please see test below to reproduce, which throws the exception immediately as
seen in production.
{code:java}
package org.apache.activemq.artemis.tests.integration;
import org.apache.activemq.artemis.api.core.client.ClientSession;
import org.apache.activemq.artemis.api.core.client.ClientSessionFactory;
import org.apache.activemq.artemis.api.core.client.ServerLocator;
import org.apache.activemq.artemis.core.server.ActiveMQServer;
import org.apache.activemq.artemis.core.settings.impl.AddressSettings;
import org.apache.activemq.artemis.tests.util.ActiveMQTestBase;
import org.junit.Before;
import org.junit.Test;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.MessageConsumer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.Topic;
import java.util.HashMap;
public class QueueTopicSameNameTest extends ActiveMQTestBase {
protected ActiveMQServer server;
protected ClientSession session;
protected ClientSessionFactory sf;
protected ServerLocator locator;
@Override
@Before
public void setUp() throws Exception {
super.setUp();
server = createServer(true, createDefaultNettyConfig(),
AddressSettings.DEFAULT_PAGE_SIZE, AddressSettings.DEFAULT_MAX_SIZE_BYTES, -1,
-1, new HashMap<>());
server.start();
locator = createInVMNonHALocator();
sf = createSessionFactory(locator);
session = addClientSession(sf.createSession(false, true, true));
}
@Test
public void testConsumerKick() throws Exception {
String myAddr = "TEST";
ConnectionFactory cf = new
org.apache.activemq.ActiveMQConnectionFactory("failover:(tcp://localhost:61616)");
Connection c = cf.createConnection();
Session s = c.createSession();
Topic t = s.createTopic(myAddr);
MessageConsumer consumer = s.createConsumer(t);
Queue q = s.createQueue(myAddr);
MessageConsumer otherConsumer = s.createConsumer(q);
c.close();
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9512) Latencies with large synchrized blocks in JDBC persistence adapter
[
https://issues.apache.org/jira/browse/AMQ-9512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850799#comment-17850799
]
Justin Bertram commented on AMQ-9512:
-
For what it's worth, all of the actual implementations of
{{org.apache.activemq.store.TopicMessageStore#recoverNextMessages}} are either
using {{synchronized}} or some other kind of lock. This includes:
* {{org.apache.activemq.store.jdbc.JDBCTopicMessageStore#recoverNextMessages}}
(your case)
*
{{org.apache.activemq.store.kahadb.KahaDBStore.KahaDBTopicMessageStore#recoverNextMessages}}
(using a {{ReentrantReadWriteLock.WriteLock}})
*
{{org.apache.activemq.store.kahadb.TempKahaDBStore.KahaDBTopicMessageStore#recoverNextMessages}}
(using {{synchronized}})
*
{{org.apache.activemq.store.memory.MemoryTopicMessageStore#recoverNextMessages}}
(using {{synchronized}})
The thread dumps themselves don't contain any deadlocks. They simply contain a
number of threads in a {{BLOCKED}} state due to the synchronization. In each
thread dump a different thread is holding the lock which indicates that nothing
is stuck, per se. The broker is making progress, albeit slowly. It may simply
be that the database or the network is slow or just that this is the "cost of
doing business" with JDBC. Generally speaking, JDBC is the slowest option for
message storage. You may have better luck using shared storage with KahaDB.
> Latencies with large synchrized blocks in JDBC persistence adapter
> --
>
> Key: AMQ-9512
> URL: https://issues.apache.org/jira/browse/AMQ-9512
> Project: ActiveMQ Classic
> Issue Type: Bug
>Reporter: Jean-Louis Monteiro
>Priority: Major
> Attachments: stack-1, stack-2, stack-3, stack-4, stack-5
>
>
> When running ActiveMQ with a JDBC Persistence Adapter, I'm facing slow or
> irresponsive situations with ActiveMQ.
> I spotted (maybe badly) this one:
> [https://github.com/apache/activemq/blob/2f40261362bb830899f7f369a731b446f795a627/activemq-jdbc-store/src/main/java/org/apache/activemq/store/jdbc/JDBCTopicMessageStore.java#L262]
> Here are a couple of thread dumps at different moments that can demonstrate
> the situation hopefully.
> Not sure if this is the root cause or not, but anyways, the class seems
> inconsistent. The method is synchronized even though it seems to be a read
> only operation only. The rest of the class isn't thread safe at all, so I'm
> wondering what's the purpose.
> Second option would be to go fine grain with a ReentrantReadWriteLock maybe
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Closed] (AMQ-8417) ActiveMQBytesMessage - unable to read content after property is set
[
https://issues.apache.org/jira/browse/AMQ-8417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
R@DU closed AMQ-8417.
-
Resolution: Invalid
> ActiveMQBytesMessage - unable to read content after property is set
> ---
>
> Key: AMQ-8417
> URL: https://issues.apache.org/jira/browse/AMQ-8417
> Project: ActiveMQ Classic
> Issue Type: Bug
> Components: JMS client
>Affects Versions: 5.16.3
>Reporter: R@DU
>Priority: Critical
> Attachments: image-2021-11-26-12-34-28-328.png,
> image-2021-11-26-12-37-08-865.png, image-2021-11-26-12-42-33-028.png,
> image-2021-11-26-12-45-32-500.png
>
>
> This issue was discovered, when using spring boot 2.5.7 and spring cloud
> 2020.0.4 (brave 5.13.2, and ActiveMQ Client 5.16.3)!
> When sleuth is enabled, brave instrumentation jms edits the jms message, by
> removing properties related to sleuth, then jms message is consumed further
> (i.e. content is read).
> The issue is when jms message is of type ActiveMQBytesMessage.
> Having a closer look at how ActiveMQBytesMessage was implemented, I came to
> the conclusion that there is something wrong. However I do not know exactly
> if this is true, that's why I opened a bug for brave instrumentation jms as
> well. Please check for more details here:
> [https://github.com/openzipkin/brave/issues/1310] ;
> —
> *Steps:*
> # jms message, of type ActiveMQBytesMessage is received;
> # set a property on that message - use
> ActiveMQBytesMessage#setObjectProperty method;
> # try to read the content - use ActiveMQBytesMessage#read* method.
> # analyze the result...
> *Expected:*
> The content is read...
> *Actual:*
> no content is read...
> For more details check: [https://github.com/openzipkin/brave/issues/1310]
> h2. Things to consider
> When ActiveMQBytesMessage#setObjectProperty method is called
> !image-2021-11-26-12-34-28-328.png!
> the `initializeWritingNoCheck()` method moves the `content` to
> `dataOut`/`bytesOut`.
> As a result, `content` will be `null` and `dataOut`/`bytesOut` will contain
> the bytes moved from `content`. Note `dataIn` remains `null`.
> !image-2021-11-26-12-37-08-865.png!
> Note the comment done above `this.content = null;`!
> When `ActiveMQBytesMessage#read*` method is called, for example readByte()
> !image-2021-11-26-12-42-33-028.png!
> the `initializeReading()` will try to prepare the `dataIn` for reading, based
> on the `content`... but the `content` is `null` (here is the problem actually)
> !image-2021-11-26-12-45-32-500.png!
> as a result, the `dataIn` is initialized with an empty sequence of bytes
> (i.e. empty input stream).
> As a result, calling dataIn.read* method (in our example it will be
> dataIn.readByte()) will end in unexpected result (EOF or -1)...
> *Solution (in my opinion)*
> Fix should be done in
> org.apache.activemq.command.ActiveMQBytesMessage#initializeReading() method.
> When `content` is null, then
> org.apache.activemq.command.ActiveMQBytesMessage#storeContent() method should
> be called.
> Here is the code snippet:
> {code:java}
> ByteSequence data = getContent();
> if (data == null) {
> storeContent();
> data = getContent(); // storeContent() will set the content... only if
> dataOut != null;
> if (data == null) {
> data = new ByteSequence(new byte[] {}, 0, 0); // don't understand why
> we should silently fallback to an empty byte sequence... I would opt for an
> exception
> }
> } {code}
> This is just my opinion ^.
>
> Note: I do not know who should do the fix, that's why I have created this
> bug, and additionally I have created a bug on the ActiveMQ client-side, in
> the hope to obtain a resolution ASAP... check
> [https://github.com/openzipkin/brave/issues/1310]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Created] (AMQ-9512) Latencies with large synchrized blocks in JDBC persistence adapter
Jean-Louis Monteiro created AMQ-9512: Summary: Latencies with large synchrized blocks in JDBC persistence adapter Key: AMQ-9512 URL: https://issues.apache.org/jira/browse/AMQ-9512 Project: ActiveMQ Classic Issue Type: Bug Reporter: Jean-Louis Monteiro Attachments: stack-1, stack-2, stack-3, stack-4, stack-5 When running ActiveMQ with a JDBC Persistence Adapter, I'm facing slow or irresponsive situations with ActiveMQ. I spotted (maybe badly) this one: [https://github.com/apache/activemq/blob/2f40261362bb830899f7f369a731b446f795a627/activemq-jdbc-store/src/main/java/org/apache/activemq/store/jdbc/JDBCTopicMessageStore.java#L262] Here are a couple of thread dumps at different moments that can demonstrate the situation hopefully. Not sure if this is the root cause or not, but anyways, the class seems inconsistent. The method is synchronized even though it seems to be a read only operation only. The rest of the class isn't thread safe at all, so I'm wondering what's the purpose. Second option would be to go fine grain with a ReentrantReadWriteLock maybe -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-3957) Check for Subject on RemotingConnection before auth cache
[
https://issues.apache.org/jira/browse/ARTEMIS-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850742#comment-17850742
]
Justin Bertram commented on ARTEMIS-3957:
-
[~mike.artz], how come?
> Check for Subject on RemotingConnection before auth cache
> -
>
> Key: ARTEMIS-3957
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3957
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Authenticated users automatically have their {{Subject}} set on their
> {{RemotingConnection}}. The {{SecurityStore}} should check for this
> {{Subject}} during authorization before checking its cache or attempting
> re-authentication. This will avoid unnecessary traffic to the underlying
> security repository (e.g. LDAP) in cases where the cache times out or is
> disabled completely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (AMQ-9397) Update JDBC adapter mapping for MySQL 8 driver
[
https://issues.apache.org/jira/browse/AMQ-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated AMQ-9397:
--
Fix Version/s: (was: 5.17.7)
> Update JDBC adapter mapping for MySQL 8 driver
> --
>
> Key: AMQ-9397
> URL: https://issues.apache.org/jira/browse/AMQ-9397
> Project: ActiveMQ Classic
> Issue Type: New Feature
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 6.1.0, 5.18.4, 6.0.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Need updated mapping for MySQL 8
> ref:
> https://stackoverflow.com/questions/76687587/activemq-classic-jdbc-master-slave-persistent-issue-with-jdbc-unable-to-lock-t
> {noformat}
> Using Persistence Adapter:
> JDBCPersistenceAdapter(org.apache.commons.dbcp2.BasicDataSource@6bd16207) |
> org.apache.activemq.broker.BrokerService | main
> Starting Persistence Adapter:
> JDBCPersistenceAdapter(org.apache.commons.dbcp2.BasicDataSource@6bd16207) |
> org.apache.activemq.broker.BrokerService | main
> Database adapter driver override not found for : [mysql_connector_j]. Will
> use default implementation. |
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
> Database lock driver override not found for : [mysql_connector_j]. Will use
> default implementation. |
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Updated] (AMQ-9397) Update JDBC adapter mapping for MySQL 8 driver
[
https://issues.apache.org/jira/browse/AMQ-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated AMQ-9397:
--
Fix Version/s: (was: 6.1.0)
> Update JDBC adapter mapping for MySQL 8 driver
> --
>
> Key: AMQ-9397
> URL: https://issues.apache.org/jira/browse/AMQ-9397
> Project: ActiveMQ Classic
> Issue Type: New Feature
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 5.18.4, 6.0.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Need updated mapping for MySQL 8
> ref:
> https://stackoverflow.com/questions/76687587/activemq-classic-jdbc-master-slave-persistent-issue-with-jdbc-unable-to-lock-t
> {noformat}
> Using Persistence Adapter:
> JDBCPersistenceAdapter(org.apache.commons.dbcp2.BasicDataSource@6bd16207) |
> org.apache.activemq.broker.BrokerService | main
> Starting Persistence Adapter:
> JDBCPersistenceAdapter(org.apache.commons.dbcp2.BasicDataSource@6bd16207) |
> org.apache.activemq.broker.BrokerService | main
> Database adapter driver override not found for : [mysql_connector_j]. Will
> use default implementation. |
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
> Database lock driver override not found for : [mysql_connector_j]. Will use
> default implementation. |
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9397) Update JDBC adapter mapping for MySQL 8 driver
[
https://issues.apache.org/jira/browse/AMQ-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850733#comment-17850733
]
Jean-Baptiste Onofré commented on AMQ-9397:
---
Good point, let me cleanup. Thanks [~jbertram] !
> Update JDBC adapter mapping for MySQL 8 driver
> --
>
> Key: AMQ-9397
> URL: https://issues.apache.org/jira/browse/AMQ-9397
> Project: ActiveMQ Classic
> Issue Type: New Feature
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 6.1.0, 5.18.4, 6.0.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Need updated mapping for MySQL 8
> ref:
> https://stackoverflow.com/questions/76687587/activemq-classic-jdbc-master-slave-persistent-issue-with-jdbc-unable-to-lock-t
> {noformat}
> Using Persistence Adapter:
> JDBCPersistenceAdapter(org.apache.commons.dbcp2.BasicDataSource@6bd16207) |
> org.apache.activemq.broker.BrokerService | main
> Starting Persistence Adapter:
> JDBCPersistenceAdapter(org.apache.commons.dbcp2.BasicDataSource@6bd16207) |
> org.apache.activemq.broker.BrokerService | main
> Database adapter driver override not found for : [mysql_connector_j]. Will
> use default implementation. |
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
> Database lock driver override not found for : [mysql_connector_j]. Will use
> default implementation. |
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | main
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4165) Page transactions not getting deleted on queue deletion
[
https://issues.apache.org/jira/browse/ARTEMIS-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850715#comment-17850715
]
ASF subversion and git services commented on ARTEMIS-4165:
--
Commit 6b5f78bfc4f53ac32808cb5a5cf947ef649fc4a3 in activemq-artemis's branch
refs/heads/main from iliya
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=6b5f78bfc4 ]
ARTEMIS-4165 Delete messages in case of queue destroy
Messages should be acked even while paging. That will allow page transactions
or anything else
to be cleared accordingly.
> Page transactions not getting deleted on queue deletion
> ---
>
> Key: ARTEMIS-4165
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4165
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.28.0
>Reporter: Iliya Grushevskiy
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If the queue contains paged messages then during queue deletion those message
> records won't be updated. That will lead to journal grows as those records
> will never get removed from journal.
> {code:java}
> operation@AddRecordTX;txID=107743391288,recordID=107743391443;userRecordType=35;isUpdate=false;compactCount=18;PageTransactionInfoImpl(transactionID=107743391288,id=107743391443,numberOfMessages=1)
> operation@Commit;txID=107743391288,numberOfRecords=1
> operation@AddRecordTX;txID=107743391258,recordID=107743391446;userRecordType=35;isUpdate=false;compactCount=18;PageTransactionInfoImpl(transactionID=107743391258,id=107743391446,numberOfMessages=1){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4165) Page transactions not getting deleted on queue deletion
[
https://issues.apache.org/jira/browse/ARTEMIS-4165?focusedWorklogId=921389&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921389
]
ASF GitHub Bot logged work on ARTEMIS-4165:
---
Author: ASF GitHub Bot
Created on: 30/May/24 13:31
Start Date: 30/May/24 13:31
Worklog Time Spent: 10m
Work Description: clebertsuconic merged PR #4948:
URL: https://github.com/apache/activemq-artemis/pull/4948
Issue Time Tracking
---
Worklog Id: (was: 921389)
Time Spent: 50m (was: 40m)
> Page transactions not getting deleted on queue deletion
> ---
>
> Key: ARTEMIS-4165
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4165
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.28.0
>Reporter: Iliya Grushevskiy
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If the queue contains paged messages then during queue deletion those message
> records won't be updated. That will lead to journal grows as those records
> will never get removed from journal.
> {code:java}
> operation@AddRecordTX;txID=107743391288,recordID=107743391443;userRecordType=35;isUpdate=false;compactCount=18;PageTransactionInfoImpl(transactionID=107743391288,id=107743391443,numberOfMessages=1)
> operation@Commit;txID=107743391288,numberOfRecords=1
> operation@AddRecordTX;txID=107743391258,recordID=107743391446;userRecordType=35;isUpdate=false;compactCount=18;PageTransactionInfoImpl(transactionID=107743391258,id=107743391446,numberOfMessages=1){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4786) ConcurrentModificationException on Page.destroy
[ https://issues.apache.org/jira/browse/ARTEMIS-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850716#comment-17850716 ] ASF subversion and git services commented on ARTEMIS-4786: -- Commit 032597dba3bf8450900a03dc45643bb80d9e0757 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=032597dba3 ] ARTEMIS-4786 Avoid ConcurrentModificationException while queue.destroy in page We observed this assert error in the netty collection used for acks: java.lang.AssertionError: null is not a legitimate internal value. Concurrent Modification? at io.netty.util.collection.IntObjectHashMap.toExternal(IntObjectHashMap.java:103) ~[netty-common-4.1.109.Final.jar:4.1.109.Final] at io.netty.util.collection.IntObjectHashMap.access$900(IntObjectHashMap.java:37) ~[netty-common-4.1.109.Final.jar:4.1.109.Final] at io.netty.util.collection.IntObjectHashMap$PrimitiveIterator.value(IntObjectHashMap.java:650) ~[netty-common-4.1.109.Final.jar:4.1.109.Final] at io.netty.util.collection.IntObjectHashMap$2$1.next(IntObjectHashMap.java:234) ~[netty-common-4.1.109.Final.jar:4.1.109.Final] this will avoid the cleanup and rely on GC for the cleanup. PagingLeakTest is being added to make sure the cleanup is actually not needed. > ConcurrentModificationException on Page.destroy > --- > > Key: ARTEMIS-4786 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4786 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > > I observed this while running > org.apache.activemq.artemis.tests.integration.client.ConcurrentCreateDeleteProduceTest.testConcurrentProduceCreateAndDelete > in loop: > java.lang.AssertionError: null is not a legitimate internal value. Concurrent > Modification? > at > io.netty.util.collection.IntObjectHashMap.toExternal(IntObjectHashMap.java:103) > ~[netty-common-4.1.109.Final.jar:4.1.109.Final] > at > io.netty.util.collection.IntObjectHashMap.access$900(IntObjectHashMap.java:37) > ~[netty-common-4.1.109.Final.jar:4.1.109.Final] > at > io.netty.util.collection.IntObjectHashMap$PrimitiveIterator.value(IntObjectHashMap.java:650) > ~[netty-common-4.1.109.Final.jar:4.1.109.Final] > at > io.netty.util.collection.IntObjectHashMap$2$1.next(IntObjectHashMap.java:234) > ~[netty-common-4.1.109.Final.jar:4.1.109.Final] > at > org.apache.activemq.artemis.core.paging.cursor.impl.PageSubscriptionImpl.destroy(PageSubscriptionImpl.java:642) > ~[classes/:?] > at > org.apache.activemq.artemis.core.server.impl.QueueImpl.destroyPaging(QueueImpl.java:2382) > ~[classes/:?] > at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:2441) > ~[classes/:?] > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2512) > ~[classes/:?] > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2461) > ~[classes/:?] > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.deleteQueue(ServerSessionImpl.java:1212) > ~[classes/:?] > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.deleteQueue(ServerSessionImpl.java:1196) > ~[classes/:?] > at > org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:436) > ~[classes/:?] > On the occasion I had a fix for ARTEMIS-4165 in place, but the issue seems > orthogonal to me. > The cleanup methods are clearing the Netty collection out of abundance of > caution (to help out GC). The fix here is just to stop doing that. > As part of this fix I'm also adding a check-leak test to make sure such > objects are not leaking. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-3957) Check for Subject on RemotingConnection before auth cache
[
https://issues.apache.org/jira/browse/ARTEMIS-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850677#comment-17850677
]
Mike Artz commented on ARTEMIS-3957:
This looks like it should be closed
> Check for Subject on RemotingConnection before auth cache
> -
>
> Key: ARTEMIS-3957
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3957
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Authenticated users automatically have their {{Subject}} set on their
> {{RemotingConnection}}. The {{SecurityStore}} should check for this
> {{Subject}} during authorization before checking its cache or attempting
> re-authentication. This will avoid unnecessary traffic to the underlying
> security repository (e.g. LDAP) in cases where the cache times out or is
> disabled completely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (ARTEMIS-4785) log4j config from classpath and cli issue
[ https://issues.apache.org/jira/browse/ARTEMIS-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850676#comment-17850676 ] Robbie Gemmell commented on ARTEMIS-4785: - The etc dir is on the classpath to pick up various things other than the logging config, the path to which was actually historically hard coded in the script (before the SLF4J + Log4J switch). So I'm no sure you can just remove etc from the classpath without significant change. Though renaming the file wouldnt be needed if etc wasnt on the classpath except when running the broker. As I mentioned the other day, even if the script did specify the file to be used again then it wouldnt itself fix things; the script would also need to specifically know whether you were using the run command or not, and behave differently for it and the other commands, since they all load via the same initial class and classpath stuff, and so would still all get the same logging config even if were specified. Also, the 'shell' command can in turn run the broker (and anything else that you might want logging for) currently, after the initial load, so that would also need to do something different perhaps. Also, the ability to replace the default config by supplying your own "-Dlog4j2..." config for the broker as an override (it having the highest precedence) would possibly become more complicated. Your second comment notes 'we can do this for new instance creations'...but how then are you handling upgrades with the upgrade command? It leaves a lot of the config alone but it replaces the scripts with the current version, so in this case the config would need to align to those updated scripts expectations, e.g if you rename the log4j file and specify a -D config aimed a new instance creation, the log4j file would probably need renamed during upgrade too...think it possibly throws on not finding it if its explicitly specified. (You also might not know what its normal name is if its already being specified as an override, so do you write a new one if not finding it? Currently we only do that if we find the old logging.properties file, when it gets switched out) For me, I'd potentially be looking at moving the 'not-broker' commands to their own separate tools script that can be configured appropriately, or just banning the instance-level artemis command from running such 'not-broker' things, so they cant interfere. Feels like perhaps its doing too many different things. Or else changing things so they dont all use the same loader and classpath as currently. > log4j config from classpath and cli issue > - > > Key: ARTEMIS-4785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4785 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.33.0 >Reporter: Gary Tully >Priority: Major > > I have come across a strange issue where the root cause is the instance dir > cli sharing the log4j config with the broker. > the logging has a rolling file appender schedual of 1 minute. looks to be > working fine, then use instance-dir/bin/artemis produicer --user invalid to > generate logging... and the broker appender gets borked. > The problem, the cli is reading the same log4j2 config from the etc dir on > the classpath. > This is not ideal. > One workaroud is to use the installation dir artemis for producer!consumer > commands. > I wonder if we should use -Dlog4j.configuration to specify a file not on the > classpath for the broker. and leave etc off the classpath? > I guess there are a few ways to solve this. but there is indeed a gotcha here. > thoughts? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9510) Upgrade to jmock 2.13.1
[ https://issues.apache.org/jira/browse/AMQ-9510?focusedWorklogId=921372&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921372 ] ASF GitHub Bot logged work on AMQ-9510: --- Author: ASF GitHub Bot Created on: 30/May/24 09:25 Start Date: 30/May/24 09:25 Worklog Time Spent: 10m Work Description: jbonofre opened a new pull request, #1235: URL: https://github.com/apache/activemq/pull/1235 (no comment) Issue Time Tracking --- Worklog Id: (was: 921372) Remaining Estimate: 0h Time Spent: 10m > Upgrade to jmock 2.13.1 > --- > > Key: AMQ-9510 > URL: https://issues.apache.org/jira/browse/AMQ-9510 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Test Cases >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9509) Upgrade to jetty 11.0.21
[ https://issues.apache.org/jira/browse/AMQ-9509?focusedWorklogId=921369&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921369 ] ASF GitHub Bot logged work on AMQ-9509: --- Author: ASF GitHub Bot Created on: 30/May/24 09:21 Start Date: 30/May/24 09:21 Worklog Time Spent: 10m Work Description: jbonofre opened a new pull request, #1234: URL: https://github.com/apache/activemq/pull/1234 (no comment) Issue Time Tracking --- Worklog Id: (was: 921369) Remaining Estimate: 0h Time Spent: 10m > Upgrade to jetty 11.0.21 > > > Key: AMQ-9509 > URL: https://issues.apache.org/jira/browse/AMQ-9509 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker, Transport, Web Console >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9508) Upgrade to commons-logging 1.3.2
[ https://issues.apache.org/jira/browse/AMQ-9508?focusedWorklogId=921368&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921368 ] ASF GitHub Bot logged work on AMQ-9508: --- Author: ASF GitHub Bot Created on: 30/May/24 09:19 Start Date: 30/May/24 09:19 Worklog Time Spent: 10m Work Description: jbonofre opened a new pull request, #1233: URL: https://github.com/apache/activemq/pull/1233 (no comment) Issue Time Tracking --- Worklog Id: (was: 921368) Remaining Estimate: 0h Time Spent: 10m > Upgrade to commons-logging 1.3.2 > > > Key: AMQ-9508 > URL: https://issues.apache.org/jira/browse/AMQ-9508 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9507) Upgrade to commons-daemon 1.4.0
[ https://issues.apache.org/jira/browse/AMQ-9507?focusedWorklogId=921367&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921367 ] ASF GitHub Bot logged work on AMQ-9507: --- Author: ASF GitHub Bot Created on: 30/May/24 09:18 Start Date: 30/May/24 09:18 Worklog Time Spent: 10m Work Description: jbonofre opened a new pull request, #1232: URL: https://github.com/apache/activemq/pull/1232 (no comment) Issue Time Tracking --- Worklog Id: (was: 921367) Remaining Estimate: 0h Time Spent: 10m > Upgrade to commons-daemon 1.4.0 > --- > > Key: AMQ-9507 > URL: https://issues.apache.org/jira/browse/AMQ-9507 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9506) Upgrade to jackson 2.17.1
[ https://issues.apache.org/jira/browse/AMQ-9506?focusedWorklogId=921366&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921366 ] ASF GitHub Bot logged work on AMQ-9506: --- Author: ASF GitHub Bot Created on: 30/May/24 09:14 Start Date: 30/May/24 09:14 Worklog Time Spent: 10m Work Description: jbonofre opened a new pull request, #1231: URL: https://github.com/apache/activemq/pull/1231 (no comment) Issue Time Tracking --- Worklog Id: (was: 921366) Remaining Estimate: 0h Time Spent: 10m > Upgrade to jackson 2.17.1 > - > > Key: AMQ-9506 > URL: https://issues.apache.org/jira/browse/AMQ-9506 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker, Web Console >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9511) Upgrade to Spring 6.1.8
[ https://issues.apache.org/jira/browse/AMQ-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850645#comment-17850645 ] ASF subversion and git services commented on AMQ-9511: -- Commit 909b61c9286c035bdf39c8d95617819288a03578 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=909b61c92 ] AMQ-9511: Upgrade to Spring 6.1.8 > Upgrade to Spring 6.1.8 > --- > > Key: AMQ-9511 > URL: https://issues.apache.org/jira/browse/AMQ-9511 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9497) Upgrade to maven-jar-plugin 3.4.1
[ https://issues.apache.org/jira/browse/AMQ-9497?focusedWorklogId=921364&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921364 ] ASF GitHub Bot logged work on AMQ-9497: --- Author: ASF GitHub Bot Created on: 30/May/24 09:09 Start Date: 30/May/24 09:09 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1228: URL: https://github.com/apache/activemq/pull/1228 Issue Time Tracking --- Worklog Id: (was: 921364) Time Spent: 20m (was: 10m) > Upgrade to maven-jar-plugin 3.4.1 > - > > Key: AMQ-9497 > URL: https://issues.apache.org/jira/browse/AMQ-9497 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9511) Upgrade to Spring 6.1.8
[ https://issues.apache.org/jira/browse/AMQ-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850646#comment-17850646 ] ASF subversion and git services commented on AMQ-9511: -- Commit 50ea73f1d5788ba1b216f7bece4580b8033c1759 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=50ea73f1d ] Merge pull request #1230 from jbonofre/AMQ-9511 AMQ-9511: Upgrade to Spring 6.1.8 > Upgrade to Spring 6.1.8 > --- > > Key: AMQ-9511 > URL: https://issues.apache.org/jira/browse/AMQ-9511 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (AMQ-9511) Upgrade to Spring 6.1.8
[ https://issues.apache.org/jira/browse/AMQ-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9511. --- Resolution: Fixed > Upgrade to Spring 6.1.8 > --- > > Key: AMQ-9511 > URL: https://issues.apache.org/jira/browse/AMQ-9511 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9497) Upgrade to maven-jar-plugin 3.4.1
[ https://issues.apache.org/jira/browse/AMQ-9497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850643#comment-17850643 ] ASF subversion and git services commented on AMQ-9497: -- Commit b954a1054c81be2dd6478b1ab603df322e65cb80 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=b954a1054 ] AMQ-9497: Upgrade to maven-jar-plugin 3.4.1 > Upgrade to maven-jar-plugin 3.4.1 > - > > Key: AMQ-9497 > URL: https://issues.apache.org/jira/browse/AMQ-9497 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (AMQ-9496) Upgrade to maven-compiler-plugin 3.13.0
[ https://issues.apache.org/jira/browse/AMQ-9496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9496. --- Resolution: Fixed > Upgrade to maven-compiler-plugin 3.13.0 > --- > > Key: AMQ-9496 > URL: https://issues.apache.org/jira/browse/AMQ-9496 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9496) Upgrade to maven-compiler-plugin 3.13.0
[ https://issues.apache.org/jira/browse/AMQ-9496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850642#comment-17850642 ] ASF subversion and git services commented on AMQ-9496: -- Commit 29fa2a3503fa3b81aeb67d2301ea7412d9efdee0 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=29fa2a350 ] Merge pull request #1227 from jbonofre/AMQ-9496 AMQ-9496: Upgrade to maven-compiler-plugin 3.13.0 > Upgrade to maven-compiler-plugin 3.13.0 > --- > > Key: AMQ-9496 > URL: https://issues.apache.org/jira/browse/AMQ-9496 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9496) Upgrade to maven-compiler-plugin 3.13.0
[ https://issues.apache.org/jira/browse/AMQ-9496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850641#comment-17850641 ] ASF subversion and git services commented on AMQ-9496: -- Commit 3d36570181ecac43897ae968352aba71614dc527 in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=3d3657018 ] AMQ-9496: Upgrade to maven-compiler-plugin 3.13.0 > Upgrade to maven-compiler-plugin 3.13.0 > --- > > Key: AMQ-9496 > URL: https://issues.apache.org/jira/browse/AMQ-9496 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9511) Upgrade to Spring 6.1.8
[ https://issues.apache.org/jira/browse/AMQ-9511?focusedWorklogId=921365&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921365 ] ASF GitHub Bot logged work on AMQ-9511: --- Author: ASF GitHub Bot Created on: 30/May/24 09:09 Start Date: 30/May/24 09:09 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1230: URL: https://github.com/apache/activemq/pull/1230 Issue Time Tracking --- Worklog Id: (was: 921365) Time Spent: 20m (was: 10m) > Upgrade to Spring 6.1.8 > --- > > Key: AMQ-9511 > URL: https://issues.apache.org/jira/browse/AMQ-9511 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Commented] (AMQ-9497) Upgrade to maven-jar-plugin 3.4.1
[ https://issues.apache.org/jira/browse/AMQ-9497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850644#comment-17850644 ] ASF subversion and git services commented on AMQ-9497: -- Commit 814871a0488e677957b546e4fdb148d60ed79afe in activemq's branch refs/heads/main from JB Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=814871a04 ] Merge pull request #1228 from jbonofre/AMQ-9497 AMQ-9497: Upgrade to maven-jar-plugin 3.4.1 > Upgrade to maven-jar-plugin 3.4.1 > - > > Key: AMQ-9497 > URL: https://issues.apache.org/jira/browse/AMQ-9497 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Resolved] (AMQ-9497) Upgrade to maven-jar-plugin 3.4.1
[ https://issues.apache.org/jira/browse/AMQ-9497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-9497. --- Resolution: Fixed > Upgrade to maven-jar-plugin 3.4.1 > - > > Key: AMQ-9497 > URL: https://issues.apache.org/jira/browse/AMQ-9497 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (AMQ-9496) Upgrade to maven-compiler-plugin 3.13.0
[ https://issues.apache.org/jira/browse/AMQ-9496?focusedWorklogId=921363&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921363 ] ASF GitHub Bot logged work on AMQ-9496: --- Author: ASF GitHub Bot Created on: 30/May/24 09:08 Start Date: 30/May/24 09:08 Worklog Time Spent: 10m Work Description: jbonofre merged PR #1227: URL: https://github.com/apache/activemq/pull/1227 Issue Time Tracking --- Worklog Id: (was: 921363) Time Spent: 20m (was: 10m) > Upgrade to maven-compiler-plugin 3.13.0 > --- > > Key: AMQ-9496 > URL: https://issues.apache.org/jira/browse/AMQ-9496 > Project: ActiveMQ Classic > Issue Type: Dependency upgrade >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 6.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
